PR Babysitter
openinterpreter/openinterpreter
Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.
LLM-focused code review process for this repo: what to check, how to ground feedback in invariants/tests, and how to verify changes efficiently (including test-report.json).
Install Code Review
$ npx skills add atopile/atopile --skill code-review -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install atopile/atopile code-review --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/atopile/atopile.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/code-review .claude/skills/code-review && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "code-review" agent skill from https://github.com/atopile/atopile/tree/main/.claude/skills/code-review into .claude/skills/code-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "code-review", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/atopile/atopile/tree/main/.claude/skills/code-reviewType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add atopile/atopile --skill code-review -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install atopile/atopile code-review --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/atopile/atopile.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.claude/skills/code-review .agents/skills/code-review && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "code-review" agent skill from https://github.com/atopile/atopile/tree/main/.claude/skills/code-review into .agents/skills/code-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "code-review", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add atopile/atopile --skill code-review -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install atopile/atopile code-review --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/atopile/atopile.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.claude/skills/code-review .cursor/skills/code-review && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "code-review" agent skill from https://github.com/atopile/atopile/tree/main/.claude/skills/code-review into .cursor/skills/code-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "code-review", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/atopile/atopile.git --path .claude/skills/code-review--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add atopile/atopile --skill code-review -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install atopile/atopile code-review --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/atopile/atopile.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.claude/skills/code-review .gemini/skills/code-review && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "code-review" agent skill from https://github.com/atopile/atopile/tree/main/.claude/skills/code-review into .gemini/skills/code-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "code-review", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install atopile/atopile code-reviewInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add atopile/atopile --skill code-review -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/atopile/atopile.git skills-src && mkdir -p .github/skills && cp -r skills-src/.claude/skills/code-review .github/skills/code-review && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "code-review" agent skill from https://github.com/atopile/atopile/tree/main/.claude/skills/code-review into .github/skills/code-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "code-review", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add atopile/atopile --skill code-review -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install atopile/atopile code-review --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/atopile/atopile.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.claude/skills/code-review .opencode/skills/code-review && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "code-review" agent skill from https://github.com/atopile/atopile/tree/main/.claude/skills/code-review into .opencode/skills/code-review/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "code-review", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
code-review- GitHub stars
- 4k
- Token cost
- ~1.9k tokens
- SKILL.md length
- 945 words
- Files
- 1
- Skills in repo
- 19
- Repo updated
- First seen
- Licence
- MIT
At a glance
LLM-focused code review process for this repo: what to check, how to ground feedback in invariants/tests, and how to verify changes efficiently (including test-report.json).
- Works in 4 steps: Correctness + invariants → Performance / scalability → Maintainability → …
- Tasks that involve Code review
- SKILL.md covers Quick Start, What to Prioritize (In Order), Repo-Specific Review Anchors and PR Review Output Format, plus 1 more section
- Calls gh
What it does
Code Review is an agent skill from atopile/atopile. LLM-focused code review process for this repo: what to check, how to ground feedback in invariants/tests, and how to verify changes efficiently (including test-report.json).
Its SKILL.md is about 1.9k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.
It sits in Development, covering Code review. The repository describes itself as: Design circuit boards with code! ✨ Get software-like design reuse 🚀, validation, version control and collaboration in hardware; starting with electronics ⚡️. The licence is MIT.
When your agent uses it
- Tasks that involve Code review
Example prompts
- “/code-review”
Requirements
- Python 3
Workflow steps
4 steps, taken from the first numbered list in SKILL.md.
- Correctness + invariants
- Performance / scalability
- Maintainability
- Test coverage
What it can do on your machine
Read from SKILL.md and the folder at commit 619eda7. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Shell commands in SKILL.md call:
gh
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md. Its commands use gh, which can reach the network depending on how they are called.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Code Review loads about 1.9k tokens when it runs. Until then it costs about 46 tokens; SKILL.md has 945 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
SKILL.md
The full file from atopile/atopile at commit 619eda7, republished under its MIT licence (© atopile). 945 words, ~1,885 tokens.
Download SKILL.mdSave it as
.claude/skills/code-review/SKILL.md (or your agent's skills folder).- name
- code-review
- description
- LLM-focused code review process for this repo: what to check, how to ground feedback in invariants/tests, and how to verify changes efficiently (including test-report.json).
Code Review Skill
This skill is the canonical guidance for automated and interactive code reviews in this repo. It is written for LLM reviewers (CI bots and local agents).
Quick Start
- Read the PR description and ensure it matches
.github/pull_request_template.md. - Review the diff focusing on invariants, correctness, and performance-sensitive hotspots.
- If you can run commands locally, prefer targeted verification:
ato dev test --llm -k <area>(fast filter)ato dev compile(if Zig/bindings changed)ato dev flags(if behavior depends on ConfigFlags)
- When summarizing failures/regressions, prefer
artifacts/test-report.jsonover HTML.
What to Prioritize (In Order)
Correctness + invariants
- Identify the invariants the changed code is supposed to preserve and check the code that enforces them.
- If you can't find an invariant in-code or in tests, flag it as "missing invariant coverage".
Performance / scalability
- This branch prioritizes speed and maintainability; watch for accidental
O(n^2)walks, repeated graph traversals, excessive allocations, or debug logging in hot paths. - Zig/Python boundary changes are especially sensitive (ownership, lifetimes, deinit).
- This branch prioritizes speed and maintainability; watch for accidental
Maintainability
- Prefer small, well-named units and clear boundaries (compiler vs graph vs solver vs library).
- Avoid adding new "mini frameworks" unless the repo already uses that pattern.
Test coverage
- If behavior changed, require a test (or a strong reason it can't be tested).
- Prefer targeted tests near the module; avoid broad end-to-end tests unless necessary.
Repo-Specific Review Anchors
- Dev workflow + reports:
ato dev test --llmwritesartifacts/test-report.jsonandartifacts/test-report.llm.json, and optionallyartifacts/test-report.html(seetest/runner/main.py). - ConfigFlags: inventory via
ato dev flags; prefer code-driven discovery over hand-maintained docs. - Graph/fabll redesign: see
AGENTS.mdand the relevant.claude/skills/*docs for the area you're reviewing. - Solver invariants:
src/faebryk/core/solver/README.md+src/faebryk/core/solver/symbolic/invariants.py.
PR Review Output Format
When writing a CI review comment, produce exactly this structure and nothing else. The goal is a minimal, scannable summary a human can glance at in seconds.
Use gh pr comment --edit-last --create-if-none so the review stays in a single updated comment.
Template
## <one-line summary of intent>
| Metric | Score |
|--------|-------|
| **Impact** | X/10 |
| **Test coverage** | X/10 |
<details>
<summary>🔴 High-severity issues (N found)</summary>
### 1. <short title>
<details>
<file:line — description>
</details>
</details>How to Score Impact (0–10)
Impact measures how important it is for a human to manually review this PR. Think: "if I skip reviewing this, what's the worst that could happen?"
| Score | Meaning | Examples |
|---|---|---|
| 0–1 | No-op, typo fix, comment-only, CI config tweak | Fixing a typo in a README, bumping a version pin |
| 2–3 | Low-risk, isolated change with no behavioral effect on users | Renaming an internal variable, adding a log line |
| 4–5 | Normal feature or bugfix, limited blast radius | Adding a new CLI flag, fixing a parser edge case |
| 6–7 | Touches shared infrastructure, changes public API surface, or affects multiple modules | Refactoring a compiler pass, changing graph traversal logic |
| 8–9 | High-risk: breaking API/ABI change, security-sensitive, concurrency/lifetime changes, large refactor across module boundaries | Changing Zig↔Python ownership semantics, modifying solver constraint propagation |
| 10 | Critical: data loss risk, auth bypass, or silent correctness regression in a hot path | Removing a safety check in the linker, changing deinit order |
When in doubt, round up — it's cheaper to over-flag than to miss something.
Show full SKILL.md (462 more words)Show less
How to Score Test Coverage (0–10)
Test coverage measures how well the changed behavior is exercised by existing or new tests. Consider both direct test coverage AND whether the changed code sits in a hot path that is transitively tested.
| Score | Meaning | Examples |
|---|---|---|
| 0–1 | No tests touch this code path, directly or transitively | Brand-new module with no tests added |
| 2–3 | Some transitive coverage but no direct tests for the changed behavior | Helper function called from tested code, but the specific new branch isn't exercised |
| 4–5 | Partial coverage: some cases tested, others not | New function has a happy-path test but no edge-case or error-path tests |
| 6–7 | Good coverage: most branches exercised, or the change is in a very hot path that many integration tests traverse | Modifying a graph traversal function that every build test exercises |
| 8–9 | Strong coverage: direct unit tests plus integration coverage for the changed behavior | New solver rule with dedicated tests AND it runs in existing end-to-end builds |
| 10 | Exhaustive or trivially safe: change is purely mechanical, or every branch is tested | Renaming a variable (trivially safe), or new function with 100% branch coverage |
If behavior changed but no test was added or updated, the score should be ≤5 regardless of transitive coverage.
What Counts as High-Severity
Only flag issues in these categories — everything else is noise for the PR comment:
- Bugs: logic errors, off-by-one, null/None dereference, use-after-free, wrong return value, race condition
- Performance regressions: O(n²) where O(n) is possible, unnecessary allocations in hot loops, repeated graph traversals, missing caching where prior code had it
- API/ABI compatibility breaks: removing or renaming a public symbol, changing a function signature that downstream code depends on, altering serialization format without migration
- Usability regressions: breaking an existing workflow, removing a feature without deprecation, changing default behavior silently
- Missing docs on hard-to-understand code: if the changed code is non-obvious (complex algorithm, subtle invariant, tricky lifetime management) and has no explaining comment, flag it — but only for genuinely confusing code, not for self-explanatory changes
If zero issues are found, write "None" inside the details block. Do NOT pad with style nits or nice-to-haves.
Rules
- The summary line must be ≤120 chars and describe the PR's purpose/intent.
- Each high-severity issue must reference a specific
file:lineand be actionable. - Do NOT include style nits, nice-to-haves, or low-severity suggestions in the PR comment.
- Keep the entire comment as short as possible. Brevity is a feature.
Interactive Review (Non-CI)
When reviewing interactively (not in CI), you can be more conversational, but still ground every non-trivial claim in the diff or a repo path (be explicit about file + symbol).
Separate feedback into:
- Must-fix (correctness/security/regression risks)
- Should-fix (maintainability/perf improvements)
- Nice-to-have (style/ergonomics)
Prefer actionable suggestions (what to change + why + where). If you're uncertain, ask a concrete question and point to the ambiguous code.
© atopile, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
Just SKILL.md in .claude/skills/code-review of atopile/atopile.
Open the folder on GitHubat commit 619eda7
Compare with similar skills
Code Review next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Code Review this skillatopile/atopile | 4k | — | ~1.9k | Automated safety check: Pass | MIT | |
| PR Babysitteropeninterpreter/openinterpreter | 69k | 3 repos | ~4.2k | Automated safety check: Pass | Apache-2.0 | |
| Code Review ChecklistshareAI-lab/learn-claude-code | 78k | 5 repos | ~1.1k | Automated safety check: Pass | MIT | |
| Backend Code Reviewlangflow-ai/langflow | 156k | — | ~3.5k | Automated safety check: Notes | MIT | |
| Understand Diff AnalysisEgonex-AI/Understand-Anything | 86k | 1 repos | ~1.4k | Automated safety check: Pass | MIT | |
| Mole Bug Patternstw93/Mole | 70k | — | ~2k | Automated safety check: Pass | GPL-3.0 |
Similar skills
Code Review Checklist
shareAI-lab/learn-claude-code
Reviews code against a five-part checklist covering security, correctness, performance, maintainability and testing, and reports findings in a fixed format.
Backend Code Review
langflow-ai/langflow
Review backend code for quality, security, maintainability, and best practices based on established checklist rules.
Understand Diff Analysis
Egonex-AI/Understand-Anything
Reads your git changes or a pull request against a prebuilt knowledge graph of the project to explain what changed, which components are affected and what is risky.
Mole Bug Patterns
tw93/Mole
A catalog of recurring bug shapes in the Mole Mac cleaner, used to review safety-sensitive diffs for deletion safety, unbounded commands, shell traps and weak tests.
Backend Code Review
langgenius/dify
Reviews backend code under api/ for concrete, reproducible defects, routes to rule packs for architecture, schema, repositories and SQLAlchemy, and ranks findings from P0 to P3.
More from atopile/atopile
All 19 skills in this repoAto Language
atopile/atopile
Reference for the .ato declarative DSL: type system, connection semantics, constraint model, and standard library.
Compiler
atopile/atopile
How the atopile compiler builds and links TypeGraphs from .ato (ANTLR front-end → AST → TypeGraph → Linker → DeferredExecutor), plus the key invariants and test entrypoints.
Domain Layer
atopile/atopile
Instructions for electronics-specific logic and build processes: netlists, PCBs, build steps, and exporters.
Fabll
atopile/atopile
How FabLL (faebryk.core.node) maps Python node/trait declarations into the TypeGraph + instance graph, including field/trait invariants and instantiation patterns.
Faebryk
atopile/atopile
How Faebryk's TypeGraph works (GraphView + Zig edges), how to traverse/resolve references, and how FabLL types/traits map onto edge types.
Graph
atopile/atopile
How the Zig-backed instance graph works (GraphView/NodeReference/EdgeReference), the real Python API surface, and the invariants around allocation, attributes, and cleanup.
Related
Categories
Questions about Code Review
What does Code Review do?
LLM-focused code review process for this repo: what to check, how to ground feedback in invariants/tests, and how to verify changes efficiently (including test-report.json). Code Review is an agent skill from atopile/atopile.json).
When should I use Code Review?
Code Review fits situations like: tasks that involve Code review.
How do I install Code Review in Claude Code?
Run `npx skills add atopile/atopile --skill code-review -a claude-code`. Or copy the skill folder (.claude/skills/code-review in atopile/atopile) into .claude/skills/code-review in your project. Claude Code loads it when a task matches its description.
How do I install Code Review in Codex?
Run `npx skills add atopile/atopile --skill code-review -a codex`. Or copy the skill folder (.claude/skills/code-review in atopile/atopile) into .agents/skills/code-review in your project. Codex loads it when a task matches its description.
Can I use Code Review in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add atopile/atopile --skill code-review -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/code-review, .gemini/skills/code-review, .github/skills/code-review and .opencode/skills/code-review in your project.
What does Code Review need to run?
Going by SKILL.md and its folder, Code Review needs the command-line tools its instructions call (gh). Our summary lists: Python 3.
Does Code Review access the network?
SKILL.md contains no URLs. Its commands use gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.
Is Code Review safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Code Review use?
Code Review is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Code Review use?
About 1.9k tokens (SKILL.md is roughly 7.5k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
What are the alternatives to Code Review?
Skills that share tags, products or a category with Code Review: PR Babysitter (openinterpreter/openinterpreter, 69k stars), Code Review Checklist (shareAI-lab/learn-claude-code, 78k stars), Backend Code Review (langflow-ai/langflow, 156k stars) and Understand Diff Analysis (Egonex-AI/Understand-Anything, 86k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Code Review?
atopile (a GitHub organization) maintains it in atopile/atopile, which has 3,976 GitHub stars. The repository holds 19 skills in this directory. The repository was last updated on June 13, 2026.
Source: atopile/atopile on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.