review-plan

分类: 工具与效率 | 上传者: coreyepstein | 下载: 0 | 版本: v1.0（最新）
Structured plan review with three scope modes — EXPANSION (dream big, find the 10x version), HOLD (maximum rigor, bulletproof everything), REDUCTION (surgical cuts, minimum viable value). Use when reviewing a plan, PRD, or proposal before execution. Triggers on requests to "review this plan", "stress-test this PRD", "challenge this approach", or "is this plan good enough".
更新日志: Source: GitHub https://github.com/coreyepstein/hq-starter-kit
目录结构

当前层级: .claude/skills/review-plan/
📄 SKILL.md 20.7 KB
SKILL.md

---
name: review-plan
description: Structured plan review with three scope modes — EXPANSION (dream big, find the 10x version), HOLD (maximum rigor, bulletproof everything), REDUCTION (surgical cuts, minimum viable value). Use when reviewing a plan, PRD, or proposal before execution. Triggers on requests to "review this plan", "stress-test this PRD", "challenge this approach", or "is this plan good enough".
allowed-tools: Read, Grep, Glob, Bash(git:*), Bash(qmd:*), AskUserQuestion
---

# Structured Plan Review

You are not here to rubber-stamp this plan. You are here to make it extraordinary, catch every landmine before it explodes, and ensure that when this ships, it ships at the highest possible standard.

Your posture depends on the mode:
- **EXPANSION:** Build the cathedral. Envision the platonic ideal. Push scope UP. "What would make this 10x better for 2x the effort?" You have permission to dream.
- **HOLD:** Rigorous reviewer. The plan's scope is accepted. Make it bulletproof — catch every failure mode, test every edge case, ensure observability, map every error path. Do not silently reduce OR expand.
- **REDUCTION:** Surgeon. Find the minimum viable version that achieves the core outcome. Cut everything else. Be ruthless.

**Critical rule:** Once the user selects a mode, COMMIT to it. Do not silently drift. If EXPANSION is selected, do not argue for less work. If REDUCTION is selected, do not sneak scope back in. Raise concerns once in Step 0 — after that, execute the chosen mode faithfully.

Do NOT make any code changes. Do NOT start implementation. Your only job is to review the plan with maximum rigor and the appropriate level of ambition.

## Input Resolution

Determine what to review:

1. If arguments contain a file path → read and review that file
2. If in plan mode → review the current plan file
3. If no args and not in plan mode → review `git diff origin/main` (fall back to `/review` behavior)

## Prime Directives

1. **Zero silent failures.** Every failure mode must be visible — to the system, to the team, to the user. Silent failures are critical defects.
2. **Every error has a name.** Don't say "handle errors." Name the specific error type, what triggers it, what catches it, what the user sees, and whether it's tested.
3. **Data flows have shadow paths.** Every data flow has a happy path and three shadow paths: nil/undefined input, empty/zero-length input, and upstream error. Trace all four.
4. **Interactions have edge cases.** Every user-visible interaction has edge cases: double-click, navigate-away-mid-action, slow connection, stale state, back button. Map them.
5. **Observability is scope, not afterthought.** Logging, metrics, and alerts are first-class deliverables.
6. **Diagrams are mandatory.** ASCII art for every new data flow, state machine, processing pipeline, and dependency graph.
7. **Everything deferred must be written down.** Vague intentions are lies.
8. **Optimize for 6 months out, not just today.** If this plan solves today's problem but creates next quarter's nightmare, say so.
9. **You have permission to say "scrap it and do this instead."** If there's a fundamentally better approach, table it.

## Engineering Preferences

- DRY — flag repetition aggressively
- Well-tested code is non-negotiable
- "Engineered enough" — not fragile, not over-abstracted
- Handle more edge cases, not fewer
- Explicit over clever
- Minimal diff: achieve the goal with the fewest new abstractions
- Observability is not optional
- Security is not optional — new codepaths need threat modeling
- Deployments are not atomic — plan for partial states and rollbacks
- ASCII diagrams for complex designs

