compound-engineering-plugin-mirror/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. Polish or delight the user did not ask for is an option to offer, not a default.
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.

9. Recommend what the user's goal needs, and nothing it does not. Offering ideas the user did not ask for is part of being a thinking partner; what you recommend is what gets built when the user says "your call." Recommend adding scope, a safeguard, or a process the user did not name only when the goal behind the request is not actually met without it (what they are trying to achieve, not only the words they used), or when leaving it out lets harm land before anyone would catch it. An idea that would be expensive or hard to add later (stored data, a shared interface, money, security) but that neither of those requires is worth putting to the user as an explicit choice, without recommending it. Offer any other idea as a non-default option, or list it with the synthesis's deferred items instead of spending a question on it. A recommendation never narrows something the user asked for. This rule governs what you recommend and commit, not what you ask: questions that help the user understand their problem, including whether a related area should be part of this work, are still the job.

Output Guidance

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