brainstorming

name	brainstorming
description	Use this skill for top-level/PM planning gates that need design exploration and explicit direction confirmation before specs or code for MEDIUM/LARGE work. Use when a request is ambiguous, has multiple route-changing options, or needs direction lock-in. DO NOT USE FOR: direct specialist invocation, clear small isolated changes, or already-confirmed specs.

Brainstorming

Use this skill to freeze direction before planning, spec writing, or code.

This skill only serves the top-level or PM orchestration path. It exists to lock semantic ambiguity and design direction outside implementation, not to block routine small work or specialist execution.

Trigger

• Use when a MEDIUM/LARGE request in the top-level or PM planning gate still has route-changing ambiguity.
• Use when 2 or more viable routes change implementation path, API behavior, data model, module ownership, UX direction, security boundary, or delivery scope.
• Use when 3 or more candidate directions would materially change implementation and should be resolved through native structured selection.
• Use when the request contains hotspot ambiguity such as optimize, refactor, add feature, change this, or not allowed and the default interpretation is not yet locked.
• Use when a major new feature touches shared abstractions, external interfaces, or multi-module coordination and the direction is still open.

Do not use when:

• The task is small, isolated, and directionally clear.
• A complete spec already exists and the direction has already been confirmed upstream.
• The current flow is a direct specialist invocation rather than the top-level or PM planning gate.
• There is only one reasonable interpretation and it can be recorded safely.

Interview Mode

1. Ask one question at a time. Do not stack multiple branching questions in one turn.
2. Prefer 2-4 options. Each option should fit on one line and include the core trade-off.
3. Use this order for each question: re-ground the current task, simplify the decision point, then give a recommendation.
4. If a native ask UI exists, use it for route-changing decisions. In Claude Code this means an AskUserQuestion tool call with 2-4 choices and a custom free-form answer path, not a prose list. Follow the Native Ask Contract from core-workflow-contract for structured ask UI requirements. Do not ask the user to type plain A/B/C in free text when structured choice is available.
5. If 3 or more route-changing options exist, native structured selection is the default path. Do not first run a long prose comparison and defer the real choice to a later round.
6. After the user chooses, lock that direction and move forward. Do not ask a duplicate confirmation round for the same decision.
7. Follow the Native Ask Contract from core-workflow-contract. Never end the turn with a prose-only blocking question.

Confirmation Semantics

• user_confirmed means the user explicitly chooses an option, explicitly says to proceed with a direction, or confirms through native structured selection.
• Weak replies such as "take a look", "draft it first", or "maybe like this" are not enough to unlock spec writing or implementation.
• Planning text, example commands, pasted references, or quoted material are data-only context. They do not count as execution approval or direction lock-in.
• Plain prose questions, "reply A/B/C" prompts, and summary-plus-question endings do not count as confirmation.
• If native confirmation UI is unavailable, only three outcomes are allowed:
  • Continue with a clearly documented single_reasonable_interpretation.
  • Return a tightly scoped candidate set for PM-controlled agent_vote_fallback.
  • Stop and wait for native confirmation to become available again.

agent_vote_fallback Boundary

• Only use it from the top-level or PM planning gate, after brainstorming has produced a real candidate set, and only when native confirmation UI is unavailable.
• Keep the candidate set at 3 options or fewer and within the same business boundary.
• Use it only for engineering route selection, implementation shape, or default delivery posture.
• Never use it for business semantics, user-visible behavior, destructive actions, credentials, production side effects, public APIs, database schema, security boundaries, or message contracts.
• If any reviewer or voter returns human_required, BLOCKED, or equivalent high-risk feedback, stop and wait for human confirmation.

Steps

1. Parse the literal request, real intent, and success criteria.
2. Identify only decisions that change implementation path, API behavior, data model, module ownership, security boundary, UX direction, or delivery scope.
3. For each real decision point, generate 2-4 candidate directions with a one-line trade-off.
4. If there is one reasonable interpretation, record it and continue.
5. If there are multiple viable routes, use Interview Mode to lock the highest-impact ambiguity first.
6. Before handing off to spec or implementation, run an ambiguity scan:
   • hotspot wording has been resolved
   • route-changing decisions are locked
   • non-goals are aligned
   • blast radius is understood for public API, schema, message, permission, or security changes
   • major architectural choices are explicit enough to justify an ADR in spec when needed
7. After resolution, produce a Design Direction Summary:

## Design Direction Summary
- chosen_directions:
- decision_provenance: user_confirmed|single_reasonable_interpretation|agent_vote_fallback
- non_goals:
- constraints:
- blast_radius:
- ADRs_needed:
- open_questions:

• If the skill is about to end the turn after presenting direction, options, or a summary, use native structured ask/confirmation UI when available. Do not end on a prose-only summary.

Independent Review Loop

Before writing spec for a MEDIUM/LARGE task, hand the Design Direction Summary to a fresh reviewer when tooling and context allow it.

• The reviewer should assess completeness, consistency, clarity, scope discipline, and YAGNI.
• The reviewer should not rely on the original brainstorming transcript; the summary must stand on its own.
• If the reviewer finds material gaps, repair the summary and re-check once.
• After 2 review rounds with unresolved high-impact ambiguity, stop and return for user clarification instead of forcing spec progress.

Stop-Loss

• Keep MEDIUM/LARGE brainstorming to 5 rounds or fewer.
• Keep the number of real route-locking questions to 4 or fewer; prioritize the top 2-3 that most affect boundaries.
• If repeated assumptions are invalidated and the direction is still unstable, stop and request more context rather than improvising a spec.

Rules

• Do not ask broad open-ended questions.
• Do not end brainstorming with a prose-only "which option?" prompt when native structured ask is available.
• Do not ask the user to re-confirm a direction that was already locked through native structured choice.
• Do not enter implementation with unresolved direction.
• Do not invent user_confirmed from weak language, status updates, or fallback reasoning.
• Do not use agent_vote_fallback for business, security, production, public contract, credential, destructive, schema, or message-contract decisions.