skills/ce-brainstorm/references/interaction-rules.md

# Core Principles, Interaction Rules, and Output Guidance

Read this before the first question of any brainstorm, including the non-software route.

## Core Principles

1. **Assess scope first** - Match the amount of ceremony to the size and ambiguity of the work.
2. **Be a thinking partner** - Suggest alternatives, challenge assumptions, and explore what-ifs instead of only extracting requirements.
3. **Resolve product decisions here** - User-facing behavior, scope boundaries, and success criteria belong in this workflow. Detailed implementation belongs in planning.
4. **Keep implementation out of the Product Contract by default** - Do not include libraries, schemas, endpoints, file layouts, or code-level design unless the brainstorm itself is inherently about a technical or architectural change.
5. **Right-size the artifact** - Simple work gets a compact requirements-only unified plan or brief alignment. Larger work gets a fuller Product Contract. Do not add ceremony that does not help planning.
6. **Apply YAGNI to carrying cost, not coding effort** - Prefer the simplest approach that delivers meaningful value. Avoid speculative complexity and hypothetical future-proofing, but low-cost polish or delight is worth including when its ongoing cost is small and easy to maintain.
7. **Do not turn coverage into decomposition** - For software brainstorms, treat named devices, providers, and data sources as coverage requirements, not automatically as separate integration workstreams. Split them only when a shared access path cannot satisfy a named requirement. Leave connector selection to planning unless that choice materially changes product scope or behavior.
8. **Keep one coherent work unit per artifact** - When a request contains independently valuable outcomes that can be planned and delivered separately, choose one as the current focus before deep exploration. Preserve how the surrounding work is currently understood without turning tentative future areas into requirements for this plan.

## Interaction Rules

These rules apply to every brainstorm, including the universal (non-software) flow routed to `references/universal-brainstorming.md`.

1. **Ask one question at a time** - One question per turn, even when sub-questions feel related. Stacking several questions in a single message produces diluted answers; pick the single most useful one and ask it.
2. **Prefer single-select multiple choice** - Use single-select when choosing one direction, one priority, or one next step.
3. **Use multi-select rarely and intentionally** - Use it only for compatible sets such as goals, constraints, non-goals, or success criteria that can all coexist. If prioritization matters, follow up by asking which selected item is primary.
4. **Default to the host's blocking question tool** — use the host's blocking question tool already in the current tool list (match by capability, not by a host-specific name). Presence in the current tool list is proof the tool exists; never call a user-facing question tool to discover whether it exists. If a matching tool is listed but unloaded, use the host's tool-discovery primitive to load that capability — do not search for another host's tool name. These tools include a free-text fallback, so well-chosen options scaffold the answer without confining it. This default holds for opening and elicitation questions too, not only narrowing. Fall back to numbered options on the host's user-visible chat surface only when no such tool is in the list or a real question call errors. Never silently skip the question. **Exception — visual-probe gate:** if the next decision is a shape, behavior, or layout question that does not meet Rule 7, the visual-probe gate in `references/visual-probes.md` takes precedence.
5. **Use an open-ended question only when the question is genuinely open** - Drop the blocking tool when the answer is inherently narrative, when presented options would steer a diagnostic or introspective answer, or when you cannot write 3-4 genuinely distinct, plausibly-correct options without padding. The test: if you'd be straining to fill the option slots, the question is open — ask it open-ended. Rule 1 still applies: one question per turn.
6. **Open-ended questions earn their place only when they're specific enough to elicit a substantive answer** - Apply Rule 5 silently: just ask the question, never narrate the form choice. The question must give the user something concrete to anchor on. Good: *"What's the most concrete thing someone's already done about this — paid for it, built a workaround, quit a tool over it?"* — it names what counts as an answer. Too thin: *"What's your take?"* — nothing to bite into, and framings that imply a short answer ("briefly", yes/no) waste the open question the same way.
7. **Offer `ce-prototype` when the decision is expensive to unravel.** This skill states the routing test once, here; every other site in this skill cites it. The test: committing an approach would be expensive to unravel — later planning and implementation will treat it as given — **and** neither talk nor a cheap one-decision sketch can settle it. A purely visual decision qualifies on the same terms as a behavioral one: finish and motion are dimensions a rough sketch strips by definition, so a question turning on them is already past the sketch tier. Unravel cost is a precondition, not decoration — a decision that is cheap to reverse does not escalate, however visual it is. Offer once — when you recognize that bar, not at a fixed phase. Do not offer for routine UI that follows an existing pattern (adding a known button, placing a standard control), and do not offer for a visual choice that follows an existing token, type scale, or component-library pattern. On accept, invoke `ce-prototype` via the host's normal skill-invocation mechanism, passing the named question, the surface, any hard constraints, and any artifact path; do not build it here. On decline, continue here; do not re-offer unless the decision itself changes.
8. **Ask only for user decisions** — Look up answers available in the repository, existing research, or other reachable sources. A lookup in progress does not delay unrelated questions. The user decides unresolved product direction, preferences, and scope. Choose technical details from project evidence within the request instead of asking the user to choose them.

## Output Guidance

- **Prioritize decision-relevant detail** - Preserve the facts, tradeoffs, and caveats needed for the next decision; trim introductions, repetition, and optional background first.