gstack/plan-ceo-review/SKILL.md.tmpl

---
name: plan-ceo-review
preamble-tier: 3
interactive: true
version: 1.0.0
description: |
  CEO/founder-mode plan review. Rethink the problem, find the 10-star product,
  challenge premises, expand scope when it creates a better product. Four modes:
  SCOPE EXPANSION (dream big), SELECTIVE EXPANSION (hold scope + cherry-pick
  expansions), HOLD SCOPE (maximum rigor), SCOPE REDUCTION (strip to essentials).
  Use when asked to "think bigger", "expand scope", "strategy review", "rethink this",
  or "is this ambitious enough".
  Proactively suggest when the user is questioning scope or ambition of a plan,
  or when the plan feels like it could be thinking bigger. (gstack)
benefits-from: [office-hours]
allowed-tools:
  - Read
  - Grep
  - Glob
  - Bash
  - AskUserQuestion
  - WebSearch
triggers:
  - think bigger
  - expand scope
  - strategy review
  - rethink this plan
gbrain:
  schema: 1
  context_queries:
    - id: prior-ceo-plans
      kind: filesystem
      glob: "{gstack_state_root}/projects/{repo_slug}/ceo-plans/*.md"
      sort: mtime_desc
      limit: 5
      render_as: "## Prior CEO plans for this project"
    - id: recent-design-docs
      kind: filesystem
      glob: "~/.gstack/projects/{repo_slug}/*-design-*.md"
      sort: mtime_desc
      limit: 3
      render_as: "## Recent design docs for this project"
    - id: recent-reviews
      kind: list
      filter:
        type: timeline
        tags_contains: "repo:{repo_slug}"
        content_contains: "plan-ceo-review"
      sort: updated_at_desc
      limit: 5
      render_as: "## Recent CEO review activity"
---

{{PREAMBLE}}

{{BASE_BRANCH_DETECT}}

# Mega Plan Review Mode

## Philosophy
Make this plan extraordinary. Match posture:
* SCOPE EXPANSION: Build the platonic ideal, 10x better for 2x effort. Recommend expansions enthusiastically.
* SELECTIVE EXPANSION: Harden current scope; neutrally offer each expansion's opportunity, effort and risk. Accepted items govern later sections; rejected ones go to "NOT in scope."
* HOLD SCOPE: Preserve scope; trace failures, edge cases, error paths, tests and observability.
* SCOPE REDUCTION: Propose the minimum viable core; cut only with approval.
* COMPLETENESS IS CHEAP: AI makes 70 LOC seconds. Prefer complete ~150 LOC over 90% ~80 LOC. Boil the ocean.
Approval is required for each scope change. Raise concerns in Step 0, then commit: no arguing for less in EXPANSION, silent SELECTIVE additions/cuts, or scope restored to REDUCTION.
Review only. Do not change code or implement.

## Prime Directives
1. Zero silent failures: surface every failure to system, team and user.
2. Name each error's class, trigger, handler, user result and test; flag catch-alls.
3. Trace happy, nil, empty/zero and upstream-error paths.
4. Map double-clicks, navigation, slow links, stale state and back button.
5. Dashboards, alerts and runbooks are launch scope.
6. Require ASCII diagrams for new flows, state, pipelines, deps and decisions.
7. Record every deferral in TODOS.md or chat per storage policy.
8. Optimize for the 6-month future; flag future harm.
9. Propose better approaches now, including "scrap it and do this instead."

## Engineering Preferences (use these to guide every recommendation)
* DRY: flag repetition aggressively.
* Tests are required; prefer too many to too few.
* Avoid fragile hacks, premature abstractions and unnecessary complexity.
* Favor more edge cases and thoughtfulness over speed; explicit over clever.
* Prefer the smallest clear diff; broken foundations may need a rewrite under directive #9.
* New codepaths need logs, metrics or traces and threat modeling.
* Plan partial deploys, rollbacks and feature flags.
* Add and maintain ASCII comments for complex state, pipelines, requests, mixins and test setup.

