Solo Review

/review

This skill is self-contained — follow the instructions below instead of delegating to external review skills (superpowers, etc.) or spawning Task subagents. Run all checks directly.

Final quality gate before shipping. Runs tests, checks security, verifies acceptance criteria from spec.md, audits code quality, and generates a ship-ready report with go/no-go verdict.

When to use

After /deploy (or /build if deploying manually). This is the quality gate.

Pipeline: /deploy → /review

Can also be used standalone: /review on any project to audit code quality.

MCP Tools (use if available)

• session_search(query) — find past review patterns and common issues
• project_code_search(query, project) — find similar code patterns across projects
• codegraph_query(query) — check dependencies, imports, unused code

If MCP tools are not available, fall back to Glob + Grep + Read.

Pre-flight Checks

1. Architecture overview (if MCP available)

codegraph_explain(project="{project name}")

Returns: stack, languages, directory layers, key patterns, top dependencies, hub files. Use this to detect stack and understand project structure.

2. Essential docs (parallel reads)

• CLAUDE.md — architecture, Do/Don't rules
• docs/plan/*/spec.md — acceptance criteria to verify (REQUIRED)
• docs/plan/*/plan.md — task completion status (REQUIRED)
• docs/workflow.md — TDD policy, quality standards, integration testing commands (if exists)

Do NOT read source code at this stage. Only docs.

3. Detect stack

Use stack from codegraph_explain response (or CLAUDE.md if no MCP) to choose tools:

• Next.js → npm run build, npm test, npx next lint
• Python → uv run pytest, uv run ruff check
• Swift → swift test, swiftlint
• Kotlin → ./gradlew test, ./gradlew lint

4. Smart source code loading (for code quality spot check)

Do NOT read random source files. Use the graph to find the most important code:

codegraph_query("MATCH (f:File {project: '{name}'})-[e]-() RETURN f.path, COUNT(e) AS edges ORDER BY edges DESC LIMIT 5")

Read only the top 3-5 hub files (most connected = most impactful). For security checks, use Grep with narrow patterns (sk_live, password\s*=) — not full file reads.

Review Dimensions

Makefile convention: If Makefile exists in project root, always prefer make targets over raw commands. Use make test instead of npm test, make lint instead of pnpm lint, make build instead of pnpm build. Run make help (or read Makefile) to discover available targets including integration tests.

Run all 12 dimensions in sequence. Report findings per dimension.

1. Test Suite

Run the full test suite (prefer make test if Makefile exists):

# If Makefile exists — use it
make test 2>&1 || true

# Fallback: Next.js / Node
npm test -- --coverage 2>&1 || true

# Python
uv run pytest --tb=short -q 2>&1 || true

# Swift
swift test 2>&1 || true

Report:

• Total tests: pass / fail / skip
• Coverage percentage (if available)
• Any failing tests with file:line references

Integration tests — if docs/workflow.md has an "Integration Testing" section, run the specified commands:

• Execute the CLI/integration commands listed there
• Verify exit code 0 and expected output format
• Report: command run, exit code, pass/fail

2. Linter & Type Check

# Next.js
pnpm lint 2>&1 || true
pnpm tsc --noEmit 2>&1 || true

# Python
uv run ruff check . 2>&1 || true
uv run ty check . 2>&1 || true

# Swift
swiftlint lint --strict 2>&1 || true

# Kotlin
./gradlew detekt 2>&1 || true
./gradlew ktlintCheck 2>&1 || true

Report: warnings count, errors count, top issues.

3. Build Verification

# Next.js
npm run build 2>&1 || true

# Python
uv run python -m py_compile src/**/*.py 2>&1 || true

# Astro
npm run build 2>&1 || true

Report: build success/failure, any warnings.

4. Security Audit

Dependency vulnerabilities:

# Node
npm audit --audit-level=moderate 2>&1 || true

# Python
uv run pip-audit 2>&1 || true

Code-level checks (Grep for common issues):

• Hardcoded secrets: grep -rn "sk_live\|sk_test\|password\s*=\s*['\"]" src/ app/ lib/
• SQL injection: look for string concatenation in queries
• XSS: look for dangerouslySetInnerHTML without sanitization
• Exposed env vars: check .gitignore includes .env*

