review
Skill3 starsChanged 7 months agoMITView on GitHub
Code review gate — dispatches the code-reviewer agent to analyze an implementation branch, tracks findings, and auto-dispatches the supervisor for rework when verdict is NEEDS-REWORK.
192 other projects use a version of this.
Adopted by
Most recently taken up by
- microsoft/veronatheir own version, first seen Nov 8, 2026
- microsoft/FluidFrameworktheir own version, first seen Nov 8, 2026
- charliee1w/consolidation-memorytheir own version, first seen Nov 8, 2026
- jisuzzzz/haechitheir own version, first seen Nov 8, 2026
- apokamo/kajitheir own version, first seen Nov 8, 2026
- dirien/yet-another-agent-harnesstheir own version, first seen Nov 8, 2026
Used with
Projects with it also use close-spec, design-with-images and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
dzhngSkillclose-spec
When a spec under specs/<feature>/ is done shipping (a write-spec build, or any planned task that produced a spec), archive it to specs/done/ and rewrite it from a build-plan into a durable rationale — the why, the principles, the invariants — pointing back to the real code for the how. Use when implementation has landed and the plan no longer matches what shipped, or the user says a feature/spec is finished. Pairs with [write-spec](../write-spec/SKILL.md) (the plan this closes) and [review](../review/SKILL.md) (run before closing).
Also in 5 projects that use this
dzhngSkilldesign-with-images
Explore UI and visual design with image generation, then iterate the real implementation against the user-selected concept. Use when brainstorming visual directions, offering mockup variants, or implementing an approved generated design; do not stop at the mockups or the first code approximation.
Also in 5 projects that use this
LambenthanSkilldaily-arxiv
每日从 arXiv 拉取新论文,过滤相关性,auto-ingest 高优先级论文,检测 SOTA 更新
Also in 5 projects that use this
LambenthanSkillexp-eval
实验判决门:Review LLM 独立评判实验结果 → 4 种判决路径 → 自动更新 claims confidence、ideas status、graph edges
Also in 5 projects that use this
- +3 more from dzhng
- +5 more from Lambenthan
Other versions192 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 192
- garrytan/gstack★ 141ksame name
- ansible/ansible★ 71ksame name
- docling-project/docling★ 70ksame name
- traefik/traefik★ 65ksame name
- ClickHouse/ClickHouse★ 51ksame name
- temporalio/temporal★ 24ksame name
- tisfeng/Easydict★ 15ksame name
- juicedata/juicefs★ 15ksame name
- elie222/inbox-zero★ 13ksame name
- gitkraken/vscode-gitlens★ 10ksame name
182 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository21 other files it gives its agents.
- skills/setup/templates/AGENTS.mdAGENTS.md
- skills/setup/templates/CLAUDE.mdCLAUDE.md
- add-supervisorSkill
- architectureSkill
- core-loopSkill
- doSkill
- implementationSkill
- investigateSkill
- manifestoSkill
- planSkill
- productSkill
- qualitySkill
- requirementsSkill
- researchSkill
- setupSkill
- specificationSkill
- specSkill
- subagents-disciplineSkill
- tasksSkill
- updateSkill
- workflowSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
21 rules. 0 are common, 6 are distinctive, and 15 are very specific to this project.
0
Common
Most of the 157 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
15
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 14
If the user provides $ARGUMENTS, check if it contains a bead ID (e.g., bd-a3f, bd-001.2).
- Distinctive: line 16
If bead ID provided: use it directly.
- Very specific: line 19
Run bd list --label needs-review --json to get beads awaiting review
- Very specific: line 21
If no beads with needs-review label found, inform the user and stop
- Distinctive: line 22
Ask the user which task to review </on-init>
- Very specific: line 27
Implementation branch must exist: Check with git branch -a | grep {BEAD_ID}.
- Very specific: line 28
COMPLETED comment should exist: Read bd comments {BEAD_ID} and search for COMPLETED:.
- Very specific: line 44
Read bead comments: bd comments {BEAD_ID}
- Distinctive: line 62
After the code-reviewer completes:
- Very specific: line 64
Read the REVIEW comment: bd comments {BEAD_ID}
- Very specific: line 70
If [cosmetic] items exist, auto-apply before proceeding:
- Very specific: line 72
If no supervisor can be resolved, skip auto-apply and treat [cosmetic] items as [semantic] for tracking in Step 4
- Very specific: line 81
If any items were skipped by the supervisor (reported as failures), promote them to [semantic] for tracking in Step 4
- Distinctive: line 90
Update labels and status:
- Very specific: line 97
Ask: "Continue on existing branch {branch-name} or create a fresh branch?
- Very specific: line 123
If
parentis not empty: use it as {TARGET_EPIC_ID} - Very specific: line 165
If APPROVE: brief summary of what was checked and confirmed.
- Distinctive: line 166
If NEEDS-REWORK: for each CRITICAL/WARNING, explain in natural language what the issue is, why it matters, and what needs to change.
- Distinctive: line 167
Findings tracked: if Fernando created beads, list them with plain-language descriptions, not raw finding text
- Very specific: line 178
If APPROVE → recommend /quality {BEAD_ID}
- Very specific: line 179
If NEEDS-REWORK → supervisor already dispatched (or user deferred to /do) </on-next>
“Common” is measured: kept by at least 6 in 10 of the 157 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Review
Dispatch a code review for a completed implementation. Quality gate between implementation and QA.
<on-init>
If the user provides $ARGUMENTS, check if it contains a bead ID (e.g., `bd-a3f`, `bd-001.2`).If bead ID provided: use it directly.
If no bead ID provided:
- Run
bd list --label needs-review --jsonto get beads awaiting review - Present the list showing: ID, title, priority, and labels
- If no beads with
needs-reviewlabel found, inform the user and stop - Ask the user which task to review
</on-init>
<on-check>
1. **Bead must exist and have status `in-review`.** Validate with `bd show {BEAD_ID} --json`.
2. **Implementation branch must exist.** Check with `git branch -a | grep {BEAD_ID}`.
3. **COMPLETED comment should exist.** Read `bd comments {BEAD_ID}` and search for `COMPLETED:`.
</on-check><on-check-fail if="bead">
Bead does not exist. Inform the user and stop.
</on-check-fail><on-check-fail if="completed_comment">
Warn: "The implementation supervisor did not leave a COMPLETED comment. The reviewer will have less context."
</on-check-fail><on-execute>Step 1: Read Bead Context
- Parse bead JSON. Extract:
description,acceptance,design,notes,status,labels,parent - Read bead comments:
bd comments {BEAD_ID} - Identify the implementation branch
Step 2: Dispatch Code Reviewer
Dispatch using exactly these parameters — no more, no less:
Agent(
subagent_type="code-reviewer",
prompt="Review BEAD {BEAD_ID} on branch {branch-name}. Read the bead (bd show {BEAD_ID}) and comments (bd comments {BEAD_ID}) for full context — description, acceptance criteria, design notes, and the COMPLETED comment from the supervisor. Analyze the branch diff against acceptance criteria and log a structured REVIEW comment to the bead."
)Do NOT add extra parameters unless the user explicitly requests it.
Step 3: Present Verdict
After the code-reviewer completes:
- Read the REVIEW comment:
bd comments {BEAD_ID} - Extract verdict:
APPROVEorNEEDS-REWORK - Present the review summary
If APPROVE:
- Extract
[cosmetic]SUGGESTIONs from the REVIEW comment - If
[cosmetic]items exist, auto-apply before proceeding:- Resolve supervisor from bead
assigneefield (same as/doStep 2) - If no supervisor can be resolved, skip auto-apply and treat
[cosmetic]items as[semantic]for tracking in Step 4 - Dispatch:
Do NOT add extra parameters unless the user explicitly requests it.Agent( subagent_type="{resolved-supervisor}", prompt="Apply cosmetic review fixes on BEAD {BEAD_ID}, branch {branch-name}. These are trivial, non-behavioral changes from the code review. Apply each fix, run build and tests to confirm nothing breaks, then commit as 'chore: review-cleanup {BEAD_ID}'. If any fix unexpectedly breaks build or tests, skip it and list skipped items in your report.\n\nCosmetic fixes to apply:\n{COSMETIC_LIST}" ) - If any items were skipped by the supervisor (reported as failures), promote them to
[semantic]for tracking in Step 4
- Resolve supervisor from bead
- Update labels:
bd label remove {BEAD_ID} needs-review bd label add {BEAD_ID} approved
If NEEDS-REWORK:
- Present findings (critical, warnings, suggestions)
- Update labels and status:
bd label remove {BEAD_ID} needs-review bd label add {BEAD_ID} needs-rework bd update {BEAD_ID} --status in_progress - Resolve branch for rework:
- Ask: "Continue on existing branch
{branch-name}or create a fresh branch? (default: continue)" - Store
{REWORK_BRANCH_INSTRUCTION}
- Ask: "Continue on existing branch
Step 4: Track Review Findings
Extract actionable findings from the REVIEW comment and apply the severity threshold policy:
| Severity | Action |
| CRITICAL | Addressed by rework (same bead) — never tracked separately |
| WARNING[must-fix] | Individual bead — direct impact on correctness, security, or reliability |
| WARNING[should-fix] | Batched into a single "Review warnings: {BEAD_ID}" bead per epic |
| SUGGESTION[semantic] | Batched into a single "Review cleanup" bead per epic — one bead for all semantic suggestions |
| SUGGESTION[cosmetic] | Auto-applied in Step 3 (APPROVE) or bundled into rework (NEEDS-REWORK) — not tracked |
| GOOD | Not tracked — acknowledgement only |
Filtering rules:
- APPROVE: track
[must-fix]WARNINGs as individual beads, batch[should-fix]WARNINGs into one bead, batch[semantic]SUGGESTIONs into one bead.[cosmetic]items already auto-applied in Step 3. - NEEDS-REWORK: CRITICAL and
[must-fix]WARNINGs addressed by rework. Batch[should-fix]WARNINGs and[semantic]SUGGESTIONs.[cosmetic]items bundled into rework prompt in Step 5. - If no
[must-fix]WARNINGs,[should-fix]WARNINGs, or[semantic]SUGGESTIONs exist: skip tracking entirely — do NOT dispatch Fernando - Findings beads (bead has any
finding:*label): the review verdict (APPROVE / NEEDS-REWORK) and rework cycle operate normally — CRITICALs and[must-fix]WARNINGs are still fixed via rework on the same bead. However, Step 4 tracking is skipped:[should-fix]WARNINGs and[semantic]SUGGESTIONs found during review of a findings bead are reported in the REVIEW comment for transparency but do NOT generate new beads. This breaks the recursive cycle where findings create findings indefinitely.
Resolve the target epic — findings go to the parent epic of the reviewed bead:
bd show {BEAD_ID} --json | python3 -c "import json,sys; d=json.load(sys.stdin); print(d[0].get('parent',''))"- If
parentis not empty: use it as{TARGET_EPIC_ID} - ONLY if
parentis empty: fall back to a "Review Findings" epic
Dispatch beads-owner using exactly these parameters — no more, no less:
Agent(
subagent_type="beads-owner",
prompt="Create beads issues for the following review findings from BEAD {BEAD_ID} review. IMPORTANT: Each issue MUST use --parent {TARGET_EPIC_ID} flag to place it inside the epic, and --deps 'discovered-from:{BEAD_ID}' to link back to the reviewed task. Do NOT use 'bd dep add' to link tasks to epics — only --parent does that. Use label 'finding:{severity}' (lowercase) for each. Include file path and line number. BATCHING RULE: Create individual beads for [must-fix] WARNING findings only. Batch [should-fix] WARNING findings into a single bead titled 'Review warnings: {BEAD_ID}' with each item as a checklist in the description. Batch ALL [semantic] SUGGESTION findings into a single bead titled 'Review cleanup: {BEAD_ID}' with each suggestion as a checklist item in the description. Note: [cosmetic] suggestions have already been applied automatically and are NOT included. Findings:\n\n{FINDINGS_LIST}"
)Do NOT add extra parameters unless the user explicitly requests it.
Step 5: Auto-Dispatch Supervisor (NEEDS-REWORK only)
Skip when verdict is APPROVE.
- Resolve supervisor from
assigneefield (same as/doStep 2) - Confirm before dispatch:
Ready to dispatch {resolved-supervisor} for rework of {BEAD_ID}: "{bead title}" Branch: {REWORK_BRANCH_INSTRUCTION summary} Findings to address: {N} CRITICAL + {M} [must-fix] WARNING Proceed? [y/n] - If confirmed, dispatch using exactly these parameters — no more, no less:
Do NOT add extra parameters unless the user explicitly requests it.Agent( subagent_type="{resolved-supervisor}", prompt="Rework BEAD {BEAD_ID}. {REWORK_BRANCH_INSTRUCTION} Read the bead (bd show {BEAD_ID}) and comments (bd comments {BEAD_ID}) for full context. The latest REVIEW comment contains CRITICAL and [must-fix] WARNING findings that MUST be addressed. [should-fix] WARNINGs and [semantic] SUGGESTIONs have been tracked as separate issues. Also apply any [cosmetic] suggestions from the REVIEW — they are trivial, non-behavioral fixes that do not need separate tracking. After addressing all findings, log a COMPLETED comment summarizing what was fixed." ) - If declined: inform "Run
/do {BEAD_ID}when ready." and stop.
</on-execute><on-complete>
Present the result following the **Presenting to the User** guidelines:- Headline: verdict in plain language — "Code review passed — ready for QA" or "Code review found {N} issues that need attention"
- What was found:
- If APPROVE: brief summary of what was checked and confirmed. Mention any
[cosmetic]items that were auto-applied. - If NEEDS-REWORK: for each CRITICAL/WARNING, explain in natural language what the issue is, why it matters, and what needs to change. Use a ASCII diagram if findings involve multi-component interactions.
- If APPROVE: brief summary of what was checked and confirmed. Mention any
- Findings tracked: if Fernando created beads, list them with plain-language descriptions, not raw finding text
- Repercussions: what could break if NEEDS-REWORK findings aren't addressed
- Next step: recommend
/quality {BEAD_ID}(APPROVE) or confirm rework dispatch (NEEDS-REWORK) - Technical details: raw REVIEW comment, spec references, and file:line locations in a
<details>block</on-complete>
<on-complete if="verdict=APPROVE">
Inform: "Code review passed. Ready for QA validation."
</on-complete><on-next>
- If APPROVE → recommend `/quality {BEAD_ID}`
- If NEEDS-REWORK → supervisor already dispatched (or user deferred to `/do`)
</on-next>Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