## Priority Hierarchy Under Context Pressure
Step 0 > System audit > Error/rescue map > Test diagram > Failure modes > Opinionated recommendations > Everything else.
Never skip Step 0, system audit, error/rescue map or failure modes.

{{ASIDE_RESEARCH}}

{{ANTI_SHORTCUT_CLAUSE}}

## PRE-REVIEW SYSTEM AUDIT (before Step 0)
Before anything else, audit the system for review context. Run:
```
git log --oneline -30                          # Recent history
git diff <base> --stat                           # What's already changed
git stash list                                 # Any stashed work
grep -r "TODO\|FIXME\|HACK\|XXX" -l --exclude-dir=node_modules --exclude-dir=vendor --exclude-dir=.git . | head -30
git log --since=30.days --name-only --format="" | sort | uniq -c | sort -rn | head -20  # Recently touched files
```
Then read CLAUDE.md, TODOS.md, and any existing architecture docs.

**Design doc check:**
```bash
setopt +o nomatch 2>/dev/null || true  # zsh compat
SLUG=$(~/.claude/skills/gstack/browse/bin/remote-slug 2>/dev/null || basename "$(git rev-parse --show-toplevel 2>/dev/null || pwd)")
BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null | tr '/' '-' || echo 'no-branch')
{{DESIGN_DOC_DISCOVERY}}
```
Read any `/office-hours` design doc as the problem, constraints and approach source of truth. `Supersedes:` marks a revised design.

**Handoff note check** (reuses $SLUG and $BRANCH from the design doc check above):
```bash
setopt +o nomatch 2>/dev/null || true  # zsh compat
HANDOFF=$(ls -t ~/.gstack/projects/$SLUG/*-$BRANCH-ceo-handoff-*.md 2>/dev/null | head -1)
[ -n "$HANDOFF" ] && echo "HANDOFF_FOUND: $HANDOFF" || echo "NO_HANDOFF"
```
In a separate shell, first recompute $SLUG and $BRANCH with the design-doc commands.
Read any paused CEO `/office-hours` handoff alongside the design doc; reuse its audit
and discussion without repeating questions or skipping review steps. Tell the user:
"Found a handoff note from your prior CEO review session. I'll use that context to pick up where we left off."

{{BENEFITS_FROM}}

**Mid-session detection (0A):** If the user cannot articulate a stable problem, says "I'm not sure"
or is exploring rather than reviewing, offer `/office-hours`:

> "It sounds like you're still figuring out what to build — that's totally fine, but
> that's what /office-hours is designed for. Want to run /office-hours right now?
> We'll pick up right where we left off."

Options: A) Yes, run /office-hours now. B) No, keep going.
If they keep going, proceed normally — no guilt, no re-asking.

If they choose A:

{{INVOKE_SKILL:office-hours}}

Note current Step 0A progress so you don't re-ask questions already answered.
After completion, re-run the design doc check and resume the review.

Map current system state, in-flight PRs/branches/stashes, relevant pain points and
FIXME/TODOs in touched files. From TODOS.md, record related prior deferrals and
work this plan touches, blocks, unlocks or depends on.

### Retrospective Check
Record earlier review refactors/reverts and overlap with this plan. Scrutinize prior problem areas; flag recurring problems as architectural concerns.

### Frontend/UI Scope Detection
Note DESIGN_SCOPE for Section 11 if the plan changes UI screens/components, user interactions, frontend frameworks, user-visible states, mobile/responsive behavior or design systems.

### Taste Calibration (EXPANSION and SELECTIVE EXPANSION modes)
Choose 2-3 good files/patterns as references and 1-2 poor ones to avoid. Report before Step 0.

### Landscape Check

Read ETHOS.md at the preamble's Search Before Building path. Before challenging scope, research through Aside (readiness above), one read-only request per query:
- "[product category] landscape {current year}"
- "[key feature] alternatives"
- "why [incumbent/conventional approach] [succeeds/fails]"

```bash
{{ASIDE_EXEC_PRELUDE}}
_aside_exec "Search the web for [product category] landscape {current year} and [key feature] alternatives. Read-only: do not sign in, submit, or change anything. Reply with up to 8 bullets, each with its source URL, then stop."
```

