--- name: founder-review description: CEO/founder-mode scope and ambition review. Rethink the problem, find the 10x product, challenge premises, expand or cut scope deliberately — across four committed modes (SCOPE EXPANSION, SELECTIVE EXPANSION, HOLD SCOPE, SCOPE REDUCTION). Fires upstream of execution on a /plan artifact, STRATEGY.md, /brainstorm output, or an ad-hoc scope question; produces a scope decision and routes deep rigor back to /doc-review and /code-review in a closed loop. Triggers on "think bigger", "expand scope", "is this ambitious enough", "rethink this", "scope review", or a /ceo-review invocation. Does not implement, record strategy, file issues, or change code. --- # Founder Review `/founder-review` (alias `/ceo-review`) answers **"Is this the right, ambitious-enough thing to build at all?"** It is the **scope / ambition / direction** review **lens** — the third member of the review trio: - **`/doc-review`** = *readiness* ("can this plan safely drive implementation?") - **`/code-review`** = *code* ("is the built code safe to merge?") - **`/founder-review`** = *scope & ambition* ("is this the right, ambitious-enough thing, and is the scope shaped correctly?") Unlike its two siblings, it fires **upstream of execution** — on a `/plan` artifact, a `STRATEGY.md`, a `/brainstorm` output, or an ad-hoc scope question — and its output is a **scope decision**, not a readiness/code review artifact. It **challenges** direction; `/strategy` **records** it; `/plan` **re-plans** accepted scope; and it hands any (re-)expanded plan **back** to `/doc-review` and `/code-review` for depth — a real closed loop, not a hand-wave. ## Position in the lifecycle `/founder-review` runs **before** the work thread, so it is **not** a saga consumer and **never writes the saga** (no `saga.py` call, no `--review-paths`). Cross-session persistence is the `docs/founder-reviews/` scope-decision artifact plus the engineering-journal ADR. - `/office-hours` answers: "What should we even build?" (framing) - `/brainstorm` answers: "What are the requirements and candidate approaches?" (the WHAT) - **`/founder-review` answers: "Is this scope right and ambitious enough?"** (this engine) - `/plan` answers: "How should it be built?" (the HOW) - the `review` phase (`/doc-review`) answers: "Is this plan ready to execute?" - `/work` -> `/code-review` -> `/qa` answer: "Build it, is it safe to merge, does it actually work?" ### founder-review vs doc-review (the boundary) Both engines can target a `STRATEGY.md` or scope document (`/doc-review`'s path tie-breaker maps `STRATEGY.md -> strategy/scope`). They are **complementary lenses, not a collision**: - **`/founder-review` = the ambition lens** — *challenge the direction*: is it ambitious? coherent? worth doing? is the scope shaped right? - **`/doc-review` = the readiness lens** — *check execution-readiness*: can this drive implementation without inventing missing decisions? `/doc-review` already cross-suggests `/founder-review` "when strategy, product scope, ambition, or user-facing behavior is prominent" — that is the **inbound** edge. `/founder-review` closes the loop **outbound** by writing/updating the (re-)expanded plan and handing it back with the path. No `/doc-review` edit is needed. ## Core principles 1. **Review, not implement.** `/founder-review` challenges scope/ambition/direction and captures decisions. It does **NOT** make code changes, does **NOT** start implementation, does **NOT** commit, does **NOT** push, does **NOT** open PRs, and does **NOT** file SDLC issues. Its only writes are the `docs/founder-reviews/` artifact and (downstream, separately) the journal. ZERO writes to reviewed code. 2. **User 100% in control.** Every scope change is an explicit opt-in (via `AskUserQuestion`, or inline in a channel). Never silently add or remove scope. Once a mode is chosen, **commit to it — no silent drift.** Raise concerns once in Step 0; after that, execute the chosen mode faithfully. 3. **Internalize the CEO patterns, don't enumerate them.** The 18 CEO cognitive patterns and 9 Prime Directives (`references/ceo-cognition.md`) are thinking instincts that shape the whole review, not a checklist to read aloud. They turn a vibe into a named, concrete scope finding. 4. **Ground before challenging.** Run the adapted pre-review system audit and the premise challenge first — a grounded critique, not opinion. Apply the **no-false-precision** posture: when you cite a number (effort, file count, scope size) present it and let the operator judge; use **no hardcoded "too big / too small" thresholds** (the `>15-files -> Reduction` line is a suggestion the operator can override, not a verdict). Stolen sharpened from CE `product-pulse`. 5. **Challenge direction, don't record it.** `/strategy` records the chosen direction; `/founder-review` challenges whether it is ambitious, coherent, and worth doing. On a `STRATEGY.md` target, `/founder-review` is the *ambition* lens and `/doc-review` the *readiness* lens — complementary, not duplicative. 6. **Agent-actionable + closed-loop.** Accepted scope -> `/plan` (re-plan). The (re-)expanded plan is written/updated and handed **back** to `/doc-review` (readiness) and `/code-review` (code) **with the artifact path** — so the deep rigor that gstack bundled into 11 sections actually runs, just in the right engine. Direction shifts -> `/strategy` (record). Nothing is left as vague intention. ## Interaction method Use `AskUserQuestion` for choices from a known set (mode selection, per-expansion opt-in, the chosen implementation approach, execution backend). Call `ToolSearch` with `select:AskUserQuestion` first if its schema is not loaded. Ask one issue per question — never batch multiple decisions into one. Never silently skip a question or silently default. In a channel session (`redis-channel` active), `AskUserQuestion` cannot be called — inline the choices in your reply text instead, and use the **digest** path for expansions (see Phase 2 and `references/review-modes.md`). Follow the canonical channel-inline convention in `saga/skills/brainstorm/SKILL.md` (do not duplicate its wording here). **Operator-absence contract (#371).** Every known-set gate above declares what happens on silence, and the declaration above this line is the contract. `HALT` here: stop and wait. A timeout, a widget error, or a dropped session is never consent — do not proceed on a default and do not invent an answer. Ask one question at a time and read the decision from the operator's actual answer, never from a widget's raw return value. Use repo-relative paths in every generated document. Absolute paths break portability across machines and worktrees. --- ## Phase 0 — Enter, detect target type, system audit Capture the target AND **classify its type** — this drives the conditional ceremonies in Phase 1: - **plan** — a `/plan` artifact under `docs/plans/` (run the full faithful gstack Step 0). - **strategy** — `STRATEGY.md` or a strategy/scope document. - **brainstorm** — a `/brainstorm` output under `docs/brainstorms/`. - **scope-question** — an ad-hoc "is this ambitious enough?" with no artifact yet. If the target is ambiguous, ask before reviewing. Then run the **adapted pre-review system audit** (full procedure in `references/review-modes.md`): git log/diff/stash + recently-touched files + TODO/FIXME scan; read the target + `docs/office-hours/` notes + root `STRATEGY.md` + `docs/engineering-journal/` (DECISIONS/QUEUED) + `CLAUDE.md`; then the four lenses — retrospective check, frontend/UI scope detection (`DESIGN_SCOPE`), taste calibration (EXPANSION + SELECTIVE only), and the landscape `WebSearch` (skip gracefully if unavailable: "Search unavailable — proceeding with in-distribution knowledge only"). Report audit findings before Step 0. --- ## Phase 1 — Scope challenge & mode selection (Step 0) Run Step 0 (sub-steps detailed in `references/review-modes.md`): - **0A. Premise challenge** — right problem? actual outcome vs proxy? do-nothing cost? **+ office-hours escape:** if the session is vague/unframed (can't articulate the problem, keeps changing it, "I'm not sure", clearly exploring), offer to run `/office-hours` now and resume after (re-read `docs/office-hours/` notes on return). A prose offer, not guilt. - **0B. Existing-code leverage** — what already solves each sub-problem? Is this rebuilding something better refactored? - **0C. Dream-state mapping** — current -> this plan -> 12-month ideal; moving toward or away? - **0C-bis. Implementation alternatives — TARGET-CONDITIONAL.** target=plan -> produce 2-3 distinct approaches (one minimal-viable, one ideal-architecture, **equal weight**) + a recommendation, and get explicit approval before mode selection. target=strategy/brainstorm/scope-question -> **skip**, or downgrade to "strategic options" (channel -> single recommended-approach confirm). - **0E. Temporal interrogation — TARGET-CONDITIONAL.** target=plan -> the HOUR-by-HOUR implementation interrogation (present human + CC effort scales; no false precision). Else -> **recast** as "what must be resolved before this becomes a plan?" - **0F. Mode selection** — present the 4 modes via `AskUserQuestion` (channel -> inline) with a context-default recommendation; state **"options differ in kind, not coverage — no completeness score"**; once selected, **commit, no silent drift.** Gate-divergence telemetry (optional, issue #399): record via `gate_id` `founder-review-mode-selection` per the run record, which is where a gate interaction and its outcome are now recorded. The mode selection is a durable gate-record (`founder-review-mode-selection-`) under the Interaction-method contract above: open before prompting, satisfy on answer, `resolve-absent` on silence (`HALT`). --- ## Phase 2 — Mode-specific scope analysis Run the branch for the committed mode (full ceremonies in `references/review-modes.md`): - **SCOPE EXPANSION** — 10x check + platonic ideal + delight opportunities, then the **opt-in ceremony**: each expansion as its own `AskUserQuestion`, recommended *enthusiastically*, framed **FLAT -> EXPANSIVE** (lead with the felt experience, close with effort + impact). Options: **A) add / B) defer (-> journal/QUEUED) / C) skip**. Gate-divergence telemetry (optional, issue #399): record each expansion decision via `gate_id` `founder-review-expansion-optin` per the run record, which is where a gate interaction and its outcome are now recorded. Each expansion opt-in is a durable gate-record (`founder-review-expansion-optin--`) under the Interaction-method contract above: open before prompting, satisfy on answer, `resolve-absent` on silence (`HALT`). - **SELECTIVE EXPANSION** — run the HOLD analysis (complexity + minimum-change) as the bulletproof baseline, then the expansion scan, then the **cherry-pick ceremony** (same A/B/C, **neutral** posture). - **HOLD SCOPE** — complexity check + minimum-change rigor. Do not silently expand or reduce. - **SCOPE REDUCTION** — ruthless cut to the minimum that ships value; split the rest into follow-ups. **Cap the ceremony:** if more than 8 candidates, present the **top 5-6** and note the remainder. **Channel session:** present a **digest** ("5 opportunities — one-at-a-time, or recommend the top 2?") — never 5 serial inlined blocks. Accepted items join scope for the rest of the review; rejected go to "NOT in scope". --- ## Phase 3 — Founder rigor pass (directives + patterns -> concrete findings) Apply the 9 Prime Directives and 18 CEO patterns (`references/ceo-cognition.md`) at the **scope/direction layer**, producing **named, concrete scope-level findings** — not vibes: - zero-silent-failures-as-scope, every-error-has-a-name, data-flows-have-shadow-paths, observability-is-scope, optimize-for-the-6-month-future, inversion reflex, focus-as-subtraction, proxy skepticism, scrap-it permission, design-for-trust (when `DESIGN_SCOPE`), … Each finding is concrete (e.g., "this accepted expansion adds a data flow with no named error path — resolve before `/doc-review`"), then the **ambition / coherence / worth-it verdict**. **Route deep rigor in a CLOSED LOOP — do NOT reproduce gstack's 11 review sections.** The deep section-by-section rigor (Architecture, Error-&-Rescue map, Security, Data-flow, Code-quality, Test, Performance, Observability, Deployment, Long-Term Trajectory, Design & UX) is the **readiness** and **code** lenses' job. After scope is decided, **write/update the (re-)expanded plan artifact** and name the **concrete handback**: "run `/doc-review docs/plans/` for readiness depth; `/code-review` once built." Without writing the artifact and naming its path, expanding scope then "recommending `/doc-review`" silently drops the rigor — the closed loop is what prevents that. --- ## Phase 4 — Synthesize the scope-decision artifact Write `docs/founder-reviews/YYYY-MM-DD--founder-review.md` — its **own** scope-decision directory (**NOT** `docs/reviews/` = readiness, **NOT** `docs/code-reviews/` = code, and deliberately **not** a `mission-control` artifact source). Format (full template in `references/review-modes.md`): - **Frontmatter** — `status`, `type: founder-review`, `date`, `origin` (the target path/identity). - **Mode** + target (type + path). - **Vision** (EXPANSION + SELECTIVE only) — 10x check + platonic ideal. - **Scope Decisions** table — `# | Proposal | Effort | Decision (ACCEPTED/DEFERRED/SKIPPED) | Reasoning`. - **Accepted Scope** — now in this plan. - **Deferred** — routed to the engineering journal / QUEUED with enough context to pick up cold (never a stray `TODOS.md` — vague intentions are lies). - **Premise findings** — the concrete 0A/0B/0C findings. - **Founder verdict** — **ship / sharpen / scrap-and-rethink** + the concrete next-command handback (the expanded-plan path -> `/doc-review`). --- ## Phase 5 — Route + operator-choice **Closed-loop route:** - Accepted scope -> **`/plan`** (re-plan). Write/update the (re-)expanded plan. - The (re-)expanded plan -> **`/doc-review docs/plans/`** (readiness depth) **with the path**, and **`/code-review`** (code) once built. This is the closed loop — name the path, don't just say "run /doc-review". - Direction shifts -> **`/strategy`** (record the chosen direction). **Operator-choice.** On a scope-expansion or scrap-and-rethink verdict, say that the accepted changes should be routed into the lifecycle, and stop there. There is no backend to offer: issue #1030 archived every value above `inline`, and `../../references/operator-choice.md` §1 is the contract. Starting the work is still never automatic — it is the operator's pick. **No saga write.** `/founder-review` runs upstream of the work thread and does **not** touch the saga — no `saga.py` invocation, no `--review-paths`. Persistence is the `docs/founder-reviews/` artifact + the journal ADR. **Hard boundary.** `/founder-review` challenges, captures, and routes. It does **NOT** implement, does **NOT** record strategy (`/strategy` does), does **NOT** file SDLC issues (`mission-control` does), does **NOT** commit, push, or open PRs, and does **NOT** make code changes. Challenge the scope, write the scope-decision artifact, route — then stop. --- ## Reference files - `references/ceo-cognition.md` — the 18 CEO cognitive patterns (internalized, not a checklist) + the 9 Prime Directives + Engineering Preferences + the founder posture (incl. the sharpened no-false-precision steal). "How a founder thinks." - `references/review-modes.md` — the 4 modes (definitions + context-defaults + commit-no-drift) + expansion-framing (FLAT vs EXPANSIVE) + the opt-in/cherry-pick ceremonies (capped + the channel digest) + the adapted pre-review system audit + the Step-0 sub-steps with the **target-conditional** 0C-bis/0E gating + the office-hours escape + the scope-decision artifact format. "How the review runs."