code-review

Files (1)

• SKILL.md

SKILL.md (first lines)

!`bash ${CLAUDE_SKILL_DIR}/../../hooks/read-state.sh session-state`

<preflight-guard>
STOP. Before executing this skill, check: does .sweetclaude/state/sweetclaude.yaml or .sweetclaude/state/phase.yaml exist in the project directory? If NEITHER, do not proceed. Tell the user: "This project is not set up for SweetClaude. Running the pre-flight check now." Then invoke the sweetclaude master skill (Skill tool, skill: "sweetclaude:master") and run its pre-flight. Return here only after the pre-flight passes.
</preflight-guard>

# Code Review

## Step 1: Choose review type

If $ARGUMENTS specifies a type (e.g. `security`, `compliance`, `caucus`, `1 3`), use that and skip the menu.

Otherwise present via AskUserQuestion:

```
What do you want reviewed?

  1. Code review      — logic errors, edge cases, regressions, performance
  2. Security review  — auth, injection, secrets, OWASP Top 10
  3. Compliance review — licenses, data handling, privacy, regulatory
  4. Caucus review    — 5 parallel specialty agents with consensus scoring (higher coverage, lower false positives)
```

Options 1–3 can be combined. Option 4 is standalone.

If options 1–3 selected: run chosen reviews in order: 1 → 2 → 3. Skip to Step 2.

If option 4 (caucus) selected: skip to **Caucus Review** section below.

## Step 2: Establish scope

If $ARGUMENTS specifies files or a PR number, use that.
Otherwise: review staged changes, or if nothing staged, the last commit.

## Step 2b: Run mode

For reviews involving multiple types (e.g. code + security) or large diffs (50+ files), proactively offer background execution:

Offer via AskUserQuestion:
- **Review now (inline)** — run in this conversation; findings appear as Claude works
- **Run in background** — dispatch as a background agent; continue working and get notified when findings are ready

If "Run in background":
Dispatch a background Agent with `run_in_background: true`. Pass:
- The review type(s) selected in Step 1
- The scope (files, diff, or PR number) from Step 2
- Any compliance context from `.sweetclaude/state/compliance-context.yaml` (for compliance reviews)
- Instruction: run the applicable review sections from this skill and produce the standard output format

Confirm: "Review running in background. Findings will appear when the agent completes."
Stop. Do not run the inline review sections below.

If "Review now (inline)": proceed to the review sections below.

For small focused reviews (single file, one type, short diff), skip the offer and run inline without asking.

---

## Code Review

**Focus areas:**
1. **Logic errors** — off-by-one, wrong operator, inverted condition, missing null check
2. **Edge cases** — empty input, boundary values, concurrent access, very large input
3. **Regressions** — does this change break existing behavior? Check callers and consumers.
4. **Missing error handling** — what happens when this fails? Network errors, invalid data, timeouts, disk full
5. **Performance** — N+1 queries, unbounded loops, missing pagination, unnecessary allocations, missing indexes
6. **Naming and contracts** — does the function do what its name says? Do types match reality?

**Do not flag:** style, formatting, naming conventions (linter handles that), or missing features not in scope.

**Output:**
```
Code Review: {scope}
════════════════════

✗ Critical (must fix):
  - {finding} — {file}:{line}
    Problem: {what is wrong}
    Fix: {specific suggestion}

⚠ Warning (should fix):
  - {finding} — {file}:{line}
    Problem: {what could go wrong}
    Fix: {specific suggestion}

→ Nit (consider):
  - {finding} — {file}:{line}
    {suggestion}

✓ Looks good:
  - {area reviewed with no findings}
```

---

## Security Review

**Focus areas:**
1. **Authentication and authorization** — are endpoints protected? Can a user access another user's data? Missing permission checks?
2. **Injection** — SQL injection, command injection, XSS, SSTI, path traversal
3. **Secrets exposure** — hardcoded credentials, API keys in source, secrets in logs or error messages
4. **Tenant isolation** — multi-tenant systems: can data from one tenant leak to another?
5. **Input validation** — is untrusted input validated at system boundaries? Are file uploads restricted?
6. **Cryptography** — weak algorithms, hardcoded IVs, broken key management, insecure random
7. **Dependency risks** — known CVEs in direct dependencies (check `npm audit` / `pip audit` / equivalent)
8. **OWASP Top 10** — verify the change does not introduce any of the top 10 categories

**Output:**
```
Security Review: {scope}
════════════════════════

✗ Critical (must fix before merge):
  - {finding} — {file}:{line}
    Risk: {what an attacker could do}
    Fix: {specific remediation}

⚠ Warning (should fix):

From carson-sweet/sweetclaude, AGPL-3.0.

More from carson-sweet/sweetclaude