If the Aside check did not print `READY`, run the same queries with the WebSearch tool when the host provides it; with neither, skip this check and note: "Search unavailable — proceeding with in-distribution knowledge only."

Run the three-layer synthesis:
- **[Layer 1]** What's the tried-and-true approach in this space?
- **[Layer 2]** What are the search results saying?
- **[Layer 3]** First-principles reasoning — where might the conventional wisdom be wrong?

Use this in 0A and 0C. Surface any eureka as differentiation at Expansion opt-in; log it per the preamble.

{{LEARNINGS_SEARCH}}

{{GBRAIN_CONTEXT_LOAD}}

{{BRAIN_PREFLIGHT}}

{{SECTION_INDEX:plan-ceo-review}}

## Step 0: Nuclear Scope Challenge + Mode Selection

Startup:
1. Choose the review depth and artifact destinations, then open the ledger below.
2. Record 0A–0C evidence; call 0D only for a required approach choice.
3. Select the mode in 0E and follow its route table.
4. Complete Review Sections and its closing sequence; return to Section self-check.

0D is reusable, not an unconditional question. Observations do not approve changes.

**Set review depth from the user's request.** Default to implementation-ready.
Use strategy-only only when the user asks for strategy, scope, or prioritization
without implementation design. Use one narrow decision only when the user names a
single choice. To expand strategy-only into implementation design, use 0D with
**A)** Keep this review strategy-only **B)** Add implementation design for the
named capability. Recommend A unless a concrete blocker requires B; wait for the
answer. B permits design detail for that capability only.
Resolve a choice only when output would be wrong without it, a blocker would be
hidden, or scope would change. Reuse prior answers only for the same scope.

Plain terms:
- **Required choice:** a mode, scope, deferral, TODO, spec, outside-review or
  finding decision needed before the next step.
- **Pending:** recorded in the ledger and waiting for approval.
- **Settled:** answered by the user, directly instructed, or auto-authorized by
  the preamble.

Review depth controls the detail within each section. Review Sections 1–10 in every depth;
run Section 11 only for UI. Strategy-only uses capability-level rows and
"implementation owner must prove ___" notes, including the Error & Rescue map.
Implementation-ready names interfaces, codepaths, rescue behavior and tests.
For one narrow decision, apply every section to that choice and its dependencies.

**Keep the stated limits.** Record each measure, value, unit and prerequisite. Count all deliverables, including reused code, as scope; 0E estimates only files that will change. Changing a limit needs evidence and user approval.

**Storage policy: choose before writing.** Honor user/host artifact and cleanup
limits. One working plan: requested output, else reviewed plan, else host active
plan. Use native Write for a missing file and scoped Edit for checkpoints;
retain all current content, ledger rows and comparisons.

**Artifact outcomes:** Never claim an unconfirmed save, read-back or log.
When writing is forbidden, continue analysis and decisions without writing.
Present complete artifacts as **not persisted**. At finalization, an unsaved
plan/report means **completion blocked**: no completion log, success telemetry,
ExitPlanMode or next-skill handoff.

| Permitted write | On failure |
|---|---|
| Plan/report, CEO summary, approved TODOs and tasks | Stop with the cause; chat cannot replace a failed save. Missing jq may omit only task JSONL, as the task instructions explain. |
| 0H spec-review metrics | Stop with the cause; reviewer availability does not waive this write. |
| Review, decision and question history logs | Report cause and unsaved fields; continue. The plan's ledger is still required. |

Paths are per output: resolve the CEO archive as `CEO_PLANS` in 0H; tasks
use `~/.gstack/projects/`, metrics use `~/.gstack/analytics/`, and log helpers
choose their own paths. Do not substitute the CEO archive root for these paths.

Keep one decision ledger through Step 0, Spec Review Loop and Outside Voice:

| ID and owner | Contract and evidence | Current | Proposed | Status | Exact approval and scope |
|---|---|---|---|---|---|

Name owners; cite evidence, conventions and tests; mark unknowns. Current holds approved values; Proposed holds alternatives. Status: unresolved, approved, reopened, deferred or declined. Cite actual instructions/answers and exact scope.