Report: vulnerabilities found, severity levels.

5. Acceptance Criteria Verification

Read docs/plan/*/spec.md and check each acceptance criterion:

For each - [ ] criterion in spec.md:

1. Search codebase for evidence it was implemented.
2. Check if related tests exist.
3. Mark as verified or flag as missing.

Update spec.md checkboxes. After verifying each criterion, use Edit tool to change - [ ] to - [x] in spec.md. Leaving verified criteria unchecked causes staleness across pipeline runs — check them off as you go.

Acceptance Criteria:
  - [x] User can sign up with email — found in app/auth/signup/page.tsx + test
  - [x] Dashboard shows project list — found in app/dashboard/page.tsx
  - [ ] Stripe checkout works — route exists but no test coverage

After updating checkboxes, commit: git add docs/plan/*/spec.md && git commit -m "docs: update spec checkboxes (verified by review)"

6. Code Quality Spot Check

Read 3-5 key files (entry points, API routes, main components):

• Check for TODO/FIXME/HACK comments that should be resolved
• Check for console.log/print statements left in production code
• Check for proper error handling (try/catch, error boundaries)
• Check for proper loading/error states in UI components

Report specific file:line references for any issues found.

7. Plan Completion Check

Read docs/plan/*/plan.md:

• Count completed tasks [x] vs total tasks
• Flag any [ ] or [~] tasks still remaining
• Verify all phase checkpoints have SHAs

8. Production Logs (if deployed)

If the project has been deployed (deploy URL in CLAUDE.md, or .solo/states/deploy exists if pipeline state directory is present), check production logs for runtime errors.

Read the logs field from the stack YAML (templates/stacks/{stack}.yaml) to get platform-specific commands.

Vercel (Next.js):

vercel logs --output=short 2>&1 | tail -50

Look for: Error, FUNCTION_INVOCATION_FAILED, 504, unhandled rejections, hydration mismatches.

Cloudflare Workers:

wrangler tail --format=pretty 2>&1 | head -50

Look for: uncaught exceptions, D1 errors, R2 access failures.

Fly.io (Python API):

fly logs --app {name} 2>&1 | tail -50

Look for: ERROR, CRITICAL, OOM, connection refused, unhealthy instances.

Supabase Edge Functions:

supabase functions logs --scroll 2>&1 | tail -30

iOS (TestFlight):

• Check App Store Connect → TestFlight → Crashes
• If local device: log stream --predicate 'subsystem == "com.{org}.{name}"'

Android:

adb logcat '*:E' --format=time 2>&1 | tail -30

• Check Google Play Console → Android vitals → Crashes & ANRs

If no deploy yet: skip this dimension, note in report as "N/A — not deployed".

If logs show errors:

• Classify: startup crash vs runtime error vs intermittent
• Add as FIX FIRST issues in the report
• Include exact log lines as evidence

Report:

• Log source checked (platform, command used)
• Errors found: count + severity
• Error patterns (recurring vs one-off)
• Status: CLEAN / WARN / ERRORS

9. Dev Principles Compliance

Check adherence to dev principles. Look for templates/principles/dev-principles.md (bundled with this skill), or check CLAUDE.md or project docs for architecture and coding conventions.

Read the dev principles file, then spot-check 3-5 key source files for violations:

SOLID:

• SRP — any god-class/god-module doing auth + profile + email + notifications? Flag bloated files (>300 LOC with mixed responsibilities).
• DIP — are services injected or hardcoded? Look for new ConcreteService() inside business logic instead of dependency injection.

DRY vs Rule of Three:

• Search for duplicated logic blocks (Grep for identical function signatures across files).
• But don't flag 2-3 similar lines — duplication is OK until a pattern emerges.

KISS:

• Over-engineered abstractions for one-time operations?
• Feature flags or backward-compat shims where a simple change would do?
• Helpers/utilities used only once?

Schemas-First (SGR):

• Are Pydantic/Zod schemas defined before logic? Or is raw data passed around?
• Are API responses typed (not any / dict)?
• Validation at boundaries (user input, external APIs)?

Clean Architecture:

• Do dependencies point inward? Business logic should not import from UI/framework layer.
• Is business logic framework-independent?

Error Handling:

• Fail-fast on invalid inputs? Or silent swallowing of errors?
• User-facing errors are friendly? Internal errors have stack traces?

Report:

• Principles followed: list key ones observed
• Violations found: with file:line references
• Severity: MINOR (style) / MAJOR (architecture) / CRITICAL (data loss risk)

10. Commit Quality

Check git history for the current track/feature:

git log --oneline --since="1 week ago" 2>&1 | head -30

Conventional commits format:

• Each commit follows <type>(<scope>): <description> pattern
• Types: feat, fix, refactor, test, docs, chore, perf, style
• Flag: generic messages ("fix", "update", "wip", "changes"), missing type prefix, too-long titles (>72 chars)

Atomicity:

• Each commit = one logical change? Or monster commits with 20 files across unrelated features?
• Revert-friendly? Could you git revert a single commit without side effects?

SHAs in plan.md:

• Check that completed tasks have <!-- sha:abc1234 --> comments
• Check that phase checkpoints have <!-- checkpoint:abc1234 -->

grep -c "sha:" docs/plan/*/plan.md 2>/dev/null || echo "No SHAs found"

