agents/skills/review/SKILL.md
Code review panel for current branch changes. Use for reviewing PR changes, code review, or getting feedback on branch changes.
npx skillsauth add drn/dots reviewInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Run a comprehensive code review (security, architecture, clarity) against your current changes.
$ARGUMENTS - Optional: branch or commit range to review (defaults to current branch vs main/master)git branch --show-currentgit branch -r 2>/dev/null | grep -oE 'origin/(main|master)' | head -1git diff --stat HEAD...origin/main 2>/dev/null | head -50git diff --stat HEAD...origin/master 2>/dev/null | head -50This skill participates in a phase chain. Read ~/.claude/skills/_shared/resources/phase-protocol.md for the full protocol.
Before starting: Check .context/phases/ for prior artifacts:
plan-*.md for the original intent and decisions — review the diff against plan expectations, flagging deviations.build-*.md for what was built and any notes from the implementer.After Step 4 (report): Write a review-{ts}.md artifact to .context/phases/ (create with mkdir -p .context/phases). The Handoff section should state: PASS (ready to ship) or FAIL (needs changes, list what), plus any warnings /pr should include in the PR description.
You run a code review and produce a consolidated report.
IF $ARGUMENTS contains a branch name or commit range:
Use that as the review scope
ELSE:
Review current branch changes vs the default branch (main/master)
Gather the diff:
git diff {base}...HEAD # full diff
git diff {base}...HEAD --name-only # changed files
If there are no changes to review, tell the user and stop.
Read the full content of each changed file for context. The reviewer needs to see the code around the changes, not just the diff.
Use 1 Task tool call with subagent_type="general-purpose", model: "sonnet":
Review the following code changes for security, architecture, and clarity.
DIFF:
{full diff}
CHANGED FILES:
{full file contents}
CHECK EACH -- SECURITY:
- Injection flaws (SQL, command, LDAP, XPath)
- Authentication/authorization issues
- Sensitive data exposure (secrets, PII, credentials in code or logs)
- Input validation and sanitization
- XSS potential
- Insecure deserialization
- Vulnerable dependencies added
- Error handling exposing internals
- Missing rate limiting
- Insecure direct object references
CHECK EACH -- ARCHITECTURE:
- Single Responsibility Principle
- Separation of concerns
- Dependency direction (abstractions over concretions)
- Coupling level
- Cohesion
- Consistency with existing codebase patterns
- Error handling strategy
- Extensibility for likely changes
- Circular dependencies
CHECK EACH -- CLARITY:
- Function/method naming clarity
- Variable naming
- Comments where logic is non-obvious
- Public API documentation
- Cyclomatic complexity
- Dead code or unreachable branches
- Magic numbers/strings
- Consistent code style
- Log message quality
Classify each finding as:
- BLOCKING: Must fix before merging
- WARNING: Should fix, real risk
- INFO: Improvement suggestion
Tag each finding with its category: [security], [architecture], or [clarity].
If no issues in a category: explicitly state so.
Output your findings grouped by severity (BLOCKING first, then WARNING, then INFO).
After the reviewer completes, consolidate into:
# Code Review: {branch name}
## Summary
{1-2 sentences: what the changes do and overall assessment}
## Blocking Issues
{Numbered list with category tag, file, line, description -- or "None"}
## Warnings
{Numbered list -- or "None"}
## Suggestions
{Numbered list -- or "None"}
## Verdicts
| Category | Verdict | Key Notes |
|----------|---------|-----------|
| Security | PASS / CONCERNS | {1-line} |
| Architecture | PASS / CONCERNS | {1-line} |
| Clarity | PASS / CONCERNS | {1-line} |
## Files Reviewed
{git diff --stat output}
If there are blocking issues, note: "Address the blocking issues before merging." If clean: "Changes look good across all review dimensions."
development
Walk every unresolved review thread on a PR, triage each one, reply with a rationale of whether or not the comment will be acted upon, make the code change if warranted, and mark the thread resolved. Use when the user asks to address only the open PR comments without re-running CI, respond to review feedback, resolve review threads, or clear bot comments on a PR.
tools
Iteratively run /rereview, fix the findings, and loop until reviewers approve clean. Use for iterative automated review, when you want /rereview to loop until clean, or for a paranoid pre-merge review that auto-addresses every blocker.
development
Generate self-contained HTML visualizations with Plannotator theming. Use for implementation plans, PR explainers, architecture diagrams, data tables, slide decks, and any visual explanation of technical concepts. Plans and PR explainers follow Plannotator's prescriptive approach; all other visual content delegates to nicobailon/visual-explainer.
development
Create reviewed Codex goal setup packages for long-running /goal work. Use when the user wants to turn an idea, backlog, project mission, or vague objective into durable goal files under a project goals slug folder, with Plannotator review gates for brief, narrative plan with acceptance criteria, verification, blockers, and the final /goal prompt.