### 0A. Premise Challenge
Name the real problem, target outcome and do-nothing cost. Say whether the plan
solves the pain directly or only a proxy.

### 0B. Existing Code Leverage
Map each sub-problem to reusable code. For any rebuild, explain why refactoring
the existing path is worse.

### 0C. Dream State Mapping
Describe the 12-month ideal and whether this plan moves toward it.
```
  CURRENT STATE                  THIS PLAN                  12-MONTH IDEAL
  [describe]          --->       [describe delta]    --->    [describe target]
```

Before 0E, call 0D for unresolved approaches: A) current/requested plan,
B) smallest scoped alternative, C) larger approach/rewrite only with evidence.
With no required choice, or after those choices settle, go to 0E.

### 0D. Alternatives (reusable decision procedure)

**Choose the question's route first:**
- **Admin question:** mode, setup, navigation, document approval or promotion.
  Use its listed menu and the preamble question transport, then wait and record
  the answer. Skip steps 1–4; this approves no plan changes. For mode selection,
  0E defines the four-option menu and any authorized automatic preference;
  neither needs a plan-decision row, comparison grid or completeness score.
- **Plan decision:** review-depth expansion, scope additions/cuts, approach
  choices, TODOs, specs and review/outside findings. Start at step 1. Reuse exact
  prior approvals; run steps 2–4 only when a new answer is needed, even for one option.

If an admin answer requests a plan change, use the Plan decision route for that
change. 0D never restarts mode selection.

**1. Check sources and prior answers.**
Compare input, source and answers; correct facts, flag conflicts and preserve unknowns.
Reuse exact approvals. Reopen only for contradictions, changed assumptions or
user instructions, never speculation or reviewer agreement. With no new answer
needed, cite settled answers and return; invent no alternatives or approval.

**2. Record the pending choice.**
Give independent changes separate ledger rows; explain necessary coupling. Record
owner, behavior, limits, test method and coverage in Current/Proposed. Cite the
source filename/message and section/lines when available.

| Test choice | Treatment |
|---|---|
| Code change and required regressions | Keep together; carry both forward once approved. |
| Approved change with open test method/coverage | Decide once; every option preserves required behavior and approved tests. |
| Tests for existing behavior | Separate independently selectable additions. Tests for undecided behavior stay pending. |

Record pending rows before comparisons; never prewrite approval or tasks.

**3. Compare and save that row's options.**
Build one `currentDecision` using these fields and the preamble format:

| Field | Required content |
|---|---|
| `question` | Full brief: `D<N> — <ROW-ID>: <one-line question>`, Project, ELI10, Stakes, Recommendation and applicable completeness/net text. D counts questions; ROW-ID identifies the pending choice. |
| `header` and option labels | Final native text within host limits; exactly one label includes `(recommended)`. |
| Each option's `description` | A 1–2 sentence summary; S/M/L/XL effort, low/medium/high risk, reuse, verification coverage, at least 2 ✅ pros and 1 ❌ con. Apply the preamble's minimum lengths and destructive-choice exception. |

For a plan decision without a prescribed menu, offer 2–3 options (prefer 3 for
non-trivial plans). This default does not replace an admin or scope menu.
For an option with no implementation, use effort S and state zero implementation
work, never effort 0. Weigh diff size and long-term architecture equally,
including rewrites: state the immediate changed-file cost and the future
maintenance cost for each option, then explain both in the recommendation.

In Proposed, compare every commitment in the labels, descriptions and pros/cons:

```text
Commitment | Source/approval or pending | Current | A | B | C
```

Include one column per option (add D for a four-option menu). Show unchanged,
shared and pending values. Changes remain separate decisions even if they use the same framework.
Keep other rows fixed or pending; preserve requirements, tests and fixes.

Score this row's coverage differences: 10 = all edge cases, 7 = happy path,
3 = shortcut. For different kinds of work, write:
"Note: options differ in kind, not coverage — no completeness score."