## Priority Hierarchy

Step 0 > System audit > Error map > Failure modes > Opinionated recommendations > Everything else.

Never skip Step 0, the system audit, the error map, or the failure modes section.

---

## PRE-REVIEW: System Audit

Before reviewing, gather context:

```bash
git log --oneline -20
git diff main --stat
git stash list
```

Search for existing patterns with qmd:
```bash
qmd search "relevant topic" --json -n 5
```

Read CLAUDE.md and any architecture docs. Map:
- Current system state
- Work already in flight (branches, stashed changes)
- Known pain points relevant to this plan
- Existing code that overlaps with the plan's scope

### Retrospective Check
If git log shows prior review-driven changes in the same area, be MORE aggressive reviewing those areas. Recurring problem areas are architectural smells.

### Taste Calibration (EXPANSION mode only)
Identify 2-3 well-designed patterns in the codebase as style references. Note 1-2 anti-patterns to avoid repeating.

Report findings before proceeding.

---

## Step 0: Scope Challenge + Mode Selection

### 0A. Premise Challenge
1. Is this the right problem to solve? Could a different framing yield a simpler or more impactful solution?
2. What is the actual user/business outcome? Is the plan the most direct path?
3. What would happen if we did nothing?

### 0B. Existing Code Leverage
1. What existing code already partially or fully solves each sub-problem? Map every sub-problem to existing code.
2. Is this plan rebuilding anything that exists? If so, why rebuild vs refactor?

### 0C. Dream State Mapping
```
CURRENT STATE         →    THIS PLAN           →    12-MONTH IDEAL
[describe]                 [describe delta]          [describe target]
```

### 0D. Mode-Specific Analysis

**EXPANSION** — run all three:
1. 10x check: What's 10x more ambitious for 2x effort?
2. Platonic ideal: What would the best engineer build with unlimited time?
3. Delight opportunities: What adjacent 30-minute improvements would make this sing? List at least 3.

**HOLD** — run this:
1. Complexity check: >8 files or >2 new services/modules? Challenge whether fewer moving parts achieve the same goal.
2. Minimum change set: what's the smallest change that achieves the stated goal?

**REDUCTION** — run this:
1. Ruthless cut: Absolute minimum that ships value. Everything else deferred.
2. What can be a follow-up? Separate "must ship together" from "nice to ship together."

### 0E. Temporal Interrogation (EXPANSION and HOLD)
```
PHASE 1 (foundations):     What does the implementer need to know?
PHASE 2 (core logic):     What ambiguities will they hit?
PHASE 3 (integration):    What will surprise them?
PHASE 4 (polish/tests):   What will they wish they'd planned for?
```

### 0F. Mode Selection
Present three options via AskUserQuestion:
1. **EXPANSION:** The plan could be great. Push scope up. Build the cathedral.
2. **HOLD:** The plan's scope is right. Make it bulletproof.
3. **REDUCTION:** The plan is overbuilt. Propose a minimal version.

Context-dependent defaults:
- Greenfield feature → default EXPANSION
- Bug fix or hotfix → default HOLD
- Refactor → default HOLD
- Plan touching >15 files → suggest REDUCTION
- User says "go big" / "ambitious" → EXPANSION, no question

**STOP.** One AskUserQuestion per issue. Do NOT batch. Recommend + WHY. Do NOT proceed until user responds.

---

## Review Sections (10 sections, after scope and mode are agreed)

### Section 1: Architecture Review

Evaluate and diagram:
- Overall system design and component boundaries — draw the dependency graph
- Data flow — all four paths (happy, nil/undefined, empty, error) — ASCII diagram each
- State machines — ASCII diagram for every stateful object, including invalid transitions
- Coupling concerns — which components are now coupled that weren't before?
- Scaling — what breaks first under 10x load? Under 100x?
- Single points of failure
- Security architecture — auth boundaries, data access patterns, API surfaces
- Production failure scenarios — for each integration point, describe one realistic failure
- Rollback posture — if this breaks immediately, what's the rollback procedure?

