@xulthekl/team-flow 0.22.4

package/skills/ce-brainstorm/references/blindspot-pass.md

@@ -0,0 +1,70 @@
+# Blindspot Pass
+
+The interview machinery in this skill assumes the user can evaluate what it asks. On territory the user doesn't know, that assumption fails: questions extract guesses, not requirements. The blindspot pass converts the user's unknown unknowns into known unknowns — it maps the decision surface of the flagged territory so the user chooses among options they can now evaluate, instead of generating answers from nothing.
+
+A blindspot pass is a decision map, not a tutorial. Test for every item: it must end in something the user will decide, delegate, or explicitly defer during this brainstorm. An item that feeds no decision is domain trivia — cut it.
+
+## Trigger
+
+Two signals arm the pass:
+
+- **Opening signal** — the user explicitly flags missing working knowledge of the domain or the territory the topic touches: "I know nothing about X", "never touched the auth modules", "I don't know what's possible here", "I don't know what I should be asking".
+- **Mid-dialogue signal** — two consecutive answers show the user *cannot evaluate* the question's substance: "I don't know", "whatever you think", "you decide" in response to questions that need domain judgment.
+
+**Can't-evaluate vs. hasn't-decided — the guard against over-firing.** A user who understands the options but hasn't picked one needs the normal interview, not a teaching pass. Offer only when the signal shows the user cannot weigh the options at all. Offering a blindspot pass to a domain expert who is merely undecided is the failure mode; when the signal is ambiguous, keep interviewing.
+
+## The gate
+
+The gate is **territory-scoped, not conversation-wide**. Questions about the user's own problem, users, evidence, and priorities proceed normally — the user is the authority on those. The gate fires only before the first substantive question *into the flagged territory* (the domain or system area the user cannot evaluate).
+
+Never silently switch into teaching. The offer is a blocking question (Interaction Rule 4), asked once per flagged territory. If the user declines, do not re-offer for that territory — fill gaps with recommended defaults recorded as explicit assumptions, per the normal rigor-probe discipline.
+
+**Non-interactive degradation:** in a pipeline or headless run where no user can answer, never fire the offer — treat flagged territory exactly like a declined offer (recommended defaults recorded as explicit assumptions) and continue.
+
+## Offer
+
+Use this wording, substituting the territory:
+
+> Part of this sits in territory you've flagged as unfamiliar (<territory>). I can map the decision surface first — the decisions you'll face there, the realistic options for each, and what I'd default to — so you're choosing rather than guessing. Or we keep going with questions and I fill gaps with defaults recorded as assumptions. Which do you prefer?
+
+Two options: **Map the territory first** / **Proceed with questions** (defaults become assumptions).
+
+## Building the map
+
+Ground it before writing it:
+
+- **In-repo territory** (a module, subsystem, or pattern in this codebase): use the Phase 1.1 grounding — the scout's dossier and targeted reads. If the scout has not returned yet, wait for it or read the relevant area directly; do not map in-repo territory from model knowledge alone.
+- **External domain** (a technology, practice, or field outside the repo): research with whatever web tools are reachable. When none are, model knowledge is allowed, but label each such item **Unverified — from model knowledge, not checked against current sources**.
+
+**The territory closes questions the user should never be asked.** Before an item goes on the map, check whether the codebase or sources already answer it — if so, it is not a decision: show the question and the found answer with its citation as settled ground, not as an option menu. The map holds only what genuinely needs the user's judgment. But a question closed off-screen isn't closed — territory-answered items are shown, never silently resolved.
+
+While grounding, hunt hazards specifically: things that bite silently (wrong-by-default data, filters that pass bad rows, escaping that corrupts output), unwritten conventions the code enforces that no doc states, and half-built or reverted prior attempts at the same job — the reason a prior attempt died is usually the landmine.
+
+The map is **3-7 items**, delivered in chat. Each item is a **decision** the user will face or a **hazard** that constrains one, in at most 4 lines — an item that runs longer has started teaching instead of framing the decision; cut it back:
+
+- what the decision or hazard is, in the user's vocabulary — when a term of art is unavoidable, define it and name what knowing it unlocks the user to decide
+- why it matters *for this topic* — tie it to something the user said, not to the domain in general; a hazard states what it changes about the task
+- decisions only: the realistic options (2-4), one clause each on the trade-off that matters here — list only options you would defend if the user picked them; a menu padded with options the map itself rules out is a strawman, not a choice. An option you ruled out belongs in why-it-matters as one clause ("subdomain isolation is closed — single-domain config"), never in the menu
+- decisions only: the recommended default, stated plainly
+
+A hazard is not a vote — it gets no option menu and no default. When a hazard forces a choice among genuinely viable mitigations, that choice is its own decision item and the hazard is its why-it-matters.
+
+The highest-stakes item earns first placement, not extra length — depth belongs in the walk-through after the user selects it, not in the map.
+
+Order items by how much the user's answer would change the product shape — architecture-changing decisions first, hazards and reversible choices last. Do not pad to 7; a territory with three real decisions gets three items.
+
+## Re-entering the dialogue
+
+After the map, ask **one** multi-select blocking question (a legitimate Rule 3 compatible set): *"Which of these do you want to walk through now? Anything unselected takes the recommended default, recorded as an explicit assumption."*
+
+Then:
+
+- **Selected decisions** — walk through one per turn as informed single-select menus. Post-pass, menus over mapped options are the right form even where Rule 5 would normally prefer open-ended: the options no longer steer, they recall what was just taught.
+- **Unselected decisions and hazards** — record the recommended default (or the hazard's constraint) as an explicit assumption, the same way rigor-probe uncertainty is recorded: in the Product Contract on the software route, in the synthesis on the universal route.
+- **"I want to actually learn this one"** — offer a handoff to the `ce-explain` skill for that item (offer, don't auto-fire); the brainstorm resumes when they return or continues with the default meanwhile.
+
+The pass never resolves decisions by itself and never replaces the dialogue. It runs once, converts blindspots into questions the user can answer, and the normal flow — rigor probes, approaches, synthesis — continues on informed ground.
+
+## Universal route
+
+The pass applies unchanged on the non-software route (an unfamiliar craft, market, or process — "I need to grade this video but don't know what color grading is"). Grounding is web research or labeled model knowledge; delegated defaults land as named assumptions in the wrap-up synthesis instead of a Product Contract.

package/skills/ce-brainstorm/references/brainstorm-sections.md

@@ -0,0 +1,285 @@
+# Brainstorm Sections
+
+This reference describes what makes a great PRD document (产品需求文档)
+produced by `ce-brainstorm`.
+It does NOT prescribe how the doc looks on the page — rendering is handled by
+the format-specific references (`markdown-rendering.md`, `html-rendering.md`).
+
+## The outcome
+
+A great brainstorm produces the PRD document (业务要件) that defines **WHAT** to build.
+`ce-plan` then reads the PRD and produces an **independent implementation plan** (实施方案) that defines **HOW** to build it.
+The PRD and plan are separate documents in the same `prd/vN/` directory.
+
+The PRD enables three audiences to act:
+
+- **The planning agent** (`ce-plan` or a human) produces an implementation
+  plan based on the PRD, without inventing user behavior, scope boundaries, or success
+  criteria — the brainstorm answered those.
+- **The reviewer** sees the framing choices, distinguishes pinned from open,
+  and catches scope gaps before planning.
+- **The future reader** traces why the proposed thing matters, who it's for,
+  and what success looks like.
+
+Sections earn their place by serving one of these audiences. Omit padding.
+
+## PRD skeleton contract
+
+New `ce-brainstorm` outputs follow the PRD artifact contract:
+
+- **Path:** `prd/vN/prd.md` (N is the iteration version number, e.g., v1, v2).
+- **Metadata:** `project_name`, `iteration_version`, `prd_template` (template path).
+- **Template source:** read `prd.template` from project configuration, or use
+  the default `templates/prd.md`.
+- **Structure:** the PRD contains 11 chapters as defined by the PRD template:
+  1. 版本修订记录
+  2. 业务流程一览
+  3. D7.1_业务流程
+  4. D7.2_画面原型及设计
+  5. D7.3_报表清单
+  6. D7.4_业务术语字典
+  7. D7.5_系统功能清单
+  8. D7.6_系统功能处理说明书
+  9. D7.7_要件定义自查报告
+  10. D7.8_要件定义完成报告
+  11. D7.9_评审会议纪
+
+- **Filling rule:** the brainstorm phase fills chapters where information is
+  available from the dialogue; chapters without dialogue content retain
+  template placeholders. Do not fabricate content for empty chapters —
+  they belong to later BA processes or will be addressed by `ce-plan` in its
+  implementation plan.
+
+A brainstorm-produced PRD is kept **light and standalone-readable**. It
+includes only chapters that carry real information from the brainstorm
+dialogue, leaving the rest as template placeholders. Empty chapters serve
+as a reminder of what still needs to be defined.
+
+Historical `docs/brainstorms/*-requirements.*` files remain valid legacy
+inputs. Do not migrate or rewrite them when creating new artifacts.
+
+## Decide whether a doc is warranted at all
+
+Brainstorm dialogue does not always need to produce a PRD document.
+Skip document creation when **both** hold:
+
+- The user only needs brief alignment — no exploration produced novel scope,
+  framing, or decisions worth preserving in IDed shape.
+- Any durable decisions made during the dialogue can flow naturally to
+  downstream artifacts (`ce-plan`, the commit message, `docs/solutions/`)
+  without a PRD document as an intermediary.
+
+The trigger for creating a doc is when the dialogue surfaced enough
+structural decisions, scope boundaries, or acceptance criteria that
+downstream consumers (planner, reviewer, future reader) need them in a
+durable, IDed form — not just as conversational artifacts.
+
+**Stress test:** a brainstorm about a tiny bug fix where the user asks "fix
+this with a null check or with upstream validation?" and the agent confirms
+"upstream validation, here's why" doesn't need a PRD document. The
+decision flows to `ce-plan` (or directly to commit message, or to
+`docs/solutions/` if it's a pattern worth carrying) without a PRD
+artifact in the middle.
+
+Conversely, a brainstorm about a multi-actor feature with contested scope
+and several behavioral conditions probably does need a doc — the planning
+agent needs the structured content the dialogue produced.
+
+## Match depth to content
+
+When a PRD IS warranted, depth matches what the dialogue produced. A
+brainstorm with sparse content produces a sparse doc; one with rich content
+produces a rich doc. Don't add ceremony to make a slim brainstorm look
+substantial.
+
+## Prose economy
+
+Match-depth-to-content sizes *which* sections appear and how deep each goes.
+This sizes *how the kept prose reads*. A section can be material and still be
+written loosely — the failure mode is a material section padded into a wall of
+text where contradictions hide and a downstream agent loses the thread. Length
+that earns its place is fine; wordiness around that length is not.
+
+Hold every kept section to these:
+
+- **Lead with the decision or outcome.** Put the conclusion first, then the
+  reason, then background; keep one claim plus its support per paragraph. Don't
+  bury the chosen scope, an open blocker, or a Key Decision beneath its
+  rationale.
+- **One idea per sentence.** A requirement is a handful of sentences, not one
+  sentence with five semicolons and four parentheticals. If a sentence needs a
+  second parenthetical to stay true, split it.
+- **A requirement is one sentence of intent plus at most one qualifier.** When
+  a requirement would specify two outcomes ("either A or B, planning decides"),
+  state the intent and send the fork to Outstanding Questions — don't write both
+  arms in full inside the requirement.
+- **Cut hedges and intensifiers.** "Critically", "deliberately", "explicitly",
+  "genuinely", "actually", "simply" carry nothing a downstream agent acts on.
+- **Prefer the verb to the nominalization.** "Demote the grid", not "the
+  demotion of the grid is the deliberate change in this brief".
+- **Summary and motivation serve different purposes.** When both appear in a
+  chapter, the lead (summary or conclusion) is forward-looking — what is being
+  proposed or decided. The supporting context is backward-looking / situational —
+  why this proposal exists or why this decision was made. Don't restate the
+  proposal inside the motivation paragraph; the remedy lives in the conclusion.
+
+Precision is not padding: keep IDs, dates, actor names, domain terms,
+conditionals, and exact thresholds verbatim; when a concrete anchor is knowable
+from the work already done, use it instead of a vague abstraction. Economy
+targets the connective tissue around precision, never the precision itself.
+
+**Resolve in place; don't stratify.** When a later decision answers a parked
+question or supersedes earlier text, rewrite or remove the original entry —
+don't append a separate "resolutions" layer that leaves the superseded text
+standing, and don't keep superseded prose as strikethrough. Version control
+holds the history. Stacked question/resolution strata double the reading surface
+and hide which text is live.
+
+**Named test, run before the doc is declared written:** could a reader find a
+contradiction in each section in one pass? A sentence carrying more than one
+parenthetical, or a requirement specifying two outcomes, fails the test — split
+it or defer it.
+
+## PRD chapter contract
+
+When a PRD is warranted, the document follows the PRD template structure. The
+brainstorm dialogue fills chapters where information is available; chapters
+without dialogue content retain template placeholders.
+
+### Always filled (from dialogue or metadata)
+
+- **§1 版本修订记录** — auto-filled from metadata (date, user, iteration
+  version). §1.2 修订记录 carries the brainstorm date and a one-line summary
+  of what was brainstormed.
+- **§2 业务流程一览** — filled from brainstorm's Key Flows and Actors. Each
+  identified business process gets a row in the flow overview table.
+- **§7 D7.5_系统功能清单** — filled from brainstorm's Requirements. Each
+  requirement maps to a system function entry.
+
+### Conditionally filled (when dialogue covers the topic)
+
+- **§3 D7.1_业务流程** — filled when brainstorm produced multi-step Key Flows
+  with enough detail for process diagrams.
+- **§4 D7.2_画面原型及设计** — filled when brainstorm involves UI/visual
+  components. Prototype references go here.
+- **§6 D7.4_业务术语字典** — filled with domain terms defined during brainstorm
+  dialogue.
+- **§8 D7.6_系统功能处理说明书** — partially filled: §8.2 全局说明
+  (permissions, interactions, exceptions) from Key Decisions and constraints;
+  §8.4 功能模块 from Requirements. Hardware/network/performance sections
+  retain placeholders.
+
+### Always placeholder (belong to later processes)
+
+- **§5 D7.3_报表清单** — retains template placeholder. Report details are
+  defined during detailed design.
+- **§9 D7.7_要件定义自查报告** — retains template placeholder. Self-check
+  is a BA process artifact.
+- **§10 D7.8_要件定义完成报告** — retains template placeholder. Completion
+  report is a closing artifact.
+- **§11 D7.9_评审会议纪** — retains template placeholder. Review minutes
+  are recorded during review meetings.
+
+## PRD chapters: fill when material
+
+The agent decides per brainstorm which PRD chapters carry information from the
+dialogue. Filling a chapter with placeholder content is worse than leaving it
+as template placeholder.
+
+- **§2 业务流程一览** — fill when brainstorm identified business processes,
+  user journeys, or system interactions. Each distinct process gets a row. Skip
+  rows for processes not discussed.
+
+- **§3 D7.1_业务流程** — fill when brainstorm produced detailed multi-step
+  flows with enough granularity for process diagrams. Include the flow diagram
+  placeholder and step-by-step descriptions. Skip when flows are high-level
+  only.
+
+- **§4 D7.2_画面原型及设计** — fill when brainstorm involves UI changes.
+  Include module names, page names, and prototype references. Skip entirely
+  when the brainstorm is non-visual (backend, data, API only).
+
+- **§6 D7.4_业务术语字典** — fill with domain terms actively defined during
+  dialogue. Only include terms where the conversation pinned down a precise
+  meaning. Skip terms merely mentioned in passing.
+
+- **§7 D7.5_系统功能清单** — fill from brainstorm Requirements. Each R-ID
+  maps to a system function entry with the requirement's intent as the function
+  description.
+
+- **§8 D7.6_系统功能处理说明书** — partially fill §8.2 when dialogue covered
+  permissions, interactions, or exception handling. Fill §8.4 from Requirements.
+  Skip §8.3 (hardware/network) and §8.5 (non-functional) unless the brainstorm
+  explicitly covered these.
+
+## Agent agency
+
+The chapter catalog is a floor, not a ceiling. When the brainstorm's content
+doesn't fit any catalog chapter, introduce a new one — don't force the content
+into a chapter it doesn't belong in. Content drives chapter choices, not vice
+versa.
+
+The agent also picks per artifact:
+
+- How much depth each present chapter gets
+- Whether supplementary diagrams or visuals appear inline or as appendices
+- How to organize the function module details within §8.4
+
+## PRD metadata fields
+
+Every PRD produced by `ce-brainstorm` carries metadata in YAML frontmatter.
+
+### Required
+
+- **`title`** — PRD title in format `{项目名称}_D7_业务要件` (matching the H1).
+- **`project_name`** — the project or product name.
+- **`iteration_version`** — the iteration version (e.g., "v1", "v2"),
+  corresponding to the `prd/vN/` directory.
+- **`date`** — creation date in ISO 8601 (`YYYY-MM-DD`).
+- **`prd_template`** — relative path to the PRD template used (e.g.,
+  `templates/prd.md`).
+- **`prd_readiness`** — always `requirements-only` for new `ce-brainstorm`
+  outputs. `ce-plan` produces a separate `plan.md` document (not modifying the PRD).
+
+### No status field
+
+PRD artifacts have no `status` field. `prd_readiness` is document completeness,
+not execution progress.
+
+### Field-name stability
+
+Field names are stable across PRD revisions. Adding new fields is fine; renaming
+existing fields breaks downstream consumers.
+
+## ID and content rules
+
+- **Stable IDs.** PRD tables use the PRD template's numbering format
+  (e.g., `X.X.X.X_a1_f1`). R-IDs in brainstorm Requirements map to this
+  format when inserted into PRD tables.
+- **Plain prefix.** In brainstorm dialogue, use plain prefixes (`R1.`, `F1.`)
+  for readability. When rendering into PRD tables, convert to the template's
+  hierarchical numbering.
+- **Bold leader labels** inside Flows and Acceptance Examples
+  (`**Trigger:**`, `**Covers R4, R8.**`) provide structure without deeper
+  heading levels.
+- **Repo-relative paths.** Always. Never absolute paths.
+- **No process exhaust.** No "captured at Phase X" notes, no `## Next Steps`
+  pointing to ce-plan, no italic provenance lines. Engineering process
+  metadata belongs in commit messages and tool output, not the artifact.
+- **No implementation details by default.** Libraries, schemas, endpoints,
+  file layouts, code structure stay out unless the brainstorm itself is
+  inherently about a technical or architectural change and those details are
+  the subject of the decision.
+
+## Rendering
+
+The format-specific references describe how to render these chapters in each
+output format:
+
+- **Markdown rendering:** `references/markdown-rendering.md`
+- **HTML rendering:** `references/html-rendering.md`
+
+This reference (`brainstorm-sections.md`) is about WHAT the PRD contains;
+rendering references are about HOW each format presents it. The PRD is
+written in one format — markdown OR HTML, never both — based on the
+resolved output mode. The chapter catalog is the same regardless of format.

package/skills/ce-brainstorm/references/handoff.md

@@ -0,0 +1,168 @@
+# Handoff
+
+This content is loaded when Phase 4 begins — after the PRD document is
+written.
+
+---
+
+#### 4.1 Present Next-Step Options
+
+The Phase 4 menu's visible option count varies by state: no PRD document
+hides the review and Proof options, `OUTPUT_FORMAT=html` also hides
+the review option (ce-doc-review is markdown-only today), unresolved `Resolve
+Before Planning` hides both `Create the implementation plan` and `Ship it
+autonomously with lfg`, and the lfg option is also hidden for non-software
+brainstorms (`execution` other than `code`). Count the visible options for the
+current state and choose the rendering mode accordingly:
+
+- **Visible count fits the current platform's option cap:** use the platform's blocking question tool (`AskUserQuestion` in Claude Code — call `ToolSearch` with `select:AskUserQuestion` first if its schema isn't loaded; `request_user_input` in Codex; `ask_question` in Antigravity CLI (`agy`), `ask_user` in Pi (requires the `pi-ask-user` extension)). Claude Code `AskUserQuestion` supports up to 4 explicit options, and Codex `request_user_input` supports only 2-3 explicit options.
+- **Visible count exceeds the current platform's option cap:** render as a numbered list in chat. This is the narrow option-overflow fallback; trimming would hide legitimate choices (plan, ship, review, Proof/browser, refine are all distinct destinations). Include a hint that free-form input is accepted ("Pick a number or describe what you want.") so the numbered list retains the blocking tool's open-endedness.
+
+Never silently skip the question.
+
+If `Resolve Before Planning` contains any items:
+- Ask the blocking questions now, one at a time, by default
+- If the user explicitly wants to proceed anyway, first convert each remaining item into an explicit decision, assumption, or `Deferred to Planning` question
+- If the user chooses to pause instead, present the handoff as paused or blocked rather than complete
+- Do not offer the `Create the implementation plan` or `Ship it autonomously with lfg` options while `Resolve Before Planning` remains non-empty
+
+In both preambles below, the "Pick a number or describe what you want." hint applies only in numbered-list mode. When using the blocking tool, omit that line and pass the remaining stem as the question.
+
+**Path format:** Use absolute paths for chat-output file references — relative paths are not auto-linked as clickable in most terminals.
+
+**Preamble when no blocking questions remain:**
+
+```
+Brainstorm complete.
+
+PRD document: <absolute path to PRD document>  # omit line if no artifact was created
+
+What would you like to do next? (Pick a number or describe what you want.)
+```
+
+**Preamble when blocking questions remain and user wants to pause:**
+
+```
+Brainstorm paused. I'm holding planning until the remaining questions are resolved — say the word and I'll proceed anyway, recording each open item as an explicit assumption or a question deferred to planning.
+
+PRD document: <absolute path to PRD document>  # omit line if no artifact was created
+
+What would you like to do next? (Pick a number or describe what you want.)
+```
+
+The override sentence is load-bearing, not padding: the planning options are hidden while `Resolve Before Planning` is non-empty, so without it the user is told planning is blocked and is never told the block is theirs to lift. `Resolve Before Planning` is your own judgment call — an over-cautious read of it must not silently strand the user with no visible way forward. Hiding the option withholds the *recommendation*; it never withholds the *choice*.
+
+Present only the options that apply. Renumber so visible options stay contiguous starting at 1.
+
+1. **Create the implementation plan** *(recommended)* - Hand off to `ce-plan` and sharpen the PRD document into a complete, testable plan. Shown only when `Resolve Before Planning` is empty.
+2. **Ship it autonomously with `lfg`** - Hand the requirements to the full autonomous pipeline: `lfg` plans (`ce-plan`), implements, simplifies, runs independent code review and applies the fixes, opens a PR, and watches CI to green — hands-off, no check-ins. It plans first (unlike a raw `/goal` straight from requirements), so it's the safer autonomous path. Best when you trust the requirements and want it built and shipped without steering. **Opens a PR and pushes a branch.** Shown only for software brainstorms (`execution: code`) with `Resolve Before Planning` empty **and a PRD document was created** — `lfg` hands `ce-plan` the PRD path in pipeline mode and cannot prompt, so with no artifact (e.g. a brief-alignment brainstorm that skipped doc creation per the "Decide whether a doc is warranted" rule) there is nothing to enrich; offer option 1 instead, which can plan interactively from the conversation. For a quicker plan-then-decide flow, or to run a `/goal` yourself, pick option 1 and choose at the `ce-plan` handoff.
+3. **Pressure-test the requirements** - Dispatch reviewer agents with `ce-doc-review` to find gaps, conflicts, weak premises, and scope issues in the requirements; auto-apply safe fixes; route the rest interactively. Shown only when a markdown PRD document exists **and `OUTPUT_FORMAT=md`** — ce-doc-review's walkthrough applies markdown-only mutations (`##`/`###` heading inserts, single-file markdown edits via apply-set) and would corrupt an HTML artifact, so HTML brainstorms skip this option until ce-doc-review gains HTML-aware mutation support. Under HTML mode, surface a one-line note above the menu: `Requirements review unavailable in output:html mode — ce-doc-review is markdown-only today. Switch to output:md if you want a review pass.`
+4. **Publish to Proof — shareable link** - Publish the markdown PRD document to Every's Proof editor and get a shareable link to read, comment on, or share with others. One-way: the local doc stays canonical. Shown only when a markdown PRD document exists. **Render only when `OUTPUT_FORMAT=md`** (Proof operates on markdown and cannot ingest HTML).
+4. **Open in browser** — open the HTML PRD document locally for review and sharing. Shown only when an HTML PRD document exists. **Render only when `OUTPUT_FORMAT=html`.** Replaces "Publish to Proof" at the same slot under exclusive output mode — the artifact is either markdown OR HTML, never both, so exactly one of the two labels applies per run.
+5. **More clarifying questions to sharpen the scope** - Keep refining scope, edge cases, constraints, and preferences through further dialogue. Always shown — so the label names the scope rather than the doc, which stays true on a run that correctly skipped doc creation.
+
+There is no "done" / "pause" option — the blocking question already waits, and the user ends by dismissing it (Esc) or saying they're finished. The PRD document is already saved.
+
+**Post-review nudge (subsequent rounds only):** If the user has already run `ce-doc-review` this session and residual P0/P1 findings remain unaddressed, add a one-line prose nudge adjacent to the menu (e.g., "Document review flagged 2 P1 findings you may want to address — pick \"Pressure-test the requirements\" to run another pass."). Reference the option by label, not number: the menu renumbers when `Resolve Before Planning` hides `Create the implementation plan` and the lfg option, so a hardcoded option number can point users at the wrong action. Do not add a separate menu option; reuse the existing `Pressure-test the requirements` option. Suppress this nudge when `OUTPUT_FORMAT=html` — that option is hidden in that mode, so the nudge would point users at a missing action.
+
+#### 4.2 Handle the Selected Option
+
+Selections may be the literal option label (when the user types the label or a close paraphrase) or the option number. Match numbers against the currently-rendered (post-trim) list. Free-form input that doesn't match an option or describe an alternative action should be treated as clarification — ask a follow-up rather than guessing.
+
+**If user selects "Create the implementation plan":**
+
+Immediately load the `ce-plan` skill in the current session. Pass the PRD
+document path when one exists; otherwise pass a concise summary of the
+finalized brainstorm decisions. When the Phase 1.1 grounding scout produced a
+dossier and the file still exists, also pass its path
+(`<scratch-root>/ce-brainstorm/<run-id>/grounding.md`) — it gives
+planning verified quotes with `file:line` pointers to start from instead of
+re-scanning the repo. Do not print the closing summary first.
+
+**If user selects "Pressure-test the requirements":**
+
+Load the `ce-doc-review` skill, passing the PRD document path as the argument.
+When ce-doc-review returns "Review complete", return to the Phase 4 options
+and re-render the menu (the requirements may have changed, so re-evaluate
+`Resolve Before Planning`, the lfg software gate, and residual findings). If
+residual P0/P1 findings remain unaddressed, include the post-review nudge
+above the menu. Do not show the closing summary yet.
+
+**If user selects "Ship it autonomously with `lfg`":**
+
+Immediately invoke the `lfg` skill in the current session via the platform's
+skill-invocation primitive, passing the PRD document path as its
+argument so `lfg`'s `ce-plan` step enriches the PRD to implementation-ready
+state rather than bootstrapping a new plan. `lfg` then owns the full pipeline
+autonomously — plan, implement (`ce-work` in `return-to-caller` mode), simplify,
+independent code review and applied fixes, commit/push/open PR, and CI watch to
+green. Do not also start a `/goal` or load `ce-work` directly — `lfg`
+orchestrates them. Unlike a goal tool, `lfg` is host-agnostic: it works wherever
+skills run (plus `git`/`gh` for the PR/CI tail, which it guards when absent).
+
+Where the host exposes no skill-invocation primitive, print the `lfg <plan-path>`
+invocation for the user to run and note that it will plan, build, review, and
+open a PR from this artifact.
+
+Do not print the closing summary first.
+
+**If user selects "More clarifying questions to sharpen the scope":** Return to Phase 1.3 (Collaborative Dialogue) and continue asking the user clarifying questions one at a time to further refine scope, edge cases, constraints, and preferences. Continue until the user is satisfied, then return to Phase 4. Do not show the closing summary yet.
+
+**If user selects "Publish to Proof — shareable link":**
+
+Load the `ce-proof` skill to publish the markdown PRD document. Pass:
+
+- **source file:** `prd/vN/prd.md`
+- **doc title:** `PRD: <topic title>`
+- **identity:** `ai:compound-engineering` / `Compound Engineering`
+
+ce-proof creates a shared Proof doc from the markdown PRD file (Create and
+Share workflow), binds the display name, and returns the share URL. Surface
+the URL to the user — they can open it to read, comment, or share with others
+— then return to the Phase 4 options and re-render the menu. This is a one-way
+publish: the local doc stays canonical and nothing syncs back, so option
+eligibility is unchanged (no need to re-evaluate `Resolve Before Planning`,
+the lfg software gate, or residual findings on account of Proof).
+
+If the upload fails (network error, Proof API down), retry once after a short wait. If it still fails, tell the user the upload didn't succeed and briefly explain why, then return to the Phase 4 options — don't leave them wondering why the option did nothing.
+
+**If user selects "Open in browser":** Display the absolute path to the `.html` PRD document so the user can open it locally. Where the platform exposes a browser-opening primitive (e.g., `open` on macOS, `xdg-open` on Linux, `start` on Windows), the agent may invoke it directly; otherwise print the absolute path and let the user open it. After the path is displayed (or the browser is opened), return to the Phase 4 options so the user can pick a follow-up action.
+
+**If the user indicates they're finished** (says "done"/"that's all", or dismisses the menu without picking an option): display the closing summary (see 4.3) and end the turn.
+
+#### 4.3 Closing Summary
+
+Use the closing summary only when this run of the workflow is ending or handing off, not when returning to the Phase 4 options.
+
+In both templates below, substitute `<absolute path to PRD document>` with the
+actual file path written this run — `.md` for `OUTPUT_FORMAT=md`, `.html` for
+`OUTPUT_FORMAT=html`. Do not emit a hardcoded `.md` path when the artifact is
+HTML, or the closing summary will point users at a file that was never written.
+
+When complete and ready for planning, display:
+
+```text
+Brainstorm complete!
+
+PRD document: <absolute path to PRD document>  # omit line if no artifact was created
+
+Key decisions:
+- [Decision 1]
+- [Decision 2]
+
+Recommended next step: `ce-plan <PRD document path>`
+```
+
+If the user pauses with `Resolve Before Planning` still populated, display:
+
+```text
+Brainstorm paused.
+
+PRD document: <absolute path to PRD document>  # omit line if no artifact was created
+
+Planning is held on:
+- [Blocking question 1]
+- [Blocking question 2]
+
+Resume with `ce-brainstorm` to resolve these — or say to plan anyway, and I'll record each open item as an explicit assumption or a question deferred to planning.
+```