**Pre-question checkpoint:** Validate every field above before saving.
Find exactly one row by its assigned ID; verify owner, Current/Proposed, Status
and Exact approval and scope. Repair missing/duplicate rows in step 2.
Effort/risk must each be one listed value, never a range. Correct missing or
invalid fields and host-limit violations before saving.

- **Save.** Under the storage policy, save/present the complete current plan,
  pending rows and comparisons. Copy the grid and all exact fields below,
  without the illustrative fence delimiters:

  ```text
  ## currentDecision (ROW-ID)
  Commitment comparison: <complete grid>

  Question: <complete currentDecision.question>
  Header: <exact currentDecision.header>
  A) <exact first option label>
  <full first option description>
  B) <exact second option label>
  <full second option description; repeat for all offered options>
  ```

  Replace the whole payload on revision.
  Keep answered decisions and their answers under separate headings.
- **Read-back.** After the latest successful Write/Edit, Read the ledger row and
  full payload through the last option's description; fetch continuations.
  Verify IDs and fields against `currentDecision`, citations against source.
  Read despite Edit's current-in-context hint. For chat, verify the complete text
  labeled **not persisted**. A grid, summary or pointer is insufficient.

A failed save stops the review. Correct mismatches, save and Read again before dispatch.

**4. Ask, record the answer, and amend.**
Copy the verified Read or chat text into one native arguments object:
`{questions: [{question, header, options: [{label, description}, ...]}]}`.
Compare its question, header, labels and full descriptions literally with the
verified fields, ignoring only saved selector prefixes such as `A)` or `B)`.
Compare strings, not format/scores. Changes repeat step 3's save and Read-back.
Ask one row per call with that object unchanged, without recomposing.
Only the preamble can authorize prose or auto-decision transport.

**STOP for the actual answer, even for a lone option.** Only a preamble-authorized
auto-decision resolves this wait; record its authority. Save the answer reference
and scope in Exact approval and scope, update Status and amend only authorized
work. A recommendation is not approval; do not edit code.

**Post-answer checkpoint:** Save or present the complete amended plan under the
storage policy before taking another row.

If all options are declined, continue only with a viable current approach retained
by the answer; otherwise leave the row unresolved and stop for direction.

Return to the calling step with the saved answer; do not ask it again.
Record findings even after resolution; say "No issues, moving on." only with none.

### 0E. Mode Selection
Follow the preamble's session rules; `CONDUCTOR_SESSION: true` changes transport only.

1. An explicit choice skips steps 2–3. "Go big", "ambitious" or "cathedral" means SCOPE EXPANSION; "hold scope but tempt me", "show me options" or "cherry-pick" means SELECTIVE EXPANSION.
2. Recommend without selecting. Count distinct planned file additions, edits and deletions, labeling estimates. For >15 planned changed files, recommend SCOPE REDUCTION. Otherwise: a new product/system (greenfield) → SCOPE EXPANSION; added capability → SELECTIVE EXPANSION; fix/refactor → HOLD SCOPE. If categories overlap or are unclear, explain why and recommend HOLD SCOPE.
   In the Recommendation's `because` clause, connect a concrete plan fact or
   constraint to this mode's actual benefit or tradeoff. Count/category alone
   is not a reason.
3. Resolve that recommendation. Mode selection is an admin choice, not a plan
   decision. When `QUESTION_TUNING: true`, first check `question_id=plan-ceo-review-mode` through the preamble.
   A check that exits 0 with `AUTO_DECIDE` selects the recommendation; go to the automatic handoff in
   step 4. When tuning is false, omit the lookup.
   Without that successful check, offer all four modes in one AskUserQuestion,
   using step 2's recommendation. **STOP for the answer**; the user's choice
   wins. When `QUESTION_TUNING: true`, include `<gstack-qid:plan-ceo-review-mode>`.
   These modes differ in kind, not coverage; do NOT score completeness.

4. **Mode handoff:** After selection, send brief chat before tools or further questions: the mode's application and rationale; every governing approved row's ID, answer reference and accepted scope. Keep rows separate.
- `plan-ceo-review-mode: AUTO_DECIDE`: `Auto-decided review mode → <selected mode> (your preference). Change with /plan-tune. Approved decisions: <rows or none>. <Application and rationale>.`
- Other selections: `Mode: <selected mode>; approved decisions: <rows or none>. <Application and rationale>.`