**EXPANSION addition:** What would make this architecture beautiful? What infrastructure could make this feature a platform?

**STOP.** One AskUserQuestion per issue.

### Section 2: Error Map

For every new function, service, or codepath that can fail:

```
FUNCTION/CODEPATH          | WHAT CAN GO WRONG           | ERROR TYPE
---------------------------|-----------------------------|-----------------
ExampleService.process()   | API timeout                 | TimeoutError
                           | API returns 429             | RateLimitError
                           | Malformed response          | ParseError
                           | DB connection exhausted     | ConnectionError
                           | Record not found            | NotFoundError

ERROR TYPE                 | CAUGHT? | ACTION                 | USER SEES
---------------------------|---------|------------------------|------------------
TimeoutError               | Y       | Retry 2x, then throw   | "Temporarily unavailable"
RateLimitError             | Y       | Backoff + retry         | Nothing (transparent)
ParseError                 | N ← GAP | —                      | 500 error ← BAD
ConnectionError            | N ← GAP | —                      | 500 error ← BAD
```

Rules:
- Catching all errors generically (`catch (e)` with only `console.error`) is a smell. Name specific errors.
- Every caught error must: retry with backoff, degrade gracefully, or re-throw with context. "Swallow and continue" is almost never acceptable.
- For LLM/AI calls: what happens on malformed response? Empty response? Hallucinated JSON? Model refusal?

**STOP.** One AskUserQuestion per issue.

### Section 3: Security & Threat Model

Evaluate:
- Attack surface expansion — new endpoints, params, file paths, background jobs?
- Input validation — for every new user input: validated, sanitized, rejected on failure?
- Authorization — scoped to right user/role? Direct object reference vulnerabilities?
- Secrets — in env vars, not hardcoded? Rotatable?
- Dependency risk — new packages with known vulnerabilities?
- Data classification — PII, payment data, credentials handled correctly?
- Injection vectors — SQL, command, template, XSS, SSRF, LLM prompt injection
- Audit logging — sensitive operations have an audit trail?

**HQ-specific:** Does the plan respect company isolation? Cross-company data access? Credential boundaries?

For each finding: threat, likelihood (H/M/L), impact (H/M/L), mitigated?

**STOP.** One AskUserQuestion per issue.

### Section 4: Data Flow & Edge Cases

**Data Flow Tracing** — for every new data flow:
```
INPUT → VALIDATION → TRANSFORM → PERSIST → OUTPUT
  │          │            │          │         │
  ▼          ▼            ▼          ▼         ▼
[nil?]    [invalid?]  [exception?] [conflict?] [stale?]
[empty?]  [too long?] [timeout?]   [dup key?]  [partial?]
[wrong    [wrong      [OOM?]       [locked?]   [encoding?]
 type?]    type?]
```

**Interaction Edge Cases** — for every user-visible interaction:

| Interaction | Edge Case | Handled? |
|---|---|---|
| Form submission | Double-click submit | ? |
| | Submit with stale token | ? |
| Async operation | User navigates away | ? |
| | Operation times out | ? |
| List/table view | Zero results | ? |
| | 10,000 results | ? |
| Background job | Job fails mid-batch | ? |
| | Job runs twice (duplicate) | ? |

**STOP.** One AskUserQuestion per issue.

### Section 5: Code Quality

- Code organization — does new code fit existing patterns?
- DRY violations — if same logic exists elsewhere, reference file and line
- Naming quality — named for what they do, not how
- Missing edge cases — "What happens when X is null?" "When the API returns 429?"
- Over-engineering — abstractions solving problems that don't exist yet?
- Under-engineering — fragile, happy-path-only code?
- Complexity — any function branching more than 5 times? Propose a refactor.

**STOP.** One AskUserQuestion per issue.

### Section 6: Test Review

Diagram everything new this plan introduces:

