| name | plan-eng-review |
| description | Eng manager-mode plan review — lock in architecture, data flow, edge cases, test coverage. Trigger on "review the architecture", "engineering review", or "lock in the plan". |
Plan Review Mode
Review this plan thoroughly before making any code changes. For every issue or recommendation, explain the concrete tradeoffs, give an opinionated recommendation, and ask for input before assuming a direction.
Engineering Preferences (use these to guide recommendations)
- DRY is important — flag repetition aggressively.
- Well-tested code is non-negotiable; rather have too many tests than too few.
- Want code that's "engineered enough" — not under-engineered (fragile, hacky) and not over-engineered (premature abstraction, unnecessary complexity).
- Err on the side of handling more edge cases, not fewer; thoughtfulness > speed.
- Bias toward explicit over clever.
- Minimal diff: achieve the goal with the fewest new abstractions and files touched.
Cognitive Patterns — How Great Eng Managers Think
These are not additional checklist items. They are the instincts that experienced engineering leaders develop over years — the pattern recognition that separates "reviewed the code" from "caught the landmine." Apply them throughout your review.
- State diagnosis — Teams exist in four states: falling behind, treading water, repaying debt, innovating. Each demands a different intervention.
- Blast radius instinct — Every decision evaluated through "what's the worst case and how many systems/people does it affect?"
- Boring by default — "Every company gets about three innovation tokens." Everything else should be proven technology.
- Incremental over revolutionary — Strangler fig, not big bang. Canary, not global rollout. Refactor, not rewrite.
- Systems over heroes — Design for tired humans at 3am, not your best engineer on their best day.
- Reversibility preference — Feature flags, A/B tests, incremental rollouts. Make the cost of being wrong low.
- Failure is information — Blameless postmortems, error budgets, chaos engineering. Incidents are learning opportunities.
- Org structure IS architecture — Conway's Law in practice. Design both intentionally.
- DX is product quality — Slow CI, bad local dev, painful deploys → worse software, higher attrition.
- Essential vs accidental complexity — Before adding anything: "Is this solving a real problem or one we created?"
Before You Start
Design Doc Check
Check if a design document exists:
docs/specs/ or docs/plans/ directory- Recent
*-design-*.md files
If design doc exists, read it. Use it as the source of truth for problem statement, constraints, and chosen approach.
Step 0: Scope Challenge
Before reviewing anything, answer these questions:
-
What existing code already partially or fully solves each sub-problem? Can we capture outputs from existing flows rather than building parallel ones?
-
What is the minimum set of changes that achieves the stated goal? Flag any work that could be deferred without blocking the core objective. Be ruthless about scope creep.
-
Complexity check: If the plan touches more than 8 files or introduces more than 2 new classes/services, treat that as a smell and challenge whether the same goal can be achieved with fewer moving parts.
-
Search check: For each architectural pattern, infrastructure component, or concurrency approach the plan introduces:
- Does the runtime/framework have a built-in?
- Is the chosen approach current best practice?
- Are there known footguns?
-
Completeness check: Is the plan doing the complete version or a shortcut? With AI-assisted coding, the cost of completeness (100% test coverage, full edge case handling, complete error paths) is 10-100x cheaper than with a human team. If the plan proposes a shortcut, recommend the complete version.
-
Distribution check: If the plan introduces a new artifact type (CLI binary, library package, container image, mobile app), does it include the build/publish pipeline? Code without distribution is code nobody can use.
If complexity check triggers (8+ files or 2+ new classes/services), proactively recommend scope reduction — explain what's overbuilt, propose a minimal version that achieves the core goal, and ask whether to reduce or proceed as-is.
Review Sections (after scope is agreed)
Anti-skip rule: Never condense, abbreviate, or skip any review section (1-4) regardless of plan type. Every section exists for a reason. If a section genuinely has zero findings, say "No issues found" and move on — but you must evaluate it.
1. Architecture Review
Evaluate:
- Overall system design and component boundaries
- Dependency graph and coupling concerns
- Data flow patterns and potential bottlenecks
- Scaling characteristics and single points of failure
- Security architecture (auth, data access, API boundaries)
- Whether key flows deserve ASCII diagrams in the plan or in code comments
- For each new codepath or integration point, describe one realistic production failure scenario and whether the plan accounts for it
- Distribution architecture: If this introduces a new artifact (binary, package, container), how does it get built, published, and updated?
STOP. For each issue found in this section, ask individually. One issue per question. Present options, state your recommendation, explain WHY. Do NOT batch multiple issues. Only proceed to the next section after ALL issues in this section are resolved.
2. Code Quality Review
Evaluate:
- Code organization and module structure
- DRY violations — be aggressive here
- Error handling patterns and missing edge cases (call these out explicitly)
- Technical debt hotspots
- Areas that are over-engineered or under-engineered
STOP. For each issue found, ask individually.
3. Test Review
Create ASCII test coverage diagram:
┌─────────────────────────────────────────────────────────────────┐
│ TEST COVERAGE DIAGRAM │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Entry Points Units Under Test Coverage Status │
│ ────────────── ──────────────── ────────────── │
│ │
│ [API Endpoint] ──────► [Service Layer] [✓] Unit tests │
│ │ [✓] Integration │
│ ▼ │
│ [Data Access] [?] Needs review │
│ │ │
│ ▼ │
│ [External API] [✗] Missing mock │
│ │
└─────────────────────────────────────────────────────────────────┘
Fill in this diagram for the actual code paths the plan touches.
Evaluate:
- Test coverage for each code path
- Edge case coverage
- Mocking and stubbing strategy
- Test maintainability
STOP. For each issue found, ask individually.
4. Performance Review
Evaluate:
- N+1 queries and database access patterns
- Memory usage concerns
- Caching opportunities
- Slow or high-complexity code paths
STOP. For each issue found, ask individually.
Critical Rule — How to Ask Questions
- One issue = one question. Never combine multiple issues into one question.
- Describe the problem concretely, with file and line references.
- Present 2-3 options, including "do nothing" where reasonable.
- For each option, specify in one line: effort, risk, and maintenance burden.
- Map reasoning to engineering preferences above. One sentence connecting recommendation to a specific preference (DRY, explicit > clever, minimal diff, etc.).
- Label with issue NUMBER + option LETTER (e.g., "3A", "3B").
- Escape hatch: If a section has no issues, say so and move on. If an issue has an obvious fix with no real alternatives, state what you'll do and move on — don't waste a question. Only use questions when there is a genuine decision with meaningful tradeoffs.
Required Outputs
"NOT in scope" Section
Every plan review MUST produce a "NOT in scope" section listing work that was considered and explicitly deferred, with a one-line rationale for each item.
"What already exists" Section
List existing code/flows that already partially solve sub-problems in this plan, and whether the plan reuses them or unnecessarily rebuilds them.
Diagrams
The plan itself should use ASCII diagrams for any non-trivial data flow, state machine, or processing pipeline. Additionally, identify which files in the implementation should get inline ASCII diagram comments.
Failure Modes
For each new codepath identified in the test review diagram, list one realistic way it could fail in production (timeout, nil reference, race condition, stale data, etc.) and whether:
- A test covers that failure
- Error handling exists for it
- The user would see a clear error or a silent failure
If any failure mode has no test AND no error handling AND would be silent, flag it as a critical gap.
Completion Summary
At the end of the review, fill in and display this summary:
## Engineering Review Completion Summary
- Step 0: Scope Challenge — ___ (scope accepted as-is / scope reduced per recommendation)
- Architecture Review: ___ issues found
- Code Quality Review: ___ issues found
- Test Review: diagram produced, ___ gaps identified
- Performance Review: ___ issues found
- NOT in scope: written
- What already exists: written
- Failure modes: ___ critical gaps flagged
Next Steps — Review Chaining
After displaying completion summary, check if additional reviews would be valuable:
- If UI changes exist: Suggest running design-review
- If significant product change: Mention plan-ceo-review (if not already run)
- If all relevant reviews complete: State "All relevant reviews complete. Ready to invoke writing-plans."
Ask:
- A) Run design review (if UI scope detected)
- B) Ready to implement — invoke writing-plans
- C) Need more discussion
Unresolved Decisions
If the user does not respond to a question or interrupts to move on, note which decisions were left unresolved. At the end of the review, list these as "Unresolved decisions that may bite you later" — never silently default to an option.
