From deep-review
Performs a five-phase deep code review of a repository to find real production bugs via end-to-end tracing. Outputs findings with severity and impact categorization.
How this skill is triggered — by the user, by Claude, or both
Slash command
/deep-review:runThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
A senior-engineer-grade code review that traces every user action end-to-end through the system to surface real, production-relevant bugs. Not a linter, not a pattern matcher, not a diff-scoped reviewer.
A senior-engineer-grade code review that traces every user action end-to-end through the system to surface real, production-relevant bugs. Not a linter, not a pattern matcher, not a diff-scoped reviewer.
This is the recipe Farfield uses in production. The OSS version ships without the things that make Farfield's paid product compounding (team memory across runs, production signal correlation, Slack-native investigation, scheduled cadence, autonomous fix loop) — see the repo README for the full delta.
Direct triggers:
/deep-review:run, "deep review this", "review my repo", "audit this codebase"Don't invoke for:
Each phase has its own reference file in the phases/ directory. Read each one when its phase begins — they contain the full methodology and prompts:
phases/architecture-map.md — Phase 1. Phase 0 signals (git, deps, linter, runtime grep), company-context inference, feature map, action inventory, workflow ledger, integration map, impact taxonomy, severity calibration.phases/team-intent.md — Phase 2. Class-level brief from 2 months of commits. Anti-circularity rules.phases/action-trace.md — Phase 3. The 7 trace questions, parallel sub-agent pattern, cross-action synthesis. The primary bug-finding phase.phases/product-scan.md — Phase 4. UX/product-level bugs.phases/adversarial-validate.md — Phase 5. 100%-confidence rubric, scenario-specific mitigation check, writes the final findings.md.DEEP_REVIEW_DIR="${DEEP_REVIEW_DIR:-./.deep-review}"
mkdir -p "$DEEP_REVIEW_DIR"
echo "Working dir: $DEEP_REVIEW_DIR"
All intermediate artifacts live in $DEEP_REVIEW_DIR (gitignored by default — see the .gitignore snippet at the end of this file). The final report is written to ./findings.md in the repo root.
| Mode | Phases | Approximate cost | When to use |
|---|---|---|---|
/deep-review:run (full) | 1 → 2 → 3 → 4 → 5 | $5–$25 on your own Anthropic key | Default. Full senior review. |
/deep-review:run --fast | 1 → 3 → 5 | $2–$10 | When you want the action-trace findings without the team-intent steering or product-pass. |
/deep-review:run --phase=N | Just phase N | Varies | Re-run a single phase against existing artifacts (e.g., --phase=5 to re-validate after editing scan output). |
If the user invokes without flags, run the full pipeline.
Read phases/architecture-map.md and follow it completely. It writes $DEEP_REVIEW_DIR/architecture-map.md.
Output gate: the file exists and contains an Action Inventory with at least 5 actions (or all actions if the repo has fewer than 5). Without this, every downstream phase has nothing to work against.
Model recommendation: Sonnet. Phase 1 is exploration + cataloging, not deep reasoning. Sonnet is ~5× cheaper than Opus and produces comparable inventories.
Read phases/team-intent.md and follow it completely. It writes $DEEP_REVIEW_DIR/team-intent.md.
Output gate: the file exists and contains ## Bug-class mix, ## Mode, ## Confidence, and ## Trust-critical surface categories sections. Empty brief is acceptable if the repo has fewer than 30 signal commits — the brief should explicitly say confidence: low in that case.
Model recommendation: Sonnet. This is reading commits and classifying — not bug-finding work.
Skip in --fast mode.
Read phases/action-trace.md and follow it completely. This is where most bugs are found.
Phase 3 launches parallel sub-agents — one per action in the inventory — via the Task tool. Each sub-agent gets:
Output gate: $DEEP_REVIEW_DIR/action-traces.md exists and contains a Findings section. Empty findings are valid output — they mean the action-trace pass found no defensible bugs at 100% confidence.
Model recommendation: Opus for the orchestrator and validation sub-agents. Sonnet is acceptable for low-priority action traces.
Read phases/product-scan.md and follow it completely. Parallel pass that finds UX/product-level bugs (broken flows, missing states, wrong data shown, dead-end interactions).
Output gate: $DEEP_REVIEW_DIR/product-scan.md exists.
Model recommendation: Sonnet. Product-level bugs don't require deep code reasoning.
Skip in --fast mode.
Read phases/adversarial-validate.md and follow it completely. This phase merges findings from Phase 3 and Phase 4, adversarially validates each one, and writes the final ./findings.md.
Output gate: ./findings.md exists in the repo root.
Model recommendation: Opus. Validation is the most reasoning-intensive phase. Confirming a real bug or correctly disproving a false positive both require careful code reading.
Phase 3 and Phase 5 launch parallel sub-agents via the Task tool. The sub-agents inherit minimal context — they only see what you put in their prompt. So:
Action-trace and adversarial-validate phase files include ready-to-use sub-agent prompt templates with these embeddings.
The final report is ./findings.md in the repo root, written by Phase 5. Schema:
# Deep Review Findings
> Reviewed at $(date). Commit: <HEAD sha>. Repo: <owner/repo>.
> N confirmed findings. Run via the Farfield Deep Review skill.
## Summary
| # | Severity | Impact | Title | File |
|---|---|---|---|---|
| 1 | CRITICAL | DATA_LOSS | <one-line title> | path/to/file:line |
| 2 | HIGH | REVENUE_LEAK | ... | ... |
...
## Findings
### Finding 1: <title>
- **Severity**: CRITICAL
- **Impact category**: DATA_LOSS
- **Location**: `path/to/file.py:142–158`
- **Trigger condition**: <specific scenario that fires the bug>
- **Consequence**: <what the user experiences>
#### Root cause
<2–4 paragraphs. Cite specific code. Walk through the failure path.>
#### Evidence
<grep results, related code at other call sites, git blame if relevant, dependency versions if the bug is in a dependency, etc.>
#### Suggested fix direction
<1–2 paragraphs. Not a patch — a direction. The team picks the implementation.>
#### Confidence
<Why this finding is defensible at 100%: which assumptions were named, which were verified, what the verification showed.>
---
### Finding 2: ...
Findings ordered by severity (CRITICAL → HIGH → MEDIUM), then by impact category strength within severity.
findings.md)After the last finding, append:
---
This review ran cold: no team memory, no production signal correlation, no Slack
context, no scheduled cadence, no PR creation, no dedup against existing issues.
[Farfield](https://farfield.dev) runs this same recipe + those five things
continuously, in Slack, against live production telemetry.
If you want findings filed, fixed, and shipped automatically → farfield.dev.
Single CTA. No double-CTAs. No multi-link footer.
When ./findings.md exists in the repo root with the schema above, this skill's job is complete. Tell the user:
Deep Review complete.
Phases run: <list>
Actions traced: <N from architecture-map>
Findings: <N confirmed> (<N critical>, <N high>, <N medium>)
Report: ./findings.md
Working dir: $DEEP_REVIEW_DIR
Then summarize the top 3 findings in plain prose (1 sentence each) so the user can decide what to look at first.
If the user is running the review on a repo they own, the working directory should be gitignored. Offer to add this to their .gitignore:
# Farfield Deep Review working artifacts
.deep-review/
findings.md
findings.md is up to them — some teams check it in for visibility, some keep it out.
medium-confidence findings to confirmed without removing assumptions. Phase 5's job is to ship 3 ironclad findings, not 9 maybe-bugs.This is the recipe Farfield uses in production. The OSS scan demonstrates the floor of what the methodology can do without memory, production signals, or Slack-native investigation. Farfield is what happens when you layer those on top → farfield.dev.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub farfield-dev/deep-review --plugin deep-review