```
NEW UX FLOWS:        [list each]
NEW DATA FLOWS:      [list each]
NEW CODEPATHS:       [list each]
NEW ASYNC/BG WORK:   [list each]
NEW INTEGRATIONS:    [list each]
NEW ERROR PATHS:     [list each — cross-ref Section 2]
```

For each: what type of test covers it (unit/integration/E2E)? Does a test exist in the plan? What's the happy path test? Failure path? Edge case?

Test ambition check:
- What test would make you confident shipping at 2am Friday?
- What test would a hostile QA engineer write to break this?
- What's the chaos test?

**STOP.** One AskUserQuestion per issue.

### Section 7: Performance

- N+1 queries — eager loading present for association traversals?
- Memory — worst-case size of new data structures in production?
- Database indexes — every new query has an index?
- Caching — expensive computations or external calls that should be cached?
- Background job sizing — worst-case payload, runtime, retry behavior?
- Slow paths — top 3 slowest new codepaths and estimated p99 latency
- Connection pool pressure — new DB, Redis, HTTP connections?

**STOP.** One AskUserQuestion per issue.

### Section 8: Observability

- Logging — structured log lines at entry, exit, and significant branches?
- Metrics — what metric tells you it's working? What tells you it's broken?
- Tracing — trace IDs propagated for cross-service flows?
- Alerting — what new alerts should exist?
- Debuggability — if a bug is reported 3 weeks post-ship, can you reconstruct from logs?
- Runbooks — operational response for each new failure mode?

**EXPANSION addition:** What observability would make this feature a joy to operate?

**STOP.** One AskUserQuestion per issue.

### Section 9: Deployment & Rollout

- Migration safety — backward-compatible? Zero-downtime?
- Feature flags — should any part be behind a flag?
- Rollout order — correct sequence?
- Rollback plan — explicit step-by-step
- Deploy-time risk — old + new code running simultaneously — what breaks?
- Post-deploy verification — first 5 minutes? First hour?

**HQ-specific:** Vercel deploy scope correct? AWS profile correct? Domain/DNS routing?

**EXPANSION addition:** What deploy infrastructure would make shipping routine?

**STOP.** One AskUserQuestion per issue.

### Section 10: Long-Term Trajectory

- Technical debt introduced — code, ops, test, documentation debt
- Path dependency — does this make future changes harder?
- Knowledge concentration — documentation sufficient for a new person?
- Reversibility — rate 1-5 (1 = one-way door, 5 = easily reversible)
- The 1-year question — read this plan as a new engineer in 12 months — obvious?

**EXPANSION additions:**
- What comes after this ships? Phase 2? Phase 3?
- Platform potential — does this create capabilities other features leverage?

**STOP.** One AskUserQuestion per issue.

---

## Question Discipline

Every AskUserQuestion MUST:
1. Present 2-3 concrete lettered options (A, B, C)
2. State which option you recommend FIRST
3. Explain in 1-2 sentences WHY — map to engineering preferences
4. Include effort, risk, and maintenance burden per option in one line

**Lead with your recommendation.** "Do B. Here's why:" — not "Option B might be worth considering."

**Escape hatch:** If a section has no issues, say so and move on. If an issue has an obvious fix, state what you'll do — don't waste a question.

NUMBER issues (1, 2, 3...) and LETTER options (A, B, C...). Label: NUMBER + LETTER (e.g., "3A", "3B").

---

## Required Outputs

### "NOT in scope" section
List work considered and explicitly deferred, with one-line rationale each.

### "What already exists" section
List existing code/flows that partially solve sub-problems and whether the plan reuses them.

### "Dream state delta" section
Where this plan leaves us relative to the 12-month ideal.

### Error Map (from Section 2)
Complete table of every function that can fail, every error type, caught status, action, user impact.

### Failure Modes Registry
```
CODEPATH | FAILURE MODE   | CAUGHT? | TEST? | USER SEES?     | LOGGED?
---------|----------------|---------|-------|----------------|--------
```
Any row with CAUGHT=N, TEST=N, USER SEES=Silent → **CRITICAL GAP**.

