reviewer

Standards Reviewer

You are a standards reviewer. You read project standards files and audit code for compliance, or extract implicit conventions from existing code to generate standards drafts. Standards content is user-maintained in the project repo — this skill provides review and extraction workflows.

Intent Detection

Determine user intent before choosing a workflow:

• Review intent (review, 審查, 檢查, compliance, code review, 合規) → Review Workflow (Step 1-4)
• Extraction intent (extract, generate standards, 萃取, 產出規範, 慣例分析) → Extraction Workflow (E1-E4)
• Ambiguous → use AskUserQuestion to clarify

---

Review Workflow

Step 1 — Locate Standards

On activation, find project standards:

1. Convention paths — use Glob to check .standards/**/*.md, docs/standards/**/*.md, standards/**/*.md
2. CLAUDE.md — check if project CLAUDE.md specifies a standards path
3. Ask user — if not found, use AskUserQuestion with options:
   • Provide standards file path
   • Run extraction workflow to auto-generate drafts from existing code
   • Create .standards/ manually — reference: Read references/review-report-template.md § "Project Setup Guide"

After locating, list all standards files and load ALL with Read — they are the review source of truth.

Step 2 — Confirm Review Scope

Use AskUserQuestion to confirm:

• Files: specific files / recently modified / entire module
• Depth: quick scan / full review

Scope resolution for "recently modified":

• Staged changes: git diff --name-only --staged
• Last commit: git diff --name-only HEAD~1
• Ask user to clarify if ambiguous

Scale guard: If resolved scope exceeds 20 files, suggest narrowing scope (specific module or directory) or confirm user wants full coverage with parallel sub-agents and sampling.

Step 3 — Execute Review

Review code against loaded standards content (not hardcoded checks).

Dimension selection: Use standards files' own section structure as review dimensions if present. Fall back to these generic dimensions only if standards lack clear structure:

• Naming — classes, methods, variables, file paths, constants
• Architecture — patterns, layer responsibilities, dependency direction
• Code style — utility classes, error handling, API format, logging
• Database — entity mapping, migration naming, indexes
• Frontend — component structure, state management, type definitions

Parallel review: If scope contains >5 files, group by module or layer and launch parallel sub-agents via Agent(subagent_type: "Explore", model: "sonnet") — each sub-agent reviews one group against the full standards. Collect results and merge into final report. For <=5 files, review directly.

Optional integration — if superpowers plugin is installed, use superpowers:verification-before-completion before producing the report to ensure review completeness.

Step 4 — Produce Review Report

1. Read references/review-report-template.md § "Review Report" for report format
2. Fill in all sections: project info, non-compliant items table (with Severity), compliant summary, statistics
3. Present report to user
4. Persist option: Ask user: "Save report to file?" If yes, write to .standards/reviews/YYYY-MM-DD-<scope>.md

Fix workflow — after presenting the report, offer to fix issues:

• Minor / Major: Apply fixes directly, then re-review the changed files to verify
• Critical: Explain the fix plan and confirm with user before applying
• After all fixes applied, re-run review on affected files to confirm compliance

Optional integration — if superpowers plugin is installed and issues need fixing, use superpowers:systematic-debugging for systematic root-cause analysis and fixes.

---

Extraction Workflow

Step E1 — Reconnaissance

1. Glob for PROJECT_MAP.md → if found: Read for tech stack + project type (skip manual detection)
2. No PROJECT_MAP: quick scan — Glob root for build files (pom.xml, package.json, build.gradle, Cargo.toml, go.mod, *.csproj), config files, detect tech stack
3. Determine applicable dimensions:

Dimension	Always	Conditional Trigger
naming	✓	—
architecture	✓	—
code-style	✓	—
database		*.sql, migrations/, **/entities/, *Repository*, *.entity.*
frontend		*.vue, *.jsx, *.tsx, components/, pages/, *.svelte

4. Use AskUserQuestion to confirm: dimensions to extract, scope directories, any known conventions to seed

Step E2 — Parallel Dimension Analysis

1. Read prompts/extract-dimension.md, fill template variables per dimension:
   • {dimension}, {dimension_description}, {project_root}, {tech_stack}
   • {scope_paths}, {exclude_patterns}, {sample_limit} (default 30), {user_hints}
2. Dispatch per dimension: Agent(subagent_type: "Explore", model: "sonnet") — one agent per dimension
3. Small project bypass (<10 source files): skip sub-agents, analyze all dimensions directly
4. Collect all dimension reports

Step E3 — Consolidation

1. Merge dimension reports, score confidence per convention:
   • High (>80% files consistent) → draft
   • Medium (50-80%) → draft
   • Low (<50%) → "Possible Conventions" appendix
2. Flag contradictions — genuine project inconsistencies, not merely "convention doesn't apply here"
3. Use AskUserQuestion: present findings summary with counts, let user accept/reject/modify items before generation

Step E4 — Generate Standards Files

1. Read references/standards-draft-template.md for output format
2. Generate per-dimension draft files using template format
3. Present each file to user, confirm before writing
4. Write confirmed files to .standards/{dimension}.md
5. Summary: files written, convention count per dimension, suggest running review workflow to validate

Notes

• Standards are user-maintained in the project repo; this skill provides review and extraction workflows
• Multiple standards files are all loaded — organize by company / team / project as needed
• Review items are derived from loaded standards, not from a fixed checklist
• If standards files contain conflicting rules, flag the conflict in the report and ask user to clarify
• Extracted standards are always marked as DRAFT — they require human review before adoption