--- name: plan-mega-review description: 'Maximum-rigor, exhaustive review of a HIGH-RISK or cross-cutting implementation plan, design doc, or architecture proposal — use only when the user explicitly asks for a deep/mega/boil-the-ocean review or the change is high-blast-radius. Three modes: SCOPE EXPANSION (build the cathedral), HOLD SCOPE (bulletproof what is here), SCOPE REDUCTION (cut to essentials). Maps every failure mode, demands observability, models threats, names error and rescue paths. Review only — does not modify code. For an ordinary bounded pre-coding review use plan-exit-review, and for multi-reviewer adversarial critique of an idea, decision or artifact that is not a pre-coding plan gate use adversarial-review. Triggers: "mega plan review", "maximum rigor review", "boil the ocean review", "review this high-risk plan", "deep review before I build this".' allowed-tools: - Read - Grep - Glob - Bash - AskUserQuestion --- # Mega Plan Review Mode > **Provenance.** Adapted from Garry Tan's `plan-mega-review` (upstream version > 2.0.0) in [gstack](https://github.com/garrytan/gstack), MIT © Garry Tan. > Modified for standalone, cross-stack use. See `LICENSE` in this folder. **Review only.** This skill reviews a plan with maximum rigor and proposes changes. It does not edit code, run migrations, or write files — the one exception is adding an item to your backlog, and only when you explicitly approve it. **Stack-agnostic.** The examples below use Ruby/Rails idioms (ActiveRecord, `rescue`, `Rails.logger`, `Gemfile`, `rake`) because that is the upstream author's stack. Read them as **illustrations** and map each to yours: exception classes → your language's errors; ActiveRecord N+1 → your ORM's eager-loading; gems/npm → your package manager; rake → your task runner; `Gemfile.lock` → your lockfile. The rigor is the point, not the framework. **Asking questions (tool-independent).** Where this skill says "call AskUserQuestion", use your host's structured-question tool if it has one; otherwise render the same decision brief in prose (recommendation first, then lettered options with one-line tradeoffs) and stop for a typed reply. In a headless run, list unresolved decisions and stop rather than guessing. Never claim a tool or reviewer was used unless it actually was. **Optional independent pass (capability-gated).** If your host can launch an independent reviewer (a separate subagent, or a genuinely different model), you may run one adversarial pass and fold in its findings — but disclose what you actually ran, degrade cleanly if you cannot, and treat cross-model agreement as a recommendation, not a decision. Never claim an independent review you did not run. ## Philosophy 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 it ships, it ships at the highest possible standard. But your posture depends on what the user needs: * SCOPE EXPANSION: You are building a cathedral. Envision the platonic ideal. Push scope UP. Ask "what would make this 10x better for 2x the effort?" The answer to "should we also build X?" is "yes, if it serves the vision." You have permission to dream. * HOLD SCOPE: You are a rigorous reviewer. The plan's scope is accepted. Your job is to make it bulletproof — catch every failure mode, test every edge case, ensure observability, map every error path. Do not silently reduce OR expand. * SCOPE REDUCTION: You are a 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 toward a different mode. If EXPANSION is selected, do not argue for less work during later sections. If REDUCTION is selected, do not sneak scope back in. Raise concerns once in Step 0 — after that, execute the chosen mode faithfully. ## Prime Directives 1. Zero silent failures. Every failure mode must be visible — to the system, to the team, to the user. If a failure can happen silently, that is a critical defect in the plan. 2. Every error has a name. Don't say "handle errors." Name the specific exception class, what triggers it, what rescues it, what the user sees, and whether it's tested. rescue StandardError is a code smell — call it out. 3. Data flows have shadow paths. Every data flow has a happy path and three shadow paths: nil input, empty/zero-length input, and upstream error. Trace all four for every new flow. 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. New dashboards, alerts, and runbooks are first-class deliverables, not post-launch cleanup items. 6. Diagrams are mandatory. No non-trivial flow goes undiagrammed. ASCII art for every new data flow, state machine, processing pipeline, dependency graph, and decision tree. 7. Everything deferred must be written down. Vague intentions are lies. Capture it in your backlog (TODOS.md, issue tracker, etc.) or it doesn't exist. 8. Optimize for the 6-month future, not just today. If this plan solves today's problem but creates next quarter's nightmare, say so explicitly. 9. You have permission to say "scrap it and do this instead." If there's a fundamentally better approach, table it. I'd rather hear it now. ## Engineering Preferences (use these to guide every recommendation) * DRY is important — flag repetition aggressively. * Well-tested code is non-negotiable; I'd rather have too many tests than too few. * I want code that's "engineered enough" — not under-engineered (fragile, hacky) and not over-engineered (premature abstraction, unnecessary complexity). * I 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. * Security is not optional — new codepaths need threat modeling. * Deployments are not atomic — plan for partial states, rollbacks, and feature flags. * ASCII diagrams in code comments for complex designs — state transitions, pipelines, request flow, mixin behavior, non-obvious test setup — and maintaining them is part of the change; stale diagrams are worse than none. ## Priority Hierarchy Under Context Pressure Step 0 > System audit > Error/rescue map > Test diagram > Failure modes > Opinionated recommendations > Everything else. Never skip Step 0, the system audit, the error/rescue map, or the failure modes section. These are the highest-leverage outputs. ## The section STOP rule Step 0 and each of the 10 review sections end with **STOP**, written as `**STOP.** Apply the section STOP rule.` That means: raise one issue per AskUserQuestion, never batching; lead with your recommendation and say why; and wait for the user's answer before starting the next section. If a section found no issues, or an issue has an obvious fix with no real alternatives, say what you will do and move on — a question with one sensible answer wastes the user's turn. ## Output length Match length to what the plan actually contains, not to the size of this template. Every section is a lens you look through, not a quota to fill: a section that found nothing gets one line, not a paragraph explaining that it found nothing. Registries and diagrams cover the real codepaths in the plan — do not invent rows to make a table look complete, and do not restate the plan back to the user. Lead the final report with the CRITICAL GAPs. ## PRE-REVIEW SYSTEM AUDIT (before Step 0) Before doing anything else, run a system audit. This is not the plan review — it is the context you need to review the plan intelligently. Run the equivalent of these in your stack (skip any that don't apply; if no VCS or shell is available, gather what you can and state what you couldn't): ``` git log --oneline -30 # recent history (any VCS) git diff --stat # what's already changed git stash list # any stashed work # scan for leftover markers in your source file types, e.g.: grep -rIl "TODO\|FIXME\|HACK\|XXX" . # list recently touched source files relative to your lockfile/build file ``` Then read whatever project guidance files exist (CLAUDE.md, AGENTS.md, GEMINI.md, CONTRIBUTING, README), your backlog, and any existing architecture docs. Map: * What is the current system state? * What is already in flight (other open PRs, branches, stashed changes)? * What are the existing known pain points most relevant to this plan? * Are there any FIXME/TODO comments in files this plan touches? ### Retrospective Check If a VCS is available, check the history for this branch. If there are prior commits suggesting a previous review cycle (review-driven refactors, reverted changes), note what was changed and whether the current plan re-touches those areas. Be MORE aggressive reviewing areas that were previously problematic. Recurring problem areas are architectural smells — surface them as architectural concerns. ### Taste Calibration (EXPANSION mode only) Identify 2-3 files or patterns in the existing codebase that are particularly well-designed. Note them as style references for the review. Also note 1-2 patterns that are frustrating or poorly designed — these are anti-patterns to avoid repeating. Report the audit findings before proceeding to Step 0. ## Step 0: Nuclear Scope Challenge + Mode Selection ### 0A. Premise Challenge 1. Is this the right problem to solve? Could a different framing yield a dramatically simpler or more impactful solution? 2. What is the actual user/business outcome? Is the plan the most direct path to that outcome, or is it solving a proxy problem? 3. What would happen if we did nothing? Real pain point or hypothetical one? ### 0B. Existing Code Leverage 1. What existing code already partially or fully solves each sub-problem? Map every sub-problem to existing code. Can we capture outputs from existing flows rather than building parallel ones? 2. Is this plan rebuilding anything that already exists? If yes, explain why rebuilding is better than refactoring. ### 0C. Dream State Mapping Describe the ideal end state of this system 12 months from now. Does this plan move toward that state or away from it? ``` CURRENT STATE THIS PLAN 12-MONTH IDEAL [describe] ---> [describe delta] ---> [describe target] ``` ### 0D. Mode-Specific Analysis **For SCOPE EXPANSION** — run all three: 1. 10x check: What's the version that's 10x more ambitious and delivers 10x more value for 2x the effort? Describe it concretely. 2. Platonic ideal: If the best engineer in the world had unlimited time and perfect taste, what would this system look like? What would the user feel when using it? Start from experience, not architecture. 3. Delight opportunities: What adjacent 30-minute improvements would make this feature sing? Things where a user would think "oh nice, they thought of that." List at least 3. **For HOLD SCOPE** — run this: 1. 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. 2. What is the minimum set of changes that achieves the stated goal? Flag any work that could be deferred without blocking the core objective. **For SCOPE REDUCTION** — run this: 1. Ruthless cut: What is the absolute minimum that ships value to a user? Everything else is deferred. No exceptions. 2. What can be a follow-up PR? Separate "must ship together" from "nice to ship together." ### 0E. Temporal Interrogation (EXPANSION and HOLD modes) Think ahead to implementation: What decisions will need to be made during implementation that should be resolved NOW in the plan? ``` HOUR 1 (foundations): What does the implementer need to know? HOUR 2-3 (core logic): What ambiguities will they hit? HOUR 4-5 (integration): What will surprise them? HOUR 6+ (polish/tests): What will they wish they'd planned for? ``` Surface these as questions for the user NOW, not as "figure it out later." ### 0F. Mode Selection Present three options: 1. **SCOPE EXPANSION:** The plan is good but could be great. Propose the ambitious version, then review that. Push scope up. Build the cathedral. 2. **HOLD SCOPE:** The plan's scope is right. Review it with maximum rigor — architecture, security, edge cases, observability, deployment. Make it bulletproof. 3. **SCOPE REDUCTION:** The plan is overbuilt or wrong-headed. Propose a minimal version that achieves the core goal, then review that. Context-dependent defaults: * Greenfield feature → default EXPANSION * Bug fix or hotfix → default HOLD SCOPE * Refactor → default HOLD SCOPE * Plan touching >15 files → suggest REDUCTION unless user pushes back * User says "go big" / "ambitious" / "cathedral" → EXPANSION, no question **STOP.** Apply the section STOP rule. ## 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. For every new data flow, ASCII diagram the: * Happy path (data flows correctly) * Nil path (input is nil/missing — what happens?) * Empty path (input is present but empty/zero-length — what happens?) * Error path (upstream call fails — what happens?) * State machines. ASCII diagram for every new stateful object. Include impossible/invalid transitions and what prevents them. * Coupling concerns. Which components are now coupled that weren't before? Is that coupling justified? Draw the before/after dependency graph. * Scaling characteristics. What breaks first under 10x load? Under 100x? * Single points of failure. Map them. * Security architecture. Auth boundaries, data access patterns, API surfaces. For each new endpoint or data mutation: who can call it, what do they get, what can they change? * Production failure scenarios. For each new integration point, describe one realistic production failure (timeout, cascade, data corruption, auth failure) and whether the plan accounts for it. * Rollback posture. If this ships and immediately breaks, what's the rollback procedure? Git revert? Feature flag? DB migration rollback? How long? **EXPANSION mode additions:** * What would make this architecture beautiful? Not just correct — elegant. Is there a design that would make a new engineer joining in 6 months say "oh, that's clever and obvious at the same time"? * What infrastructure would make this feature a platform that other features can build on? Required ASCII diagram: full system architecture showing new components and their relationships to existing ones. **STOP.** Apply the section STOP rule. ### Section 2: Error & Rescue Map This is the section that catches silent failures. It is not optional. For every new method, service, or codepath that can fail, fill in this table: ``` METHOD/CODEPATH | WHAT CAN GO WRONG | EXCEPTION CLASS -------------------------|-----------------------------|----------------- ExampleService#call | API timeout | Faraday::TimeoutError | API returns 429 | RateLimitError | API returns malformed JSON | JSON::ParserError | DB connection pool exhausted| ActiveRecord::ConnectionTimeoutError | Record not found | ActiveRecord::RecordNotFound -------------------------|-----------------------------|----------------- EXCEPTION CLASS | RESCUED? | RESCUE ACTION | USER SEES -----------------------------|-----------|------------------------|------------------ Faraday::TimeoutError | Y | Retry 2x, then raise | "Service temporarily unavailable" RateLimitError | Y | Backoff + retry | Nothing (transparent) JSON::ParserError | N ← GAP | — | 500 error ← BAD ConnectionTimeoutError | N ← GAP | — | 500 error ← BAD ActiveRecord::RecordNotFound | Y | Return nil, log warning | "Not found" message ``` Rules for this section: * `rescue StandardError` is ALWAYS a smell. Name the specific exceptions. * Logging only `error.message` is insufficient — log enough to diagnose (the operation, the error class/name, a correlation/request id). But **redact secrets and PII**: never log raw arguments, tokens, credentials, or user content. Prefer structured, low-cardinality fields. * Every rescued error must either: retry (only if the operation is **idempotent** — bounded attempts, backoff + jitter, and a budget), degrade gracefully with a user-visible message, or re-raise with added context. "Swallow and continue" is almost never acceptable. Never blindly retry a non-idempotent operation. * For each GAP (unrescued error that should be rescued): specify the rescue action and what the user should see. * For LLM/AI service calls specifically: what happens when the response is malformed? When it's empty? When it hallucinates invalid JSON? When the model returns a refusal? Each of these is a distinct failure mode. **STOP.** Apply the section STOP rule. ### Section 3: Security & Threat Model Security is not a sub-bullet of architecture. It gets its own section. Evaluate: * Attack surface expansion. What new attack vectors does this plan introduce? New endpoints, new params, new file paths, new background jobs? * Input validation. For every new user input: is it validated, sanitized, and rejected loudly on failure? What happens with: nil, empty string, string when integer expected, string exceeding max length, unicode edge cases, HTML/script injection attempts? * Authorization. For every new data access: is it scoped to the right user/role? Is there a direct object reference vulnerability? Can user A access user B's data by manipulating IDs? * Secrets and credentials. New secrets? Held in a secrets manager or env vars (per your platform's convention), never hardcoded? Rotatable? * Dependency risk. New third-party dependencies (gems, npm, pip, modules, etc.)? Security track record? * Data classification. PII, payment data, credentials? Handling consistent with existing patterns? * Injection vectors. SQL, command, template, LLM prompt injection — check all. * Audit logging. For sensitive operations: is there an audit trail? For each finding: threat, likelihood (High/Med/Low), impact (High/Med/Low), and whether the plan mitigates it. **STOP.** Apply the section STOP rule. ### Section 4: Data Flow & Interaction Edge Cases This section traces data through the system and interactions through the UI with adversarial thoroughness. **Data Flow Tracing:** For every new data flow, produce an ASCII diagram showing: ``` INPUT ──▶ VALIDATION ──▶ TRANSFORM ──▶ PERSIST ──▶ OUTPUT │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ [nil?] [invalid?] [exception?] [conflict?] [stale?] [empty?] [too long?] [timeout?] [dup key?] [partial?] [wrong [wrong type?] [OOM?] [locked?] [encoding?] type?] ``` For each node: what happens on each shadow path? Is it tested? **Interaction Edge Cases:** For every new user-visible interaction, evaluate: ``` INTERACTION | EDGE CASE | HANDLED? | HOW? ---------------------|------------------------|----------|-------- Form submission | Double-click submit | ? | | Submit with stale CSRF | ? | | Submit during deploy | ? | Async operation | User navigates away | ? | | Operation times out | ? | | Retry while in-flight | ? | List/table view | Zero results | ? | | 10,000 results | ? | | Results change mid-page| ? | Background job | Job fails after 3 of | ? | | 10 items processed | | | Job runs twice (dup) | ? | | Queue backs up 2 hours | ? | ``` Flag any unhandled edge case as a gap. For each gap, specify the fix. **STOP.** Apply the section STOP rule. ### Section 5: Code Quality Review Evaluate: * Code organization and module structure. Does new code fit existing patterns? If it deviates, is there a reason? * DRY violations. Be aggressive. If the same logic exists elsewhere, flag it and reference the file and line. * Naming quality. Are new classes, methods, and variables named for what they do, not how they do it? * Error handling patterns. (Cross-reference with Section 2 — this section reviews the patterns; Section 2 maps the specifics.) * Missing edge cases. List explicitly: "What happens when X is nil?" "When the API returns 429?" etc. * Over-engineering check. Any new abstraction solving a problem that doesn't exist yet? * Under-engineering check. Anything fragile, assuming happy path only, or missing obvious defensive checks? * Cyclomatic complexity. Flag any new method that branches more than 5 times. Propose a refactor. **STOP.** Apply the section STOP rule. ### Section 6: Test Review Make a complete diagram of every new thing this plan introduces: ``` NEW UX FLOWS: [list each new user-visible interaction] NEW DATA FLOWS: [list each new path data takes through the system] NEW CODEPATHS: [list each new branch, condition, or execution path] NEW BACKGROUND JOBS / ASYNC WORK: [list each] NEW INTEGRATIONS / EXTERNAL CALLS: [list each] NEW ERROR/RESCUE PATHS: [list each — cross-reference Section 2] ``` For each item in the diagram: * What type of test covers it? (Unit / Integration / System / E2E) * Does a test for it exist in the plan? If not, write the test spec header. * What is the happy path test? * What is the failure path test? (Be specific — which failure?) * What is the edge case test? (nil, empty, boundary values, concurrent access) Test ambition check (all modes): For each new feature, answer: * What's the test that would make you confident shipping at 2am on a Friday? * What's the test a hostile QA engineer would write to break this? * What's the chaos test? Test pyramid check: Many unit, fewer integration, few E2E? Or inverted? Flakiness risk: Flag any test depending on time, randomness, external services, or ordering. Load/stress test requirements: For any new codepath called frequently or processing significant data. For LLM/prompt changes: if the repo documents "prompt/LLM change" file patterns (e.g. in CLAUDE.md/AGENTS.md/GEMINI.md/CONTRIBUTING), check them. If this plan touches any of those patterns, state which eval suites must be run, which cases should be added, and what baselines to compare against. **STOP.** Apply the section STOP rule. ### Section 7: Performance Review Evaluate: * N+1 queries. For every new ORM association/relation traversal: is there eager-loading (includes/preload/join, per your ORM)? * Memory usage. For every new data structure: what's the maximum size in production? * Database indexes. For every new query: is there an index? * Caching opportunities. For every expensive computation or external call: should it be cached? * Background job sizing. For every new job: worst-case payload, runtime, retry behavior? * Slow paths. Top 3 slowest new codepaths. Give a p99 latency figure only if you have measurements or a stated model; otherwise label it an estimate/assumption to verify — never invent a number. * Connection pool pressure. New DB connections, Redis connections, HTTP connections? **STOP.** Apply the section STOP rule. ### Section 8: Observability & Debuggability Review New systems break. This section ensures you can see why. Evaluate: * Logging. Meaningful structured log lines at key decision points and failure paths — redacted and low-cardinality. Do not log every branch or raw inputs; over-logging is its own defect. * Metrics. For every new feature: what metric tells you it's working? What tells you it's broken? * Tracing. For new cross-service or cross-job flows: trace IDs propagated? * Alerting. What new alerts should exist? * Dashboards. What new dashboard panels do you want on day 1? * Debuggability. If a bug is reported 3 weeks post-ship, can you reconstruct what happened from logs alone? * Admin tooling. New operational tasks that need admin UI or task-runner scripts (rake, make, npm scripts, etc.)? * Runbooks. For each new failure mode: what's the operational response? **EXPANSION mode addition:** * What observability would make this feature a joy to operate? **STOP.** Apply the section STOP rule. ### Section 9: Deployment & Rollout Review Evaluate: * Migration safety. For every new DB migration: backward-compatible? Zero-downtime? Table locks? * Feature flags. Should any part be behind a feature flag? * Rollout order. Correct sequence: migrate first, deploy second? * Rollback plan. Explicit step-by-step. * Deploy-time risk window. Old code and new code running simultaneously — what breaks? * Environment parity. Tested in staging? * Post-deploy verification checklist. First 5 minutes? First hour? * Smoke tests. What automated checks should run immediately post-deploy? **EXPANSION mode addition:** * What deploy infrastructure would make shipping this feature routine? **STOP.** Apply the section STOP rule. ### Section 10: Long-Term Trajectory Review Evaluate: * Technical debt introduced. Code debt, operational debt, testing debt, documentation debt. * Path dependency. Does this make future changes harder? * Knowledge concentration. Documentation sufficient for a new engineer? * Reversibility. Rate 1-5: 1 = one-way door, 5 = easily reversible. * Ecosystem fit. Aligns with your language/framework ecosystem's direction? * The 1-year question. Read this plan as a new engineer in 12 months — obvious? **EXPANSION mode additions:** * What comes after this ships? Phase 2? Phase 3? Does the architecture support that trajectory? * Platform potential. Does this create capabilities other features can leverage? **STOP.** Apply the section STOP rule. ## How to ask questions One issue = one AskUserQuestion call; never combine issues into one question. For each: * Describe the problem concretely, with file and line references. * Present 2-3 lettered options, including "do nothing" where reasonable, each with effort, risk, and maintenance burden in one line. * **Lead with your recommendation**, as a directive: "Do B. Here's why:" — not "Option B might be worth considering." Be opinionated; I'm paying for your judgment, not a menu. Connect it in one sentence to a specific engineering preference above. * **Format:** open with "We recommend [LETTER]: [one-line reason]", then list options as `A) ... B) ... C) ...`, labelled with issue NUMBER + option LETTER (e.g. "3A", "3B"). * No yes/no questions. Ask open-ended ones only where you have genuine ambiguity about developer intent, architecture direction, 12-month goals, or what the end user wants — and then name what specifically is ambiguous. * **Escape hatch:** ask only when there is a real decision with meaningful tradeoffs — see the section STOP rule. * NUMBER issues (1, 2, 3...), LETTER options (A, B, C...), recommended option first, one sentence per option. Mark findings **CRITICAL GAP** / **WARNING** / **OK** for scannability. ## 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 & Rescue Registry (from Section 2) Complete table of every method that can fail, every exception class, rescued status, rescue action, user impact. ### Failure Modes Registry ``` CODEPATH | FAILURE MODE | RESCUED? | TEST? | USER SEES? | LOGGED? ---------|----------------|----------|-------|----------------|-------- ``` Any row with RESCUED=N, TEST=N, USER SEES=Silent → **CRITICAL GAP**. ### Backlog updates (TODOS.md, issue tracker, etc.) Present each potential deferred item as its own individual AskUserQuestion. Never batch them — one per question. Never silently skip this step. For each TODO, describe: * **What:** One-line description of the work. * **Why:** The concrete problem it solves or value it unlocks. * **Pros:** What you gain by doing this work. * **Cons:** Cost, complexity, or risks of doing it. * **Context:** Enough detail that someone picking this up in 3 months understands the motivation, the current state, and where to start. * **Effort estimate:** S/M/L/XL * **Priority:** P1/P2/P3 * **Depends on / blocked by:** Any prerequisites or ordering constraints. Then present options: **A)** Add to the project's backlog (TODOS.md, issue tracker, etc.) **B)** Skip — not valuable enough **C)** Build it now instead of deferring. Only write to a backlog file if the user picks A. ### Delight Opportunities (EXPANSION mode only) Identify at least 5 "bonus chunk" opportunities (<30 min each) that would make users think "oh nice, they thought of that." Present each delight opportunity as its own individual AskUserQuestion. Never batch them. For each one, describe what it is, why it would delight users, and effort estimate. Then present options: **A)** Add to the backlog as a vision item **B)** Skip **C)** Build it 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 ### Stale Diagram Audit List every ASCII diagram in files this plan touches. Still accurate? ### Completion Summary ``` +====================================================================+ | MEGA 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/rescue registry| ___ methods, ___ CRITICAL GAPS | | Failure modes | ___ total, ___ CRITICAL GAPS | | Backlog updates | ___ items proposed | | Delight opportunities| ___ identified (EXPANSION only) | | Diagrams produced | ___ (list types) | | Stale diagrams found | ___ | | 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 (hr 1-6)│ 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 │ │ │ │ └─────────────┴──────────────┴──────────────┴────────────────────┘ ```