Pre-commit hooks:

Read the stack YAML pre_commit field to know what system is expected (husky/pre-commit/lefthook) and what it should run (linter + formatter + type-checker). Then verify:

# Detect what's configured
[ -f .husky/pre-commit ] && echo "husky" || [ -f .pre-commit-config.yaml ] && echo "pre-commit" || [ -f lefthook.yml ] && echo "lefthook" || echo "none"

• Hooks installed? Check config files exist AND hooks are wired (core.hooksPath for husky, .git/hooks/pre-commit for pre-commit/lefthook).
• Hooks match stack? Compare detected system with stack YAML pre_commit field. Flag mismatch.
• --no-verify bypasses? Check if recent commits show signs of skipped hooks (e.g., lint violations that should've been caught). Flag as WARN.
• Not configured? Flag as WARN recommendation — stack YAML expects {pre_commit} but nothing found.

Report:

• Total commits: {N}
• Conventional format: {N}/{M} compliant
• Atomic commits: YES / NO (with examples of violations)
• Plan SHAs: {N}/{M} tasks have SHAs
• Pre-commit hooks: {ACTIVE / NOT INSTALLED / NOT CONFIGURED} (expected: {stack pre_commit})

11. Documentation Freshness

Check that project documentation is up-to-date with the code.

Required files check:

ls -la CLAUDE.md README.md docs/prd.md docs/workflow.md 2>&1

CLAUDE.md:

• Does it reflect current tech stack, commands, directory structure?
• Are recently added features/endpoints documented?
• Grep for outdated references (old package names, removed files):

  # Check that files mentioned in CLAUDE.md actually exist
  grep -oP '`[a-zA-Z0-9_./-]+\.(ts|py|swift|kt|md)`' CLAUDE.md | while read f; do [ ! -f "$f" ] && echo "MISSING: $f"; done

README.md:

• Does it have setup/run/test/deploy instructions?
• Are the commands actually runnable?

docs/prd.md:

• Do features match what was actually built?
• Are metrics and success criteria defined?

AICODE- comments:

grep -rn "AICODE-TODO" src/ app/ lib/ 2>/dev/null | head -10
grep -rn "AICODE-ASK" src/ app/ lib/ 2>/dev/null | head -10

• Flag unresolved AICODE-TODO items that were completed but not cleaned up
• Flag unanswered AICODE-ASK questions
• Check for AICODE-NOTE on complex/non-obvious logic

Dead code check:

• Unused imports (linter should catch, but verify)
• Orphaned files not imported anywhere
• If knip available (Next.js): pnpm knip 2>&1 | head -30

Report:

• CLAUDE.md: CURRENT / STALE / MISSING
• README.md: CURRENT / STALE / MISSING
• docs/prd.md: CURRENT / STALE / MISSING
• docs/workflow.md: CURRENT / STALE / MISSING
• AICODE-TODO unresolved: {N}
• AICODE-ASK unanswered: {N}
• Dead code: {files/exports found}