Quick review
Ad-hoc PR/diff/file review. No track context needed. Four dimensions — security, performance, correctness, maintainability. Use for one-off reviews when you don't have or don't need a Draft track.From its SKILL.md
npx -y skills add drafthq/draft --skill quick-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
9.1 KB, as published. Nobody here has run it
Quick Review
You are performing a lightweight, ad-hoc code review. This is the fast alternative to /draft:review — no track context needed, focused on a specific PR, diff, or file set.
MANDATORY GRAPH LOOKUP (read before dimension review)
When draft/graph/schema.yaml exists, this skill must follow the graph-first lookup contract in core/shared/graph-query.md §Mandatory Lookup Contract. Quick-review keeps the graph load light:
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="${DRAFT_PLUGIN_ROOT:-$(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"
- Always run
"$DRAFT_TOOLS/hotspot-rank.sh" --repo .for every changed file (Step 2 blast-radius pre-check below). - If a finding spans more than one file, run
"$DRAFT_TOOLS/graph-callers.sh" --repo . --symbol <name>to enumerate the call sites before claiming "no other usages".
Filesystem grep is reserved for source-text scans (literal strings, regex patterns). Symbol and caller discovery go through the graph.
Red Flags — STOP if you're
See shared red flags — applies to all code-touching skills.
Skill-specific:
- Reviewing without reading the code first
- Providing generic feedback not grounded in the actual code
- Missing security implications in authentication/authorization code
- Ignoring error handling paths
- Reviewing a whole module when asked for a specific file
Read the code. Ground every finding in a specific line.
Pre-Check
0. Capture Git Context
Before starting, capture the current git state:
git branch --show-current # Current branch name
git rev-parse --short HEAD # Current commit hash
Store this for the review report header. The review is scoped to this specific branch/commit.
1. Load Draft Context (if available)
ls draft/ 2>/dev/null
If draft/ exists, read and follow core/shared/draft-context-loading.md. This enriches review with project patterns, guardrails, and accepted patterns from tech-stack.md. Layer 0.5 of that procedure includes loading the relevant core/guardrails/language-standards.md section for the project stack — apply those standards in Dimension 4 (Maintainability) and Dimension 3 (Correctness) for language-specific patterns.
If no draft context, proceed with generic review — still valuable.
Step 1: Parse Arguments
Check for arguments:
/draft:quick-review— Review staged changes (git diff --cached) or current branch diff/draft:quick-review <file>— Review specific file(s)/draft:quick-review <PR-URL>— Review a pull request (via GitHub/GitHub MCP)/draft:quick-review <commit-range>— Review specific commits
Determine the diff to review:
- If PR URL: fetch via GitHub MCP (
get_change_detail,get_change_diff) or GitHub - If file path: read the file(s)
- If commit range:
git diff <range> - Default:
git diff HEAD~1..HEAD(last commit)
Step 2: Blast Radius Pre-check (if draft/graph/schema.yaml exists)
Before the four-dimension review, run "$DRAFT_TOOLS/hotspot-rank.sh" --repo . and check if any files in scope appear in the output. If any file has a fanIn in the top 20% of the list, add this warning at the top of the review report:
⚠ HIGH IMPACT: {file} is a high-fanIn hotspot (fanIn={N}). Changes here propagate to many callers — review with extra care.
If no hotspot data exists or no file matches, skip silently.
Step 3: Four-Dimension Review
Review the code across four dimensions. For each finding, cite the specific file:line.
Dimension 1: Security
Load core/guardrails/security.md before this dimension. Apply the 5-step security reasoning chain (identify goal → check hard red lines SEC-01…SEC-10 → assess blast radius → trace generative paths → classify). Any hard red line violation is automatically Critical.
If a violation has a // SECURITY-OVERRIDE: <ticket> <justification> annotation, downgrade to Important and include the ticket in the finding.
- Authentication/authorization gaps
[RC-005, SEC-10] - Input validation and sanitization
[RC-003] - SQL injection, XSS, CSRF vulnerabilities
[RC-002, RC-011, SEC-03] - Secrets or credentials in code
[RC-001, SEC-01] - Disabled TLS or certificate verification
[SEC-04] - Shell injection or unsafe subprocess calls
[SEC-06] - PII or credentials in log output
[RC-006, SEC-05] - OWASP Top 10 patterns
- Insecure deserialization
Dimension 2: Performance
- N+1 query patterns
- Missing indexes for frequent queries
- Unnecessary allocations in hot paths
- Missing caching opportunities
- Unbounded loops or recursion
- Large payload serialization
Dimension 3: Correctness
- Logic errors, off-by-one, null handling
- Race conditions in concurrent code
- Error handling gaps (uncaught exceptions, missing error paths)
- Edge cases not covered
- State management issues
- Contract violations (API, type, invariant)
Dimension 4: Maintainability
- Code clarity and naming
- DRY violations (repeated logic)
- Dead code or unreachable paths
- Missing or misleading comments
- Test coverage for new logic
- Consistency with project patterns (from tech-stack.md if available)
Step 4: Classify Findings
Classify each finding:
| Severity | Action | Description |
|---|---|---|
| Critical | Must fix before merge | Security vulnerabilities, data corruption risks, crashes |
| Important | Should fix | Performance issues, logic bugs, error handling gaps |
| Suggestion | Nice to have | Style improvements, refactoring opportunities, documentation |
Step 5: Generate Review Report
Present findings organized by severity:
## Quick Review: {scope description}
**Reviewer:** Draft Quick Review
**Scope:** {files/PR/commits reviewed}
**Date:** {ISO_TIMESTAMP}
### Summary
- Critical: {count}
- Important: {count}
- Suggestion: {count}
### Verdict: {PASS | PASS WITH NOTES | NEEDS CHANGES}
### Findings
#### Critical
1. **[finding title]** — `file:line`
[description and recommendation]
#### Important
...
#### Suggestion
...
### What Went Well
[2-3 positive observations about the code — good patterns, clean logic, thorough error handling]
If track-scoped, save to draft/tracks/<id>/quick-review-<timestamp>.md.
Also check core/guardrails/dependency-triage.md if the diff modifies a dependency manifest file.
MANDATORY: Include YAML frontmatter with git metadata when saving. Follow core/shared/git-report-metadata.md.
Include the report header table immediately after frontmatter:
| Field | Value |
|-------|-------|
| **Branch** | `{LOCAL_BRANCH}` → `{REMOTE/BRANCH}` |
| **Commit** | `{SHORT_SHA}` — {COMMIT_MESSAGE} |
| **Generated** | {ISO_TIMESTAMP} |
| **Synced To** | `{FULL_SHA}` |
Mandatory Self-Check (before review report)
Before printing the review report, internally verify and report:
- Graph files queried — JSONL files loaded plus any live graph query-tool invocations.
- Layer 1 files deliberately skipped — list any context sections skipped.
- Filesystem grep fallback justification — for every
grep/findrun, state the concept it searched for.
If draft/graph/schema.yaml does not exist, set Graph files queried: NONE and use justification graph data unavailable.
Graph Usage Report (append to review report)
Emit the canonical footer from core/shared/graph-usage-report.md §Canonical footer. The lint hook scripts/tools/check-graph-usage-report.sh validates the section on save.
Cross-Skill Dispatch
- Offered by:
/draft:implementat phase boundaries as lightweight alternative to full review - Escalates to:
/draft:reviewif critical findings require deeper analysis - Feeds into:
/draft:learn(findings update guardrails via pattern learning) - Suggests at completion:
- If many findings: "Consider running
/draft:reviewfor full three-stage analysis" - If security findings: "Consider running
/draft:deep-reviewfor security audit"
- If many findings: "Consider running
- Jira sync: If ticket linked, attach review and post summary via
core/shared/jira-sync.md
Error Handling
If no diff/file found: "No changes to review. Specify a file, PR URL, or commit range."
If MCP unavailable for PR: Fall back to local git diff. "GitHub/GitHub MCP unavailable. Reviewing local diff instead."
If no draft context: Proceed with generic review patterns. Note: "Review enriched when draft context is available (run /draft:init)."