Scope gates (Phase 0.2-0.6)

Required read at the start of Phase 0, before any grounding dispatch. A gate here is a check the run must pass before anything is dispatched. This file defines the subject-identification check and its scope question, mode classification, the elsewhere-mode substance check, focus/volume interpretation with the tactical dials, and the cost-transparency line.

Asking (applies to every gate below)

Ask through the host's blocking question tool, with the fallback SKILL.md Boundary 4 states.

Ask one question at a time. Prefer concise single-select choices when natural options exist.

0.2 Subject-Identification Gate

Before classifying mode or dispatching any grounding, check whether the subject of ideation is identifiable. Every downstream agent needs to know what it is working on; if reasonable sub-agents would diverge on what the topic even is (bare words like improvements, ideas, birthday cakes), the output will be scattered.

Questioning principles (apply in this phase and in 0.4):

• Questions exist only to supply what sub-agents need to operate: an identifiable subject (this phase) and enough context to say something specific about it (0.4, elsewhere modes only). Nothing else.
• Never ask about solution direction, constraints, audience, tone, or success criteria — those belong to ce-brainstorm.
• Always keep "Surprise me" as a real option, not a fallback for a user who cannot name a subject. Ideation is allowed to be greenfield by design.
• Stop as soon as the subject is identifiable or the user has delegated to "Surprise me." More than 3 questions total across 0.2, 0.3, 0.4, and the Phase 1 issue-scoping question is a smell that ideation is not the right workflow — consider suggesting ce-brainstorm.

Detection — issue-tracker intent (repo mode only; subject-identifying). Issue-tracker intent means the user asks about the reports already filed — the open issues, the themes across them, what users are reporting — as a body of material, whether or not a tracker is named. A bug named as the thing to improve is a focus hint on regular ideation, not this intent. bug reports about checkout is issue-tracker intent; fix the login issue is a focus hint. A bare bugs names neither and is a vague subject, handled by the identifiability check below. With intent detected, the subject is "issues in the tracker", against whichever tracker is reachable (GitHub, Linear, Jira, or another); do not require GitHub. Proceed to 0.3 with issue-tracker intent flagged.

When combined (e.g., top 3 issue themes in authentication, biggest bug reports about checkout): detect issue-tracker intent first, volume override in 0.5, remainder is the focus hint. The focus narrows which issues matter; the volume override controls survivor count.

Detection — subject identifiability.

The test: would a reader, seeing only this prompt, know what subject the agent should ideate on? Vagueness is about what the words refer to, not phrase length: browser sniff is two words but plausibly names a feature (identifiable — proceed to 0.3); quick wins is two words but names only a quality (vague — ask the scope question). A prompt that refers to a catch-all quality, category, or placeholder (improvements, bugs alone, an empty prompt) is vague; one that names or plausibly names a specific feature, concept, document, flow, or topic is identifiable, in any domain. Being inside a repo does not settle this — improvements in any repo is still scattered across DX, reliability, features, docs, tests, and architecture, and the repo supplies grounding material after a subject is settled, not the subject itself.

Genuine ambiguity (repo mode). When real doubt remains on a short phrase, one cheap check settles it: search filenames for the phrase with the host's file-search tool, or search README/docs for it with its content-search tool. Any repo footprint → identifiable; none and still vague → ask. Otherwise err toward asking — one question is trivial compared to dispatching a dozen agents on a scattered interpretation.

The scope question.

Ask via the platform's blocking question tool per the Asking section above — never silently skip.

• Stem: "What should the agent ideate about?"
• Options:
• "Specify a subject the agent should ideate on"
• "Surprise me — let the agent decide what to focus on"
• "Cancel — let me rephrase"

Routing:

• Specify → accept the user's follow-up as the subject. Re-apply the identifiability check once. If still ambiguous, ask once more with "Surprise me" still on the menu. Do not cascade toward specificity about how to solve — only about what the subject is.
• Surprise me → mark the run as surprise-me mode and apply the table below at every phase it names.
• Cancel → exit cleanly. Narrate that the user can rephrase and re-invoke.

