reviewer
Skill3 starsChanged 3 months agoApache-2.0View on GitHub
Independently review one exact stable candidate for introduced actionable defects in a fresh session at the configured cadence boundary. Use for Reviewer, code review, or defect adjudication. Do not use for implementation, automatic review, evidence scoring, user acceptance, author self-review, or unconfigured slice/round boundaries.
33 other projects use a version of this.
Adopted by
Most recently taken up by
- NilsHellwig/acl-paper-skillstheir own version, first seen Nov 8, 2026
- Vinix24/vnx-orchestrationtheir own version, first seen Nov 6, 2026
- ChrisAraneo/skillstheir own version, first seen Nov 1, 2026
- J-T-McC/dev-teamtheir own version, first seen Nov 1, 2026
- Rhovian/nilestheir own version, first seen Nov 1, 2026
- cathaysia/skillstheir own version, first seen Oct 23, 2026
Used with
Projects with it also use tester, planner and 3 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.
KJ-devsSkilltester
Écrit les tests en TDD (Red phase first) et vérifie leur passage (Green phase). Frontend avec Playwright, backend avec BDD Given-When-Then.
Also in 4 projects that use this
am-willSkillplanner
Create comprehensive, phased implementation plans with sprints and atomic tasks. Use when user says: "make a plan", "create a plan", "plan this out", "plan the implementation", "help me plan", "design a plan", "draft a plan", "write a plan", "outline the steps", "break this down into tasks", "what's the plan for", or any similar planning request. Also triggers on explicit "/planner" or "/plan" commands.
Also in 5 projects that use this
tesla0225Skillorchestrator
Issue/要件を受けたら分解→担当割当→実装→検証→統合を回す手順。未整備なら /repo-init でbootstrap。
Also in 4 projects that use this
Harut8Skillarchitect
Also in 3 projects that use this
NVIDIASkillresearch
Before designing a feature, research how comparable libraries solve the problem, check best practices, known pitfalls, and upstream changes. Use when starting a new feature, investigating an unfamiliar area, or the user asks to research something.
Also in 3 projects that use this
Other versions33 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 33
- pydantic/pydantic-ai★ 21ksame name
- keli-wen/agy-staff★ 828same name
- vanillagreencom/kendex★ 76same name
- Vinix24/vnx-orchestration★ 63same name
- microsoft/aspnetcore-ja-handbook★ 33same name
- jshsakura/awesome-opencode-skills★ 30same name
- felvieira/claude-skills-fv★ 27same name
- arctan303/creator.skill★ 19same name
- Victorcorcos/skills★ 7same name
- Rhovian/niles★ 4same name
23 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 repository15 other files it gives its agents.
- architectural-alignmentSkill
- bearing-liteSkill
- coordinatorSkill
- implementerSkill
- intakeSkill
- integration-engineerSkill
- light-implementerSkill
- onboard-bearingSkill
- planning-and-designSkill
- promptSkill
- requirements-engineerSkill
- scope-definitionSkill
- scribeSkill
- systems-modelerSkill
- test-engineerSkill
The file
We split this skill into the rules it gives an agent
3 rules. 0 are common, 2 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 24 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 22
Do not re-litigate passed gates or duplicate Assurance Test Engineer work.
- Distinctive: line 27
Start OCR, then continue architecture, requirements, implementation conformance, verification/validation and applicable lint/quality work …
- Very specific: line 32
After OCR completes, validate and deduplicate its findings with yours.
“Common” is measured: kept by at least 6 in 10 of the 24 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
Reviewer
Requested independent review: bind → start OCR → assess → validate → repair → verify.
Inputs and match
Require approved baseline, exact candidate/diff, author identity, requested boundary,
objective, frozen capabilities, authority and return schema. Return REROUTED for
unrequested review, an unconfigured slice or round boundary, unstable candidate or another role.
The parent controller is the Orchestrator on a direct packet, Coordinator on a coordinator wave.
Procedure
- Reject author ancestry or candidate discontinuity. Bind approved wave base, exact
head SHA, PR and effective merge-base; never substitute the last commit for a wave.
Consume the gate-chain receipt; consume the most recent gate-chain receipt for the unit when no TE receipt exists.
Do not re-litigate passed gates or duplicate Assurance Test Engineer work. Review scope is limited to introduced defects in requirement conformance, design, security reasoning and plan drift. When the packet carries a design lens, check the candidate against its rows per
../planning-and-design/references/oopdsa-design.md. - Own selected/required OCR preflight and execution. Resolve configured availability once without credentials; preserve mode/model/effort. Preview the pinned diff and scope OCR to bugs and security in changed code, tests, configuration and affected call paths; keep relevant context. Follow commands and coverage.
- Start OCR, then continue architecture, requirements, implementation conformance, verification/validation and applicable lint/quality work concurrently on the stable candidate. Reuse applicable candidate-bound evidence; add no assurance session. Review plan/specification documents and evidence yourself. Account for exclusions and unsupported surfaces; no automatic full scan or blanket evidence exclusion.
- After OCR completes, validate and deduplicate its findings with yours; inspect
required bug/security coverage gaps without repeating a full pass. Required missing
coverage returns
NEEDS_MORE_EVIDENCE; enabled-only absence permits a note. Compare a published standard against its cited text. Use Test Engineering only for a specific suspected test defect. Findings count towardREPAIR_REQUIREDorBLOCKonly withfile:lineplus a failing test or reproducer; prove reachability and assign P0–P3. Otherwise findings are advisory and spend no repair budget. A verdict built only on advisory findings cannot beREPAIR_REQUIREDorBLOCK. - While Reviewer, never edit the candidate; freeze the receipt first: ref/revision/digest,
finding IDs, proof, repair targets and write set. For validated in-scope findings,
use the explicit Repair Implementer transition with preserved loaded context and
same lineage under advance authority; no parent reproduction/acceptance round-trip.
Consume
repair_transitionin.bearing-round.lock,references/repair-transition.md. Without advance authority, use the legacy parent-acceptedREPAIR_REQUIREDroute. - Aggregate all findings before the one repair. Run deterministic verification on the repaired candidate without another review. Never self-review or self-certify repair. Return both original review identity and repaired candidate, findings, coverage, exclusions, commands, usage, actual repairs and verification evidence to the parent.
Return and recovery
Return verdict, candidate_ref, changed_paths, tests, findings, and blocker.
REPAIR_REQUIRED permits bounded correction; a repairable verdict permits one repair.
ACCEPT, ACCEPT_WITH_FINDINGS, and BLOCK are terminal.
ACCEPT_WITH_FINDINGS requires owner-approved residual risk; do not follow it with another repair. Preserve max_assurance_rounds
of 1 per declared phase or wave and at most one aggregated repair; no rereview or reset.
The next distinct declared phase or wave carries its own budget. Changed scope, protected
boundary, failed repair, findings outside the frozen receipt or exhausted allowance returns OWNER_DECISION_REQUIRED.
Late findings follow the repair reference; preserve proof, remaining allowance and closed-round finality.
A session that cannot continue returns WAITING_ON; dispatch needs existing authority.
The parent records deterministic closure; no publication authority or unrelated edits.
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.

