Skip to main content

review-agent

Run a single named review agent against target files. Use this when the user names a specific agent (e.g. "run security-review", "check for test issues", "run js-fp-review on this file") rather than wanting the full suite. Prefer this over /code-review when only one concern is relevant or speed matters. Also used by the orchestrator for inline review checkpoints during Phase 3 implementation.

Source facts

Repository
bdfinst/agentic-dev-team
Last source activity
July 31, 2026 at 12:40
Detected SKILL.md language
English
Stars
299
Forks
36

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
review-agent
description
Run a single named review agent against target files. Use this when the user names a specific agent (e.g. "run security-review", "check for test issues", "run js-fp-review on this file") rather than wanting the full suite. Prefer this over /code-review when only one concern is relevant or speed matters. Also used by the orchestrator for inline review checkpoints during Phase 3 implementation.
argument-hint
<agent-name> [--since <ref>] [--path <dir>] [--internal] [--json]
user-invocable
true
allowed-tools
Read, Write, Grep, Glob, Bash(git diff *)
# Review Agent Role: worker. This skill performs the actual review using the agent definition as its specification. You have been invoked with the `/review-agent` skill. Run a single named review agent. This command is executed under orchestrator direction. Pass the named agent's `model:`/`effort:` frontmatter as declared — the harness resolves both fields natively before dispatch, per Model/Effort Resolution in `.claude/agents/orchestrator.md` (ADR 0026). ## Worker constraints 1. **Follow the agent definition exactly.** The agent file is your specification — detect what it says to detect, skip what it says to skip. 2. **Respect context needs.** When reviewing uncommitted changes or `--since`, honor the agent's `Context needs` field (diff-only, full-file, or project-structure). 3. **Do not add findings beyond the agent's scope.** If the agent says "Ignore: naming, tests" — do not flag naming or test issues. 4. **The structured JSON result (step 3) is the canonical output.** In `--json` mode it is the *only* thing written to stdout — no formatted summary, no report, no prose (see step 3c). Otherwise it is also rendered as a formatted summary (step 4) and written to the durable report (step 4b). 5. **Be concise.** Issue messages should be one sentence. Suggested fixes should be actionable, not explanatory. No preambles or filler. ## Parse Arguments Arguments: $ARGUMENTS Required: agent name (`$0`, e.g., `test-review`, `js-fp-review`, `security-review`) Optional: - `--since <ref>`: Review files changed since a git ref - `--path <dir>`: Target directory (default: current working directory) - `--internal`: This is an orchestrator-internal dispatch (e.g. `/build`'s Phase 3 inline checkpoints) — skip the `.dev-team-reports/` report write in step 4b. `/build` is the only sanctioned caller of this flag today. - `--json`: Machine-readable mode. Emit **only** the step-3 JSON result to stdout and nothing else — skip the formatted summary (step 4), skip the `.dev-team-reports/` report write (step 4b), and print no confirmation line, preamble, or trailing prose. Used by subprocess callers such as `/agent-eval --calibrate` that parse stdout and need a deterministic, model-independent result. See step 3c. ## Steps ### 1. Load agent definition Read `.claude/agents/<name>.md`. If the file doesn't exist, list available review agents from `.claude/agents/` (the Review Agents section of `knowledge/agent-registry.md` is the roster) and ask the user to pick one. ### 2. Determine target files Same auto-scope logic as `/code-review`: - If uncommitted changes exist: review those files - If working tree is clean: review all source files - `--since <ref>`: `git diff --name-only <ref>...HEAD` - `--path <dir>`: review files in that directory ### 3. Run review Follow the agent definition to review each target file. Produce a JSON result per the shared contract in [`knowledge/review-agent-output-contract.md`](../../knowledge/review-agent-output-contract.md), wrapped with `agentName`: ```json { "agentName": "<name>", "status": "pass|warn|fail|skip", "issues": [ { "severity": "error|warning|suggestion", "confidence": "high|medium|none", "file": "<path>", "line": 0, "message": "<description>", "suggestedFix": "<fix>" } ], "summary": "<summary>" } ``` ### 3b. Apply ACCEPTED-RISKS.md suppression Before reporting, consult `ACCEPTED-RISKS.md` at the repo root if present. For each issue, check rules in declaration order per `knowledge/accepted-risks-schema.md`. The first matching rule suppresses the issue from the displayed result and emits an audit entry of the form `SUPPRESSED: <file>:<line> [<rule_id>] by ACCEPTED-RISKS rule <rule.id>`. Expired rules become inert (stop suppressing). Schema-invalid rules fail the run with a specific parse error. Absent file: skip silently. ### 3c. `--json` mode (machine-readable output) When `--json` is passed, your **entire stdout response MUST be exactly one JSON object** matching the step-3 schema — nothing before it, nothing after it. Do **not** render the formatted summary (step 4), do **not** write the `.dev-team-reports/` report (step 4b), do **not** print a `Report written:` line, do **not** wrap the object in a code fence, and do **not** add any prose, preamble, or trailing commentary. ACCEPTED-RISKS suppression (step 3b) still applies — emit the post-suppression result. This mode exists so that subprocess callers (e.g. `/agent-eval --calibrate`) can parse the result deterministically across every model; any extra text breaks that contract. ### 4. Report **Skip this step entirely when `--json` was passed** (see step 3c) — stdout must be exactly the JSON object. Otherwise, display the result as a formatted summary with issues grouped by file. Include suggested fixes inline. If any issues were suppressed by ACCEPTED-RISKS, list them in a dedicated trailing section with rule ids for audit. ### 4b. Write the durable report (skip when `--internal` or `--json`) See `knowledge/report-output-location.md` for the shared write-scope convention this step follows. When neither `--internal` nor `--json` was passed, write the same formatted summary shown in step 4 to `.dev-team-reports/<agent-name>.md` in the target repository's working directory (creating `.dev-team-reports/` if absent), overwriting any existing file at that path — write it even when the review found zero issues. Print one confirmation line after the chat summary: `Report written: .dev-team-reports/<agent-name>.md`, or `Report written: .dev-team-reports/<agent-name>.md (replaced previous run)` when a file already existed at that path. If the write fails (permission/read-only): report `Cannot write .dev-team-reports/<agent-name>.md: <error>` to chat, and still return the JSON result and chat summary unchanged — the write failure is non-fatal and never blocks or alters the primary output. When `--internal` **was** passed (but not `--json`), skip this step entirely — behavior stays exactly as today (JSON + chat summary only). When `--json` was passed, this step is likewise skipped and stdout is the JSON object alone (step 3c).
View on GitHub