Surprise-me mode — every delta, in one place. The agent discovers subjects from Phase 1 material instead of carrying a user-specified one. This is a first-class mode, not a fallback for a user who cannot name a subject. Each downstream phase repeats a one-clause hook pointing here; this table is what those hooks mean.

The user can correct at any point by interrupting and re-invoking with a named subject.

0.3 Mode Classification

Do not resolve or create the artifact root before mode is classified — an elsewhere or no-repo run never needs it.

Classify the subject of ideation (settled in 0.2) into one of three modes for dispatch routing. A user inside any repo can ideate about something unrelated to that repo; a user in /tmp can ideate about code they hold in their head.

Surprise-me short-circuit. In surprise-me mode, skip the two decisions below and the ambiguity-confirmation step; apply the 0.2 table's 0.3 mode row. State the chosen mode in one sentence and proceed to 0.4.

For specified subjects, make two sequential binary decisions:

Decision 1 — repo-grounded vs elsewhere. Weigh prompt content first, topic-repo coherence second, and CWD repo presence as supporting evidence only. Repo-grounded when the prompt references repo files, code, architecture, modules, tests, or workflows, or the topic is bounded by the current codebase; issue-tracker intent from 0.2 is always repo-grounded. Elsewhere when the prompt names things absent from the repo — pricing, naming, narrative, business model, personal decisions, brand, content, market positioning — or the topic is creative, business, or personal and involves no code.

Decision 2 (applies only when Decision 1 = elsewhere) — software vs non-software. Classify by whether the subject is a software artifact or system, not by where the ideas will land. A product, app, SaaS, web/mobile UI, feature, page, or service is elsewhere-software — even when the ideas themselves are about copy, UX, CRO, pricing, onboarding, visual design, or positioning for that product. Elsewhere-non-software is reserved for topics that are not about any software artifact: company or brand naming (independent of product), narrative and creative writing, personal decisions, non-digital business strategy, physical-product design.

Contrast pair: "Improve conversion on our sign-up page" → elsewhere-software (the subject is a page, even though the ideas may be copy or CRO); "Name my new coffee shop" → elsewhere-non-software (the subject is a brand, not a software artifact).

State the inferred approach in one sentence, in plain language, adapting a domain word from the topic itself ("landing page", "onboarding flow", "naming", "career decision"). Never print the internal taxonomy label (repo-grounded, elsewhere-software, elsewhere-non-software) — those are for routing only.

• Repo-grounded: "Treating this as a topic in this codebase — about X."
• Elsewhere-software: "Treating this as a product/software topic outside this repo — about X."
• Elsewhere-non-software: "Treating this as a [naming | narrative | business | personal] topic — about X."

Do not prescribe correction phrases ("say X to switch"). State the mode and proceed; if the user disagrees they will correct in their own words, and you reclassify and re-run any affected routing.

Active confirmation on mode ambiguity. Most subjects settled in 0.2 classify cleanly — ask only when the mode is genuinely ambiguous afterward (e.g., "our docs" could be repo docs or public marketing docs). Then ask one blocking question whose two labels name the candidate interpretations in plain language ("Treat as repo docs in this codebase" vs "Treat as public marketing docs") — never leaking internal mode names.

Routing rule (non-software mode). When Decision 2 = non-software: run Phase 1 elsewhere-mode grounding (user-context synthesis + web research; skip phrases honored, learnings skipped by default), never the repo codebase scan. Then read references/universal-ideation.md and follow it in place of Phase 2's frame dispatch and the Phase 5 menu — the domain-agnostic frames, critique rubric, and wrap-up menu for this mode live only there. The deliverable is still auto-written per references/post-ideation-workflow.md Phase 4.

0.4 Context-Substance Gate (Elsewhere Modes Only)

Skip in repo mode — the repo provides the substance Phase 1 agents work from. In elsewhere modes (both software and non-software), Phase 1 agents depend on user-supplied context for substance. A bare prompt with no description, URL, or artifact leaves the user-context-synthesis agent with nothing to synthesize and weakens web research's relevance.