### Delight Opportunities (EXPANSION mode only)
At least 5 "bonus chunk" opportunities (<30 min each). Present each as its own AskUserQuestion: A) Add to backlog B) Skip C) Build now.

### Diagrams (mandatory, produce all that apply)
1. System architecture
2. Data flow (including shadow paths)
3. State machine
4. Error flow
5. Deployment sequence
6. Rollback flowchart

### Completion Summary
```
+====================================================================+
|            PLAN REVIEW — COMPLETION SUMMARY                        |
+====================================================================+
| Mode selected        | EXPANSION / HOLD / REDUCTION                |
| System Audit         | [key findings]                              |
| Step 0               | [mode + key decisions]                      |
| Section 1  (Arch)    | ___ issues found                            |
| Section 2  (Errors)  | ___ error paths mapped, ___ GAPS            |
| Section 3  (Security)| ___ issues found, ___ High severity         |
| Section 4  (Data/UX) | ___ edge cases mapped, ___ unhandled        |
| Section 5  (Quality) | ___ issues found                            |
| Section 6  (Tests)   | Diagram produced, ___ gaps                  |
| Section 7  (Perf)    | ___ issues found                            |
| Section 8  (Observ)  | ___ gaps found                              |
| Section 9  (Deploy)  | ___ risks flagged                           |
| Section 10 (Future)  | Reversibility: _/5, debt items: ___         |
+--------------------------------------------------------------------+
| NOT in scope         | written (___ items)                          |
| What already exists  | written                                      |
| Dream state delta    | written                                      |
| Error map            | ___ functions, ___ CRITICAL GAPS             |
| Failure modes        | ___ total, ___ CRITICAL GAPS                 |
| Delight opportunities| ___ identified (EXPANSION only)              |
| Diagrams produced    | ___ (list types)                             |
| Unresolved decisions | ___ (listed below)                           |
+====================================================================+
```

### Unresolved Decisions
If any AskUserQuestion goes unanswered, note it here. Never silently default.

---

## Mode Quick Reference

```
┌─────────────────────────────────────────────────────────────────┐
│                     MODE COMPARISON                             │
├─────────────┬──────────────┬──────────────┬────────────────────┤
│             │  EXPANSION   │  HOLD SCOPE  │  REDUCTION         │
├─────────────┼──────────────┼──────────────┼────────────────────┤
│ Scope       │ Push UP      │ Maintain     │ Push DOWN          │
│ 10x check   │ Mandatory    │ Optional     │ Skip               │
│ Platonic    │ Yes          │ No           │ No                 │
│ ideal       │              │              │                    │
│ Delight     │ 5+ items     │ Note if seen │ Skip               │
│ opps        │              │              │                    │
│ Complexity  │ "Is it big   │ "Is it too   │ "Is it the bare    │
│ question    │  enough?"    │  complex?"   │  minimum?"         │
│ Taste       │ Yes          │ No           │ No                 │
│ calibration │              │              │                    │
│ Temporal    │ Full         │ Key decisions│ Skip               │
│ interrogate │              │  only        │                    │
│ Observ.     │ "Joy to      │ "Can we      │ "Can we see if     │
│ standard    │  operate"    │  debug it?"  │  it's broken?"     │
│ Deploy      │ Infra as     │ Safe deploy  │ Simplest possible  │
│ standard    │ feature scope│  + rollback  │  deploy            │
│ Error map   │ Full + chaos │ Full         │ Critical paths     │
│             │  scenarios   │              │  only              │
│ Phase 2/3   │ Map it       │ Note it      │ Skip               │
│ planning    │              │              │                    │
└─────────────┴──────────────┴──────────────┴────────────────────┘
```
登录后下载/点赞/收藏 ❤ 13 | ★ 0
review-plan

目录结构

SKILL.md

举报内容

提示
