Review

SkillDB 作者 fortunto2 v1.1.1

Final code review and quality gate — run tests, check coverage, audit security, verify acceptance criteria from spec, and generate ship-ready report. Use when user says "review code", "quality check", "is it ready to ship", "final review", or after /deploy completes. Do NOT use for planning (use /plan) or building (use /build).

源码 ↗

安装 / 下载方式

TotalClaw CLI推荐
totalclaw install skilldb:fortunto2~solo-review
cURL直接下载,无需登录
curl -fsSL https://skills.taituai.com/api/skills/skilldb%3Afortunto2~solo-review/file -o solo-review.md
Git 仓库获取源码
git clone https://github.com/openclaw/skills/commit/3aef4f799315a6e2ac03ef3721af6a05db670670
# /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):
```bash
# 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

```bash
# 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

```bash
# 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:**
```bash
# 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):**
```bash
vercel logs --output=short 2>&1 | tail -50
```
Look for: `Error`, `FUNCTION_INVOCATION_FAILED`, `504`, unhandled rejections, hydration mismatches.

**Cloudflare Workers:**
```bash
wrangler tail --format=pretty 2>&1 | head -50
```
Look for: uncaught exceptions, D1 errors, R2 access failures.

**Fly.io (Python API):**
```bash
fly logs --app {name} 2>&1 | tail -50
```
Look for: `ERROR`, `CRITICAL`, OOM, connection refused, unhealthy instances.

**Supabase Edge Functions:**
```bash
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:**
```bash
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 responsibi