Apply the discrimination test: would swapping one piece of the user's stated context for a contrasting alternative materially change which ideas survive? If yes, the context is specific enough to shape the ideas — proceed. If no, ask 1-3 narrowly chosen questions focused on supplying substance, not characterizing the subject:

• A URL or file to read
• A brief description of the current state
• A paste of an existing draft or brief

Build on what the user already provided rather than starting from a template. Default to free-form questions; use single-select only when the answer space is small and discrete. After each answer, re-apply the test before asking another. Stop on dismissive responses ("idk just go") — treat genuine "no context" answers as real answers and note context is thin in the summary so Phase 2 can compensate with broader generation.

Surprise-me exception. In surprise-me mode routed to elsewhere-software, substance is required and a dismissive response is not an acceptable answer — apply the 0.2 table's 0.4 substance row.

When the user provides rich context up front (a paste, a brief, an existing draft, a URL), confirm understanding in one line and skip this step entirely.

If this step materially changes the topic (not just adds context but shifts the subject), re-run 0.2 and 0.3 against the refined scope before dispatching Phase 1 — classify on what's actually being ideated on, not the scope at first read.

0.5 Interpret Focus and Volume

Infer two things from the argument and any intake so far:

• Focus context — concept, path, constraint, or open-ended
• Volume override — any hint that changes candidate or survivor counts

Default volume: keep the top 5-7 survivors. Per-frame idea targets and the raw/dedupe counts they imply live in references/divergent-ideation.md — the dispatch spec defines them. Honor clear overrides such as top 3, 100 ideas, or raise the bar.

Two symmetric depth overrides scale the run. Both are opt-in from the user's own words; the default sits between them.

**go deep (or equivalent) — scale up.** Every ideation agent moves to the ceiling tier, the Phase 2 verification read budget doubles, and Phase 3 adds a second critic. Users opt into top-tier cost explicitly rather than inheriting it from whichever model the conversation happens to run on.

Tactical signals — scale down. Words like polish, typo, typos, quick wins, small improvements, cleanup, or small fixes in the focus hint (or a 0.2 intake answer) mean the user opted into tactical scope. Use reasonable interpretation rather than formal parsing.

Tactical's dials — the complete list. 3-4 ideas per frame; 2-3 verification reads per agent; at most 3 axes; the meeting-test floor waived at both layers. Everywhere below and in the references, "tactical's dials" means exactly this list.

• **The waiver reaches both the generators and the Phase 3 basis verifier's dispatch prompt.** The verifier runs on a fresh context with none of the generation history, so a waiver it is not told about does not reach it.
• Tactical changes nothing else — not the agent count, not the frame set, not the model tier — and it never skips basis verification. Packing frames into fewer agents is not a tactical lever: the verification budget is per agent, not per frame (references/divergent-ideation.md).

Resolve the overrides before anything keys on them. go deep cancels tactical: a prompt carrying both runs as a go deep run, with no tactical dial and no waiver. Everything downstream — the fleet, the dials, and every waiver — keys on which overrides are active after this, never on a signal that was merely spotted. When another variant decides the frame set or the fleet (issue-tracker themes, surprise-me, or the universal path's depth), it keeps that decision, and an active tactical scope still contributes its dials.

0.6 Cost Transparency Notice

Before dispatching Phase 1, tell the user in one short line which grounding and ideation agents this run will dispatch, plus the skip phrases (e.g. 'no external research', 'no slack'), so multi-agent cost is not invisible. Derive the line from the dispatch decisions already made; do not carry a memorized total. Leave out the web researcher when the user issued a skip phrase — that much is readable from the prompt right now.

Say "conditional" for anything this phase cannot yet resolve; do not pre-subtract it. Where a number depends on a decision a later phase makes — web-research cache reuse, the issue cluster call only if that scan returns usable signal, a depth-dependent count — name the leg and say it is conditional. State a total only if you just derived it; reaching for the ordinary five-agent figure to fill a gap is the one answer certain to be wrong.

The line is informational; users do not need to acknowledge it.