Stats
Actions
Tags
From draft
Canonical code review command that runs three-stage reviews (automated validation, spec compliance, code quality) for tracks or project changes, and routes to specialist review workflows based on context.
How this skill is triggered — by the user, by Claude, or both
Slash command
/draft:reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are conducting a code review using Draft's Context-Driven Development methodology.
You are conducting a code review using Draft's Context-Driven Development methodology.
When draft/graph/schema.yaml exists, this skill must follow the graph-first lookup contract in core/shared/graph-query.md §Mandatory Lookup Contract. Stage 1 (Automated Validation) starts from the graph:
First resolve the bundled helpers:
# Locate Draft's bundled helpers (cwd is the user's project; ${CLAUDE_PLUGIN_ROOT}
# is not exported into skill Bash). See core/shared/tool-resolver.md.
DRAFT_TOOLS="$(cat ~/.cache/draft/plugin-root 2>/dev/null)/scripts/tools"
[ -d "$DRAFT_TOOLS" ] || DRAFT_TOOLS="$(ls -d ~/.claude/plugins/cache/*/draft/*/scripts/tools 2>/dev/null | sort -V | tail -1)"
[ -d "$DRAFT_TOOLS" ] || DRAFT_TOOLS="$(ls -d ~/.claude/plugins/marketplaces/*draft*/scripts/tools 2>/dev/null | tail -1)"
[ -d "$DRAFT_TOOLS" ] || DRAFT_TOOLS="$PWD/scripts/tools"
"$DRAFT_TOOLS/hotspot-rank.sh" --repo . and "$DRAFT_TOOLS/graph-impact.sh" (see Stage 1)."$DRAFT_TOOLS/graph-impact.sh" --repo . --file <path> to obtain the affected module set deterministically."$DRAFT_TOOLS/graph-callers.sh" --repo . --symbol <name> to enumerate downstream callers before judging breaking-change severity.Filesystem grep is reserved for source-text scans (string literals, log messages, regex matches in code) — not for discovering modules, files, or callers when the graph can answer.
See shared red flags — applies to all code-touching skills.
Skill-specific:
Read before you review. Evidence over opinion.
This command is the canonical review parent.
It orchestrates review workflows at two levels:
Specialist review workflows remain available:
/draft:quick-review/draft:bughunt/draft:deep-review/draft:assist-review/draft:review should remove the burden of choosing among them when the right depth is obvious from user intent or track state.
Important semantic note:
/draft:impact is not a review-depth mode in the current product. It measures project/track delivery telemetry, not code-change review depth. Do not route /draft:review to /draft:impact.Automated static validation (OWASP secrets, dead code, dependency cycles, N+1 patterns) is natively built into Stage 1 of this review.
Extract and validate command arguments from user input.
Explicit review modes:
quick - Route to /draft:quick-reviewbughunt - Route to /draft:bughuntdeep - Route to /draft:deep-reviewassist - Route to /draft:assist-reviewScope specifiers (mutually exclusive for baseline review):
track <id|name> - Review specific track (exact ID or fuzzy name match)project - Review uncommitted changes (git diff HEAD)files <pattern> - Review specific file pattern (e.g., src/**/*.ts)commits <range> - Review commit range (e.g., main...HEAD, abc123..def456)Quality integration modifiers:
with-bughunt - Include /draft:bughunt resultswith-assist - Include /draft:assist-review summaryfull - Enable all sensible add-ons for the selected scope (with-bughunt, with-assist, and any justified deep-review escalation)quick, bughunt, deep, assisttrack, project, files, commitsfull is present, enable with-bughunt and with-assist. Do not silently force deep; deep-review is module-scoped and must still satisfy escalation rules.If no arguments provided:
[~] In Progress track from draft/tracks.md[~] track, find first [ ] Pending trackAuto-detected track: <id> - <name> [<status>] and proceedIf the user explicitly invoked a specialist mode, route directly.
/draft:review quick ... → follow /draft:quick-review/draft:review bughunt ... → follow /draft:bughunt/draft:review deep ... → follow /draft:deep-review/draft:review assist ... → follow /draft:assist-reviewWhen routing, preserve any scope that can be mapped sensibly.
Examples:
/draft:review quick files "src/**/*.ts" → quick review of those files/draft:review bughunt track payments-refactor → bughunt scoped to that track/draft:review deep auth → deep-review of the auth module/draft:review assist track add-user-auth → reviewer-assist summary for that trackExplicit mode always wins over automatic escalation.
If no explicit mode is present, continue with the baseline /draft:review workflow below.
Based on parsed arguments, determine review scope and load appropriate context.
Trigger: track <id|name> argument OR auto-detected track
Check if argument is exact directory match:
ls draft/tracks/<arg>/ 2>/dev/null
If exists → use this track
Parse tracks.md for fuzzy matching:
draft/tracks.md--- separators./tracks/<id>/)### <id> - <name>)Handle matches:
Multiple tracks match '<input>':
1. <id> - <name> [<status>]
2. <id> - <name> [<status>]
Select track (1-N):
Once track is resolved:
Verify track directory exists:
ls draft/tracks/<id>/ 2>/dev/null
Read spec.md:
draft/tracks/<id>/spec.md2.5. Read hld.md and lld.md (when present):
draft/tracks/<id>/hld.md — extract §High-Level Design / Architecture, §Detailed Design (per-component subsections), §Dependencies, §Checklist (Performance/Scale/Security/Resiliency/Multi-tenancy/Upgrade/Cost), §Approvalsdraft/tracks/<id>/lld.md — extract §Classes and Interfaces (signatures, invariants), §Data Model (schemas, migrations), §Error Handling, §Observability metricsRead plan.md:
draft/tracks/<id>/plan.md[x] task lines only. Match pattern: 7+ character hex strings in parentheses, regex \(([a-f0-9]{7,})\). Example: - [x] **Task 1.1:** Description (7a7dc85). Collect SHAs in order of appearance; deduplicate keeping first occurrence.git rev-parse <first_SHA>^ 2>/dev/null<first_SHA>^..<last_SHA> as the rangegit rev-parse fails): use the empty tree SHA 4b825dc642cb6eb9a060e54bf8d69288fbee4904 as the range start, i.e., 4b825dc642cb6eb9a060e54bf8d69288fbee4904..<last_SHA>. Alternatively, for single-commit ranges, use git diff-tree --root -p <first_SHA> to obtain the diff.<last_SHA>Check for incomplete work:
[ ], [~], [x], [!] tasks[ ] or [~] tasks exist: Display warning and proceed:
Warning: Track has N incomplete tasks (M in-progress, K pending). Reviewing completed work only.
Handle missing files:
Trigger: project, files <pattern>, commits <range> argument, or no active track with local changes
project argument:
git diff HEADfiles <pattern> argument:
git diff HEAD -- <pattern>git ls-files <pattern> | head -1
commits <range> argument:
git rev-parse <range> 2>/dev/null
git diff <range>For project-level reviews (no track context):
Load Draft context (if available):
Read and follow the base procedure in core/shared/draft-context-loading.md.
Note limitations:
After scope is resolved, decide whether baseline /draft:review should proceed as the full three-stage review or should delegate to a specialist by default.
/draft:reviewTiny ad-hoc scope with no track context
If scope is project/files/commits and the diff is small, prefer /draft:quick-review.
Good signals:
Track-complete or handoff review
If the review is track-scoped and the output is likely for another reviewer or approver, attach /draft:assist-review unless the user explicitly opted out.
Good signals:
full or with-assist modifier presentHigh defect-risk changes
If the diff touches high-risk surfaces, attach /draft:bughunt.
Good signals:
full or with-bughunt modifier presentSingle-module structural risk
If the review scope maps cleanly to one high-risk module, attach /draft:deep-review.
Good signals:
If the diff spans many modules, do not auto-run multiple deep reviews. Instead, finish baseline review and recommend targeted deep-review follow-ups for the highest-risk modules.
Even when no specialist command is attached:
Example:
Running /draft:review
- baseline three-stage review
- bughunt attached because auth and persistence paths changed
- assist-review attached because this is a completed track handoff
If the heuristic selects /draft:quick-review instead of baseline review, route there directly and stop this workflow.
Generate diff output using smart chunking to avoid context overflow.
Run shortstat to check diff size:
git diff --shortstat <range>
Parse output robustly — handle both singular (1 file changed) and plural (N files changed) forms. Extract numeric values for files, insertions, and deletions. Use total lines changed (insertions + deletions) for the chunking threshold.
Small/Medium changes (<300 lines changed):
git diff <range>
Large changes (≥300 lines changed):
git diff --name-only <range>
[N/M] Reviewing <filename>git diff <range> -- <file>Skip non-source files to focus review:
*.lock, package-lock.json, yarn.lock, *.min.js, *.min.css, *.mapdist/, build/, target/, out/, __pycache__/, *.pycnode_modules/, vendor/, .git/@generated marker (case-insensitive, any comment syntax: /* @generated */, // @generated, # @generated)Apply a three-stage review process (merging static validation and semantic review).
Goal: Detect structural, security, and performance issues using fast, objective searches across the diff.
Load plugin guardrails before scanning: core/guardrails/review-checks.md (RC-###), core/guardrails/security.md (SEC-##), and the relevant core/guardrails/language-standards.md section for the detected stack. draft/guardrails.md project rules take precedence on any conflict.
Hard red line violations (SEC-01…SEC-10) are always Critical and block review approval. If the violation has a // SECURITY-OVERRIDE: <ticket> <justification> annotation, downgrade to Important and record the ticket in the report.
Read-before-report gate (Ground-Truth Discipline G1): Static checks (grep, scanner output) identify candidate findings. Every candidate that survives to the final review report must be backed by an actual Read of the cited file in this session. A grep hit on dangerouslySetInnerHTML is a candidate; only after opening the file and checking surrounding context (sanitiser? test/mock file? feature flag?) does it become a reported finding. Filing findings directly from grep output is the dominant false-positive source in review skills — do not do it.
For the files changed in the diff, perform static checks using grep or similar tools:
Blast Radius Assessment (if the draft/graph/ snapshot exists):
First resolve the bundled helpers:
# Locate Draft's bundled helpers (cwd is the user's project; ${CLAUDE_PLUGIN_ROOT}
# is not exported into skill Bash). See core/shared/tool-resolver.md.
DRAFT_TOOLS="$(cat ~/.cache/draft/plugin-root 2>/dev/null)/scripts/tools"
[ -d "$DRAFT_TOOLS" ] || DRAFT_TOOLS="$(ls -d ~/.claude/plugins/cache/*/draft/*/scripts/tools 2>/dev/null | sort -V | tail -1)"
[ -d "$DRAFT_TOOLS" ] || DRAFT_TOOLS="$(ls -d ~/.claude/plugins/marketplaces/*draft*/scripts/tools 2>/dev/null | tail -1)"
[ -d "$DRAFT_TOOLS" ] || DRAFT_TOOLS="$PWD/scripts/tools"
"$DRAFT_TOOLS/hotspot-rank.sh" --repo . output — if yes, record its fanIn value"$DRAFT_TOOLS/graph-arch.sh" --repo . | jq '.packages[].fan_in' (how many modules depend on this module)Blast Radius line in the Stage 1 report summary: Blast Radius: HIGH | MEDIUM | STANDARD — <N> changed files affect high-fanIn modules: [file list]Architecture Conformance: Search for pattern violations documented in draft/.ai-context.md. (e.g. import * from 'database' in a React component).
Dead Code: Check for newly exported functions/classes in the diff that have 0 references across the codebase.
Dependency Cycles: Trace the import chains for new imports to ensure no circular dependencies (e.g., A → B → C → A) are introduced.
Graph Boundary Check (if draft/graph/schema.yaml exists) [RC-013]:
"$DRAFT_TOOLS/graph-arch.sh" --repo . package fan-in/outSecurity Scan [RC-001, RC-002, RC-003, RC-011]:
[RC-001][RC-002]innerHTML or raw DOM insertion) [RC-011][RC-003]Dependency Manifest Check [RC-014]: If diff modifies package.json, requirements.txt, go.mod, Cargo.toml, pom.xml, or build.gradle, run the project's configured dependency vulnerability scanner (from draft/tech-stack.md) or recommend npm audit / pip-audit / cargo audit as appropriate. Include results in Stage 1 findings.
Performance Anti-patterns: Scan the diff for:
Context-Specific Checks: Identify the primary domain of changed files and apply domain-specific checks:
auth, crypto, security, token, password, hash, encrypt):
== for secret comparison)Math.random() for security)migration, schema, model, entity, repository):
controller, handler, route, endpoint, resolver) [RC-005, RC-012]:
[RC-012][RC-003][RC-005]config, env, settings):
component, view, page, template):
innerHTML, dangerouslySetInnerHTML, v-html)Breaking Change Detection [RC-012]: Check for public API changes in the diff:
Threat Model (STRIDE): For new endpoints or data mutations, check:
Verdict:
After completing Stage 1, recommend appropriate static analysis tools based on the project's tech-stack.md. Check if these tools are already configured in CI; if not, recommend adding them.
| Language | Recommended Tools |
|---|---|
| JavaScript/TypeScript | ESLint with eslint-plugin-security, Semgrep |
| Python | Bandit, Semgrep, pylint |
| Java | Error Prone, SpotBugs, Semgrep |
| Go | gosec, staticcheck |
| Rust | cargo clippy, cargo audit |
| C/C++ | Clang Static Analyzer, cppcheck |
| Multi-language | Semgrep (https://semgrep.dev/), CodeQL (semantic code analysis) |
References: Meta Infer for CI integration patterns, Google Error Prone for compile-time analysis.
Include tool recommendations in the review report under Stage 1 as a "Recommended Tooling" subsection. Only recommend tools relevant to the languages detected in the diff.
Skip for project-level reviews (no spec exists)
Load spec.md acceptance criteria and verify implementation:
For each functional requirement in spec.md:
For each criterion in spec.md:
Verdict:
Skip if no hld.md — fall through to Stage 3.
/draft:upload Step 3.1 logic)For every component subsection in HLD §Detailed Design:
path:lineWhitebox requirements addressed list is non-emptyFor criticality ∈ {high, mission-critical} (frontmatter):
Verdict:
Run for both track-level (if Stage 2 passes) and project-level reviews
Analyze semantic code quality across four dimensions:
.ai-context.md exists — check ## Critical Invariants section)For each flagged function, report: file path, function name, estimated complexity, and recommended action (split, extract, simplify).
If Stage 3 produces zero findings across all four dimensions, do NOT accept "clean" without this gate. This pass is mandatory, not optional — a "zero findings" verdict that did not complete it is incomplete and must be flagged in the report.
Answer each of the 7 questions explicitly with file:line evidence (not "looks fine"):
guardrails.md? Cite the rule..ai-context.md? Cite the invariant.Document the pass in the review report:
"Adversarial pass: 7/7 answered with evidence. [one line per question with
file:lineor 'N/A — ']."
A review verdict of "clean / LGTM" without this filled-in block is non-conforming and must not be emitted. Skipping the pass is a Ground-Truth Red Flag G4 violation (claim about absence-of-issues from incomplete examination).
Classify all findings by severity:
| Severity | Definition | Action |
|---|---|---|
| Critical | Blocks release, breaks functionality, security issue | Must fix before proceeding |
| Important | Degrades quality, technical debt | Should fix before phase complete |
| Minor | Style, optimization, nice-to-have | Note for later, don't block |
Scope-specific behavior:
spec.md acceptance criteria loaded in Step 2.Issue format:
- [ ] [File:line] Description of issue `[RC-### or CQ-### or SEC-## if applicable]`
- **Impact:** [what breaks/degrades]
- **Suggested fix:** [how to address]
Cite the most specific guardrail rule ID that applies. If no numbered rule covers the finding, omit the citation — the finding is still valid.
Run the specialist workflows selected explicitly or by the Step 2.5 heuristics.
Track-level:
/draft:bughunt --track <id>
Project-level:
/draft:bughunt
Parse output from draft/tracks/<id>/bughunt-report-latest.md or draft/bughunt-report-latest.md
If with-assist, full, or handoff heuristics selected assist-review:
/draft:assist-review for the same track contextAppend this as a dedicated section in the final review report rather than merging it into bug findings.
If deep-review escalation is justified and the scope maps to one dominant module:
/draft:deep-review <module>Deep Review Escalation section in the reportIf deep-review is recommended but not auto-run:
Next Actions row pointing to /draft:review deep <module> or /draft:deep-review <module>Merge findings from:
Deduplication:
Create unified review report in markdown format.
MANDATORY: Include YAML frontmatter with git metadata. Follow the procedure in core/shared/git-report-metadata.md to gather git info, generate frontmatter, and include the report header table. Use generated_by: "draft:review".
Path: draft/tracks/<id>/review-report-<timestamp>.md (where <timestamp> is generated via date +%Y-%m-%dT%H%M, e.g., 2026-03-15T1430)
After writing the timestamped report, create a symlink pointing to it:
ln -sf review-report-<timestamp>.md draft/tracks/<id>/review-report-latest.md
[YAML frontmatter — see core/shared/git-report-metadata.md, use track_id: "<id>"]
# Review Report: <Track Title>
[Report header table — see core/shared/git-report-metadata.md]
**Track ID:** <id>
**Reviewer:** [Current model name and context window from runtime]
**Commit Range:** <first_SHA>^..<last_SHA>
**Diff Stats:** N files changed, M insertions(+), K deletions(-)
---
## Stage 1: Automated Validation
**Status:** PASS / FAIL
- **Blast Radius:** HIGH | MEDIUM | STANDARD — [list hotspot files if HIGH/MEDIUM]
- **Architecture Conformance:** PASS/FAIL
- **Dead Code:** N found
- **Dependency Cycles:** PASS/FAIL
- **Security Scan:** N issues found
- **Dependency Vulnerabilities:** N Critical / N High (or "Clean" if scanner found none)
- **Performance:** N anti-patterns detected
[If FAIL: List critical structural issues and stop here]
---
## Stage 2: Spec Compliance
**Status:** PASS / FAIL
### Requirements Coverage
- [x] Requirement 1 - Implemented in <file:line>
- [x] Requirement 2 - Implemented in <file:line>
- [ ] Requirement 3 - **MISSING**
### Acceptance Criteria
- [x] Criterion 1 - Verified in <file:line>
- [x] Criterion 2 - Verified in <file:line>
- [ ] Criterion 3 - **NOT MET**
[If FAIL: List gaps and stop here]
---
## Stage 3: Code Quality
**Status:** PASS / PASS WITH NOTES / FAIL
### Critical Issues
[None / List with file:line]
### Important Issues
[None / List with file:line]
### Minor Notes
[None / List items]
---
[If with-bughunt or full]
## Integrations
### Bug Hunt Results
- **Critical:** N found
- **Important:** N found
- **Minor:** N found
- Full report: `./bughunt-report-latest.md`
---
## Summary
**Total Semantic Issues:** N
- Critical: N
- Important: N
- Minor: N
**Verdict:** PASS / PASS WITH NOTES / FAIL
**Required Actions:**
1. [Action item if any]
2. [Action item if any]
---
## Recommendations
[If incomplete tasks found]
⚠️ **Warning:** This track has N incomplete tasks. Consider completing all tasks before marking track as done.
[If no critical issues]
✅ **No blocking issues found.** This track is ready to merge.
[If critical issues found]
❌ **Critical issues must be resolved before proceeding.**
Path: draft/review-report-<timestamp>.md (where <timestamp> is generated via date +%Y-%m-%dT%H%M, e.g., 2026-03-15T1430)
After writing the timestamped report, create a symlink pointing to it:
ln -sf review-report-<timestamp>.md draft/review-report-latest.md
Similar format but:
project: "Scope: Uncommitted changes"files <pattern>: "Scope: Files matching ''"commits <range>: "Scope: Commits "-latest.md symlink always points to the most recent report-latest.md symlink exists (read its target to determine the previous timestamp)Previous timestamped reports are preserved. The -latest.md symlink always points to the most recent report.
For track-level reviews, update metadata.json with review status.
Condition: Always update metadata after generating the review report, regardless of verdict. This ensures review history is tracked for all outcomes (PASS, PASS_WITH_NOTES, or FAIL).
Load draft/tracks/<id>/metadata.json
{
"id": "<track_id>",
...
"lastReviewed": "<ISO timestamp>",
"reviewCount": N,
"lastReviewVerdict": "PASS" | "PASS_WITH_NOTES" | "FAIL"
}
Increment reviewCount on each review.
Save updated metadata.json
Display summary to user with actionable next steps.
✅ Review complete: <track_id>
Report: draft/tracks/<id>/review-report-<timestamp>.md (symlink: review-report-latest.md)
Summary:
- Stage 1 (Automated Validation): PASS
- Stage 2 (Spec Compliance): PASS
- Stage 3 (Code Quality): PASS WITH NOTES
- Total semantic issues: 12 (0 Critical, 3 Important, 9 Minor)
[If full]
Additional Checks:
- Bug Hunt: 5 medium-severity findings
Verdict: PASS WITH NOTES
Recommended actions:
1. Fix 3 Important issues (see report)
2. Review 9 Minor notes for future improvements
Next: Address findings and run /draft:review again, or mark track complete.
❌ Review failed: <track_id>
Report: draft/tracks/<id>/review-report-<timestamp>.md (symlink: review-report-latest.md)
Stage 1 (Automated Validation): PASS
Stage 2 (Spec Compliance): FAIL
- 3 requirements not implemented
- 2 acceptance criteria not met
Stage 3: SKIPPED (Stage 2 must pass first)
Verdict: FAIL
Required actions:
1. Implement missing requirements (see report)
2. Meet all acceptance criteria
3. Run /draft:implement to resume work
Next: Fix gaps and run /draft:review again.
Error: Draft not initialized.
Run /draft:init to set up Context-Driven Development.
Error: No tracks found in draft/tracks.md
Run /draft:new-track to create your first track.
Error: Track 'xyz' not found.
Did you mean:
1. add-review-command
2. enterprise-readiness
Use exact track ID or run /draft:status to see all tracks.
Multiple tracks match 'review':
1. add-review-command - Add /draft:review Command [~]
2. review-architecture-md - Review architecture.md [x]
Select track (1-2):
Error: Invalid commit range 'main...feature'
Git error: fatal: ambiguous argument 'feature': unknown revision
Verify the range exists:
git log main...feature
⚠️ Warning: No commit SHAs found in plan.md
Cannot determine commit range for review.
Options:
1. Manually specify range: /draft:review track <id> commits <range>
2. Review uncommitted changes: /draft:review project
| Don't | Instead |
|---|---|
| Skip Stage 1 (Automated Validation) | Always run automated checks first |
| Skip Stage 2 (Spec Compliance) | Always verify spec compliance before quality checks |
| Run Stage 3 when Stage 2 fails | Fix spec gaps before quality checks |
| Ignore incomplete tasks | Warn user, suggest completing work first |
| Auto-fix issues found | Report only, let developer decide |
| Batch multiple tracks | Review one track at a time |
After generating the review report, execute the pattern learning phase from core/shared/pattern-learning.md to update draft/guardrails.md with patterns discovered during this review.
/draft:review
/draft:review track add-user-auth
/draft:review track "user authentication"
/draft:review track add-user-auth full
/draft:review project
/draft:review files "src/**/*.ts"
/draft:review commits main...feature-branch
/draft:review track my-feature with-bughunt
/draft:review quick files "src/**/*.ts"
/draft:review deep auth
/draft:review assist track my-feature
Every review report must end with a ## Next Actions section listing the smallest set of follow-ups in execution order. Use this exact shape:
## Next Actions
| # | Action | Owner | Blocker? | Skill / Command |
|---|---|---|---|---|
| 1 | <imperative one-liner> | <author\|reviewer\|TBD> | yes/no | `/draft:<skill> <args>` or `n/a` |
Rules:
Blocker? = yes); proceeding to merge is forbidden until cleared./draft:debug, /draft:regression, /draft:tech-debt, /draft:bughunt, /draft:adr). Otherwise put n/a./draft:coverage and include results in review reportAfter review completion, based on findings:
If significant code quality findings:
"Review complete. Consider:
→ /draft:tech-debt — Catalog and prioritize the technical debt found"
If new public APIs lack documentation:
→ /draft:documentation api — Document new API endpoints"
If undocumented design decisions discovered:
→ /draft:adr — Record architectural decisions found during review"
If Jira ticket linked, sync via core/shared/jira-sync.md:
review-report-latest.md to ticketBefore printing the final verdict, internally verify and report:
get_architecture, hotspot-rank.sh, graph-impact.sh, graph-callers.sh, cycle-detect.sh).grep/find run, state the concept it searched for. Source-text scans (string literals, regex matches in code) are exempt — they are not symbol/file discovery.If draft/graph/schema.yaml does not exist, set Graph files queried: NONE and use justification graph data unavailable.
Emit the canonical footer from core/shared/graph-usage-report.md. The lint hook scripts/tools/check-graph-usage-report.sh validates the section on save.
As the last step after saving the review report, emit a metrics record. Best-effort — never block.
Payload fields:
{
"skill": "review",
"track_id": "<track_id or null>",
"stage_reached": "stage1|stage2|stage3",
"verdict": "PASS|PASS_WITH_NOTES|NEEDS_CHANGES|FAIL",
"critical_count": <N>,
"important_count": <N>,
"blast_radius": "HIGH|MEDIUM|STANDARD",
"graph_queries": <N>,
"fallback_grep_count": <N>
}
Emit call:
# Locate Draft's bundled helpers (cwd is the user's project; ${CLAUDE_PLUGIN_ROOT}
# is not exported into skill Bash). See core/shared/tool-resolver.md.
DRAFT_TOOLS="$(cat ~/.cache/draft/plugin-root 2>/dev/null)/scripts/tools"
[ -d "$DRAFT_TOOLS" ] || DRAFT_TOOLS="$(ls -d ~/.claude/plugins/cache/*/draft/*/scripts/tools 2>/dev/null | sort -V | tail -1)"
[ -d "$DRAFT_TOOLS" ] || DRAFT_TOOLS="$(ls -d ~/.claude/plugins/marketplaces/*draft*/scripts/tools 2>/dev/null | tail -1)"
[ -d "$DRAFT_TOOLS" ] || DRAFT_TOOLS="$PWD/scripts/tools"
[ -x "$DRAFT_TOOLS/emit-skill-metrics.sh" ] && bash "$DRAFT_TOOLS/emit-skill-metrics.sh" \
'{"skill":"review","track_id":"<id_or_null>","stage_reached":"<stage>","verdict":"<v>","critical_count":<N>,"important_count":<N>,"blast_radius":"<br>","graph_queries":<N>,"fallback_grep_count":<N>}'
npx claudepluginhub drafthq/draft --plugin draftMulti-phase code review pipeline with mechanical checks, graph-scoped context, parallel review agents, cross-agent deduplication, and structured output. Use for completed work reviews.
Static code review of the active diff: trace changed paths and report P1/P2/P3 bugs with file:line evidence. Use for code review or bug checks.
Performs structured code reviews using tiered persona agents, confidence-gated findings, and merge/dedup pipeline on code changes or PRs before merging.