Record mode provenance after the handoff:
- **Explicit user choice:** instruction and mode; no question log because none was asked.
- **Successful preference check:** result and recommendation; log `plan-ceo-review-mode`, `auto_decided: true`.
- **Actual question answer:** question, answer reference and mode; log `auto_decided: false`, including the question ID only when `QUESTION_TUNING: true`.

If 0D needed no approach choice, say "No new approach decision was needed" after
the mode handoff. This records no plan decision, not automatic mode approval.
Ask before changing a previously chosen mode.

Selecting a mode does not approve changes. Preserve 0D approvals and ask about
each proposed addition or cut, including those prompted by file-count thresholds.

Follow the selected mode's route:

| Mode | Remaining Step 0 work |
|------|----------------------|
| SCOPE EXPANSION / SELECTIVE EXPANSION | 0F → 0G → 0H (including its spec review loop) → 0I |
| HOLD SCOPE | 0G → 0I |
| SCOPE REDUCTION | 0G |

Continue to Review Sections, outputs and report.

### 0F. Expansion Framing (shared by EXPANSION and SELECTIVE EXPANSION)

Prepare pending candidates for 0G: user experience, concrete addition, S/M/L/XL
effort, risk and impact. Explain ambition enthusiastically in SCOPE EXPANSION;
balance benefits and tradeoffs without unsupported promises in SELECTIVE
EXPANSION. Mark one option `(recommended)` when presenting choices; this label
does not approve scope. The user decides each proposal in 0G.

### 0G. Mode-Specific Analysis
In expansion modes, extend 0F's pending list with this analysis, then resolve
each proposal individually.

**For SCOPE EXPANSION:**
1. **10x check:** Describe 10x value for 2x effort.
2. **Platonic ideal:** What would the best engineer with unlimited time and perfect taste build? Start with the user's experience.
3. **Delight scan:** List at least 5 adjacent 30-minute improvements that would delight the user.
4. **Expansion opt-in ceremony:** Present visions and individual proposals; enthusiastically explain each one's value. The user decides.

**For SELECTIVE EXPANSION:**
1. Run all three HOLD SCOPE checks below, including their defer/keep decisions.
2. Describe 10x ambition, run the delight scan and assess platform potential. Candidates stay pending until scope answers.
3. **Cherry-pick ceremony:** Use 0F with S/M/L/XL effort and risk. For more than 8, present the top 5–6; offer the rest on request.

For both expansion modes, ask separately for each addition: **A)** Add to this plan's scope **B)** Defer to TODOS.md **C)** Skip. Accepted items govern the remaining sections.

**For HOLD SCOPE** — run this:
1. Complexity check: at more than 8 files or more than 2 new classes/services, challenge whether fewer moving parts achieve the same goal.
2. Find the minimum changes for the goal; flag work deferrable without blocking it.
3. Keep stated invariants and acceptance criteria; repairs needed to meet them are in scope.

**For SCOPE REDUCTION:** propose minimum scope and resolve each proposed deferral
with the defer/keep menu below; retain the rest.

**Deferring current scope** (REDUCTION, HOLD and SELECTIVE's HOLD checks): ask
separately per item: **A)** Defer this item to TODOS.md **B)** Keep it in scope.

Run all four 0D steps for each unanswered addition or deferral, using its menu.
These scope choices differ in kind; do not score completeness. Keep other scope
fixed or pending; wait for the answer before applying it.
A deferral changes only delivery scope: record its answer/reason beside the prior
approval. Keep other approvals and limits unchanged. In later sections, review
the retained work and accepted additions; list deferred or rejected work as excluded.

Save dispositions under the storage policy:
- **Add / Keep:** accepted working-plan scope.
- **Defer:** TODOS.md with context and NOT in scope with the deferral reason. This postpones work; it does not reject it.
- **Skip / Cut:** NOT in scope with the rejection reason; no TODO.

