agentleFS
alphazedealphazede/bearing-lite/skills/reviewer/SKILL.md

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

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-devsSkill

    tester

    É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-willSkill

    planner

    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

  • tesla0225Skill

    orchestrator

    Issue/要件を受けたら分解→担当割当→実装→検証→統合を回す手順。未整備なら /repo-init でbootstrap。

    Also in 4 projects that use this

  • Harut8Skill

    architect

    Also in 3 projects that use this

  • NVIDIASkill

    research

    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

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
  1. Distinctive:

    Do not re-litigate passed gates or duplicate Assurance Test Engineer work.

    line 22
  2. Distinctive:

    Start OCR, then continue architecture, requirements, implementation conformance, verification/validation and applicable lint/quality work …

    line 27
  3. Very specific:

    After OCR completes, validate and deduplicate its findings with yours.

    line 32

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

  1. 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.
  2. 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.
  3. 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.
  4. 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 toward REPAIR_REQUIRED or BLOCK only with file:line plus 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 be REPAIR_REQUIRED or BLOCK.
  5. 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_transition in .bearing-round.lock, references/repair-transition.md. Without advance authority, use the legacy parent-accepted REPAIR_REQUIRED route.
  6. 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.