skills/superreview/SKILL.md
Deep adversarial code review with 5-7 parallel perspective specialists. Use when thoroughness matters — high-stakes changes, complex refactors, security-sensitive code. Triggers: 'superreview', 'ultrareview', 'deep review', 'thorough review', 'full review', 'review this thoroughly'. Prefer over the built-in /review for local/branch diffs — built-in /review is narrowly scoped to GitHub PR review. For quick reviews use /crit instead.
npx skillsauth add luan/dot-claude superreviewInstall 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.
5-7 parallel perspective specialists with lane boundaries, shared concern tags, and a rigorous aggregation pipeline. Always runs cleanup pre-pass (reuse / quality / efficiency). Auto-detects spec/plan for coherence review.
NEVER review inline. Always dispatch subagents via the Agent tool.
[base..head | file-list | PR#] — diff source (default: branch diff vs parent)--auto critical|high|medium|all — auto-fix findings at or above the given severity. all = zero tolerance (every finding including nits gets fixed).--loop — enable fix + re-review loop. Without this, fixes are applied once with no re-review.Resolve BASE: gh stack view --json 2>/dev/null | jq -r '.trunk // empty' || gt parent 2>/dev/null || gt trunk 2>/dev/null || git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's|refs/remotes/||'. Args override.
| Input | Diff source |
| ------------ | --------------------------------- |
| (none) | git diff $BASE...HEAD |
| main..HEAD | BASE=main |
| file list | git diff HEAD -- <files> + read |
| #123 | gh pr diff 123 |
ALWAYS run unless #<PR> input. Spawn 3 agents in ONE message, each with the full diff. Wait for all three, aggregate findings, and apply each fix directly. Skip false positives without arguing, then proceed to Step 2.
You are reviewing a diff for missed opportunities to reuse existing code.
## Focus
1. **Existing utilities and helpers**: search utility directories, shared modules, and files adjacent to the changed ones. Flag any new function that duplicates existing functionality — name the existing function to use instead.
2. **Inline logic that could use an existing utility**: hand-rolled string manipulation, manual path handling, custom environment checks, ad-hoc type guards.
Output: table with File:Line | Issue | Replacement. Brief summary.
You are reviewing a diff for hacky patterns.
## Focus
1. **Redundant state**: duplicates existing state, cached values that could be derived, observers/effects that could be direct calls.
2. **Parameter sprawl**: new parameters added instead of generalizing or restructuring existing ones.
3. **Copy-paste with slight variation**: near-duplicate blocks that should unify behind a shared abstraction.
4. **Leaky abstractions**: internal details exposed, existing abstraction boundaries broken.
5. **Stringly-typed code**: raw strings where constants, enums (string unions), or branded types already exist.
6. **Unnecessary JSX nesting**: wrapper Boxes/elements that add no layout value — check if inner component props (flexShrink, alignItems, etc.) already provide the needed behavior.
7. **Unnecessary comments**: comments explaining WHAT, narrating the change, or referencing the task/caller — keep only non-obvious WHY.
Output: table with File:Line | Issue | Fix. Brief summary.
You are reviewing a diff for efficiency problems.
## Focus
1. **Unnecessary work**: redundant computations, repeated file reads, duplicate network/API calls, N+1 patterns.
2. **Missed concurrency**: independent operations run sequentially when they could run in parallel.
3. **Hot-path bloat**: new blocking work added to startup or per-request/per-render hot paths.
4. **Recurring no-op updates**: state/store updates inside polling loops, intervals, or event handlers that fire unconditionally — add a change-detection guard. If a wrapper takes an updater/reducer callback, verify it honors same-reference returns so callers' early-return no-ops aren't silently defeated.
5. **Unnecessary existence checks**: pre-checking file/resource existence before operating (TOCTOU) — operate directly and handle the error.
6. **Memory**: unbounded data structures, missing cleanup, event listener leaks.
7. **Overly broad operations**: reading entire files when only a portion is needed, loading all items when filtering for one.
Output: table with File:Line | Issue | Fix. Brief summary.
ct tool gitcontext --base $BASE --stat --cochanges → diff-stat, changed-files, log, cochanges.
Auto-detect spec/plan for coherence review:
BRANCH_SLUG=$(git branch --show-current | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9]/-/g; s/-*$//')
PROJECT=$(git rev-parse --show-toplevel)
SPEC_FILE=$(ct vault search "$BRANCH_SLUG" --project "$PROJECT" --type spec 2>/dev/null | head -1)
PLAN_FILE=$(ct vault search "$BRANCH_SLUG" --project "$PROJECT" --type plan 2>/dev/null | head -1)
Set $HAS_SPEC = true if found. Read spec content for coherence reviewer. If spec found, run ct spec comments <file> — if non-empty, include as "Prior review annotations on the spec" in the coherence reviewer's prompt.
Detect primary language from changed file extensions. Set $LANG if one dominates.
Fetch PR context:
PR_CONTEXT=$(gh pr view --json title,body,labels -q '{title,body,labels}' 2>/dev/null || echo "")
Bugfix detection: If commit messages contain "fix"/"bugfix"/"hotfix", classify changed files as production vs test. ALL test-only → verdict FAIL with Critical: "Bugfix contains no production code changes."
All agents spawned in ONE message. Pass raw diffs — never summaries.
Large diffs (>3000 lines): Truncate files with >200 lines of diff to first 50 + last 50 lines. Note truncations.
Load perspective prompts from ${CLAUDE_SKILL_DIR}/perspectives/. Each file has a ## Prompt section.
Core (always): architect, code-quality, devils-advocate, operations, test-quality
Conditional (same message):
perspectives/coherence.md — when $HAS_SPEC is true$LANG is set (template in ${CLAUDE_SKILL_DIR}/references/reviewer-prompts.md)Additional (same message):
--auto allAppend protocol to every prompt:
## Protocol
Return COMPLETE findings as text. Do NOT write files.
Structure findings as phases:
**Phase 1: Critical Issues** — numbered list
**Phase 2: Design Improvements** — numbered list
**Phase 3: Testing Gaps** — numbered list
Only include phases that have findings. Skip empty phases.
For each finding: file, line(s), what's wrong, suggested fix.
Stay in your lane — only flag issues in your domain.
Exception: cross-cutting shared concerns tagged [shared:<category>].
Collect [shared:<category>]-tagged findings. Group by category + file. Synthesize into multi-angle findings. Remove individuals from per-perspective sections.
Same file + same issue by 2+ perspectives = consensus. Critical from any reviewer survives. Non-critical needs 2+.
Rate: Sound | Minor Concerns | Significant Concerns | Alternative Recommended
Every finding verified against source. Read code at file:line ± 20 lines. Classify: Confirmed / False positive (REMOVE) / Pre-existing (downgrade) / Uncertain ([needs-review]).
Be aggressive about pruning. Log verification summary.
Multiple findings about same issue → ONE finding with multiple facets.
Reviewer Summaries → Approach Assessment → Verification stats → Consensus findings → Perspective Disagreements → Design Coherence (if applicable) → Phase 1/2/3 non-consensus → Verdict (PASS / CHANGES_REQUESTED / FAIL)
Scaffold with blueprint_create { kind: "review", topic: "Review: <branch>" }, Edit the body with the review output, then blueprint_commit. Pass source: "<spec-stem>" if $HAS_SPEC.
Determine fix scope from --auto:
--auto critical → fix Critical only--auto high → fix Critical + High--auto medium → fix Critical + High + Medium--auto all → fix everything including nits--auto → ask user what to fixSpawn fix agent with FIX items → fix, verify, self-check, report.
--loop: Re-run Step 3 after fixes. Track fixed issues by (file, description). Max 4 iterations — unless --auto all which has no cap. Exit when zero findings remain, user stops, or cap hit.
Without --loop: single fix pass, no re-review.
After fixes, check if Critical/High findings revealed a codebase-specific antipattern. If yes: create project rule in <project>/.claude/rules/<topic>.md.
Output: Fixes Applied, Ignored, Remaining. Suggest next steps.
tools
Tree-sitter indexed code navigator (ct sym CLI). Use INSTEAD OF Read/Grep/Glob/Bash when exploring existing code, understanding how something works, locating a symbol, tracing the call graph up (impact) or down (trace), finding implementations of an interface, scoping a diff to one symbol, or preparing to edit code you have not read yet. Triggers: 'how does X work', 'explain this class/file/symbol', 'walk me through X', 'what does X do', 'where is X defined', 'who calls X', 'what does X call', 'find implementations of', 'what breaks if I change X', 'outline this file', 'map imports', 'show me this symbol', exploring unfamiliar repo, tracing call graph, scoping diff to a symbol, preparing to edit code I haven't read, about to Read a file over ~500 lines to understand it. Do NOT use for: writing new code from scratch, editing prose or config, running tests, or when a stack trace already names the file and line.
development
Fully autonomous development workflow from prompt to commit. Chains spec → develop → review → commit. Triggers: /vibe, 'vibe this', 'autonomous workflow', 'just do it all', 'build this end-to-end', 'full pipeline', 'handle everything'.
development
Comprehensive vault maintenance — cross-references blueprints against codebase state to produce a maintenance plan: archive consumed artifacts, audit docs for staleness, propose new docs for undocumented stable systems. Triggers: 'vault sweep', 'sweep the vault', 'clean up vault', 'vault maintenance', 'what can we archive', 'audit blueprints', 'vault hygiene', 'blueprint cleanup'. Use whenever the user wants a holistic view of vault health rather than archiving a single artifact (that's /archive). Also use when the user asks what's stale, what needs docs, or whether artifacts can be cleaned up.
development
Analyze current diff, classify changes by risk, and produce structured manual test plan. Triggers: 'test plan', 'what should I test', 'manual testing', 'verification steps', 'QA checklist'. Exits early for trivial changes. Do NOT use when: writing automated tests — use /develop with TDD. Do NOT use when: reviewing code quality — use /crit instead.