Reuse answered scope decisions without another question or comparison. Inclusion
does not settle pending implementation choices; keep those rows visible.

### 0H. Persist CEO Plan (EXPANSION and SELECTIVE EXPANSION only)

Prepare the full amended working plan and a separate CEO scope summary. Keep
behavior, requirements and scope consistent; the summary cannot serve as the plan.

**Save or present both inputs under the storage policy.** For permitted storage:

```bash
eval "$(~/.claude/skills/gstack/bin/gstack-slug 2>/dev/null)"
eval "$(~/.claude/skills/gstack/bin/gstack-paths)"
CEO_PLANS="$GSTACK_STATE_ROOT/projects/$SLUG/ceo-plans"
mkdir -p "$CEO_PLANS"
echo "CEO_PLANS=$CEO_PLANS"
```

Use `{printed CEO_PLANS}/{YYYY-MM-DD}-{feature-slug}.md`. Archiving old (>30 days) or merged/deleted-branch plans requires approval.

**Otherwise:** Present both inputs in full as not persisted.

**CEO summary format — use for both saved and chat output:**

```markdown
---
status: ACTIVE
---
# CEO Plan: {Feature Name}
Generated by /plan-ceo-review on {date}
Branch: {branch} | Mode: {EXPANSION / SELECTIVE EXPANSION}
Repo: {owner/repo}

## Plan under review
{working plan path, or "Working plan — complete text in chat; not persisted"}

## Vision

### 10x Check
{10x vision description}

### Platonic Ideal
{platonic ideal description — EXPANSION mode only}

## Scope Decisions

| # | Proposal | Effort | Decision | Reasoning |
|---|----------|--------|----------|-----------|
| 1 | {proposal} | S/M/L/XL | ACCEPTED / DEFERRED / SKIPPED | {why} |

## Accepted Scope (added to this plan)
- {bullet list of what's now in scope}

## Deferred to TODOS.md
- {items with context}

## Reviewer Concerns
- {unresolved spec-review issues with their owning input, or "None"}
```

{{SPEC_REVIEW_LOOP}}

After the loop completes or reports unavailable, present both inputs for final
scope-document approval. Ask with the preamble question transport:
**A)** Approve these documents and continue to 0I **B)** Revise these documents
**C)** Pause this review. Recommend A only if both reflect the exact decisions.
Wait and record the answer. A accepts these document versions only; unresolved
amendments and implementation remain unapproved. For B, resolve the requested
changes through 0D, update both inputs and repeat document approval. C stops.
After A, run 0I before Review Sections.

### 0I. Temporal Interrogation (EXPANSION, SELECTIVE EXPANSION, and HOLD modes)
Resolve scope and feasibility blockers through 0D now. Keep other design choices
pending unless the user requested implementation planning.
```
  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?
```
Save the sequence, feasibility blockers and pending choices in the plan, with human-team and CC + gstack effort.

Carry the ledger and each answer's exact scope into the review sections.

## Continue after Step 0 (all modes)

{{SECTION:review-sections}}

## Section self-check (before you finish)

Confirm you Read `sections/review-sections.md` and executed Sections 1–10,
Section 11's findings or no-UI skip, required outputs and report from that file.
If the Summary or report preceded that Read, stop, Read and redo the review.

{{EXIT_PLAN_MODE_GATE}}

**Gate outcome:**
- **Pass with log-only gaps:** A verified report plus forbidden metadata or
  failed best-effort history can pass. Mark unsaved fields **not persisted**.
  Failed required writes still block.
- **Blocked:** Return the failed check and complete plan, report and summary.
  Label only unwritten artifacts **not persisted**; missing logs do not unsave
  a verified report. State **completion blocked**; end without success telemetry,
  ExitPlanMode or the queued handoff. Resume when the blocker is resolved.
- **Passed with a verified persisted report:** finish the cache refresh below,
  then run telemetry as the last review operation.

{{BRAIN_CACHE_REFRESH}}

After the refresh, run the preamble's **Telemetry (run last)** once. The review
is now finished. Call ExitPlanMode where required or return to the caller;
the chosen next-skill handoff starts a separate workflow.