# Brainstorming > Use as Step 1 of the PROJ workflow before creating or changing any feature, component, workflow, or behavior. Turns a feature idea into one or more approved buildable concepts through project discovery, scope decomposition, structured intake, bounded exploration, assumption playback, and risk review. Produces specs/PROJ--/1_brainstorm/PROJ--concept.md, then hands off to visual-companion for UI features or requirements-engineer for backend/API features. - Skill: `silviobeer/brainstorming` (Agent Skill) - Install (CLI): `npx skillmds@latest add silviobeer/brainstorming` - Raw SKILL.md: https://api.skillmd.com/api/skills/silviobeer/brainstorming/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: silviobeer (https://skillmd.com/u/silviobeer) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/silviobeer/brainstorming --- # Brainstorming Ideas Into Feature Concepts ## Purpose Turn a feature idea into one or more clear, buildable feature concepts. This is the start of the whole PROJ skill chain. It establishes the PROJ number, theme slug, project folder, concept document, scope boundaries, assumptions, and first handoff decision that every later skill depends on. If the seed idea is too broad for one PROJ, this skill first cuts it into separate PROJs with explicit dependencies and sequencing. This is not free-form ideation and not implementation planning. The endpoint is always one or more approved buildable feature concepts written to `specs/PROJ--/1_brainstorm/PROJ--concept.md`, matching the chain-guide Step 1 output. The concept document defines the feature's purpose, users, scope, success criteria, constraints, explored approaches, selected direction, and known risks. Start by understanding the current project context. Then assess whether the seed idea fits one PROJ or should be decomposed into multiple PROJs. After the scope boundary is approved, collect the minimum inputs needed to shape each feature concept. Ask questions one at a time. Explore alternatives before choosing a direction. Do not proceed until the user confirms that nothing important is unclear. Do NOT invoke any implementation skill, write code, scaffold a project, edit production files, or create an implementation plan until you have presented a feature concept and the user has approved it. Do NOT fill gaps with assumptions. If you catch yourself thinking "I assume the user means X", ask the user instead. Probable is not certain. A vague "yes" is not clarification. Answers like "yes", "looks fine", "should work", "probably", "I think so", or "mostly" are non-answers when a concrete decision is needed. Re-ask with specific alternatives. ## Core Rule Ask one question per response unless the user explicitly asks for a checklist or wants to move fast. If a needed answer can be discovered from the project, inspect the project instead of asking. ## Chain Ownership This skill owns the first durable artifact in the process: ```text specs/PROJ--/1_brainstorm/PROJ--concept.md ``` Later skills consume this artifact: - `visual-companion` uses it to explore UI layout shape. - `frontend-design` uses the selected UI direction when design language is needed. - `ui-mockup` uses it plus visual/design decisions to create HTML mockups and implementation handoff. - `requirements-engineer` uses it to write PRDs, user stories, acceptance criteria, and edge cases. - `architecture` uses it with PRDs to write PROJ-level technical design. - `writing-plans`, `executing`, `qa`, and `documentation` rely on its scope boundaries and project identity. Because this starts the chain, each concept must be stable enough for downstream skills to use without re-litigating the basic feature intent. Do not leave unresolved ambiguity in the concept just because a later step exists. When one seed idea becomes multiple PROJs, each PROJ has its own concept document, downstream path, scope boundary, and dependency notes. Later skills run per PROJ unless the user explicitly asks to continue with several PROJs in sequence. ## Output Contract The concept document must provide enough product-level input for downstream skills to proceed without repeating discovery. ### Required For All Downstream Skills - Feature intent and selected product direction. - Primary users and concrete usage scenarios. - Current workflow or pain. - If decomposed from a larger seed: how this PROJ relates to sibling PROJs and what dependency order exists. - Scope boundaries: in scope, out of scope, later. - Success criteria stated as product/user outcomes. - Product-level constraints, dependencies, and risks. - Confirmed assumptions and conscious trade-offs. - High-level implementation success conditions. ### Required For `visual-companion` When The Feature Has UI - Primary user job and surrounding context. - Information shape: list/detail, form-heavy, review/approval, timeline, dashboard, wizard-like, or other high-level shape. - Likely UI tensions that need exploration, without choosing the container. - Mobile importance, deep-link needs, destructive-action concerns, and context-preservation needs. - UI anti-goals or constraints from the product discussion. ### Required For `requirements-engineer` - Users and scenarios. - Selected direction and major behaviors. - Scope boundaries and success criteria. - Product-level edge cases and failure expectations. - Constraints that PRDs must preserve. ### Required For `architecture` And Planning - Product constraints with technical implications. - Data ownership hints, permission hints, and external dependency hints. - Operational risks, durability expectations, latency expectations, and existing behavior to preserve. - Explicit non-goals so architecture and plans do not overbuild. ### Mockup-Relevant Inputs For UI features, brainstorming may record product vocabulary, required high-level states, content examples, and existing behavior to preserve. It must not create screen lists, sitemaps, component reuse decisions, visual styling, or UI implementation handoff; those belong to `visual-companion`, `frontend-design`, and `ui-mockup`. ## Downstream Boundary Brainstorming must produce the inputs later skills need without doing their work. ### Brainstorming Owns - Feature intent and problem framing. - Primary users and real usage scenarios. - Current workflow or pain. - Business/product success criteria. - Scope boundaries: in scope, out of scope, later. - Product-level constraints and dependencies. - High-level implementation success discussion: what must be true for the later implementation to be considered successful. - High-level risks and trade-offs. - Whether the feature has UI and therefore needs `visual-companion`. - Whether the feature is pure backend/API and can go directly to `requirements-engineer`. ### Brainstorming Does Not Own - UI container decisions such as sidepanel, modal, drawer, split view, wizard, or dedicated page. That belongs to `visual-companion`. - Visual design language, colors, typography, spacing, or style direction. That belongs to `frontend-design`. - Screen-by-screen mockups, sitemap, detailed states, component reuse labels, or UI implementation handoff. That belongs to `ui-mockup`. - User stories, acceptance criteria, or detailed edge-case matrices. That belongs to `requirements-engineer`. - Technical architecture, data model design, API design, package choices, or implementation strategy. That belongs to `architecture` and later planning. - Wave plans, tasks, tests, file ownership, or production code. That belongs to `writing-plans` and `executing`. When a question drifts into a later skill's responsibility, capture it as a downstream input, handoff note, or open decision instead of resolving it in brainstorming. ## Brownfield Context Intake (Discovery Track) On the product discovery track there is usually **no codebase to scan**, so the "Auto-Discovered Inputs" repo scan finds little. When the work extends or fits into something that already exists — a live product, an established design system, a brand, known domain vocabulary — capture that existing state explicitly so it is not lost. Skip this section for greenfield discovery (nothing exists yet) and for the full in-repo chain (the repo scan already covers it). Run this during project-context discovery, before the Decomposition Gate. Ask the user what already exists and gather references: - **Existing surfaces:** live URLs of the current product/screens, or screenshots the user provides. - **Design system / brand:** Figma/Storybook/styleguide links, brand colors, fonts, component library, or a screenshot of the current UI. - **Vocabulary:** domain terms already in use that must not be renamed (with spelling conventions). - **Constraints and invariants:** rules, integrations, or behaviors that already exist and must be preserved. You may fetch a provided live URL for reference (structure, copy, visible patterns) and read provided screenshots. Do not guess — only record what the user confirms or what a reference clearly shows. Write the captured state to a dedicated context folder so downstream skills can consume it: ```text specs/PROJ--/0_context/existing-state.md specs/PROJ--/0_context/references/ # screenshots, exported style guides, saved links ``` `existing-state.md` structure: ```markdown # Existing State — PROJ- ## Existing Product / Surfaces - — what it is, what it covers ## Design System / Brand - Source: - Colors / fonts / spacing / radius conventions: - Component library / patterns to reuse: ## Domain Vocabulary | Term | Meaning | Notes (spelling, do-not-rename) | |------|---------|---------------------------------| ## Existing Constraints And Invariants - ## Open Questions About The Existing State - ``` Downstream consumers: - `visual-companion` uses it to ground layout exploration in the existing shell. - `ui-mockup` uses it in **design-system mode** to adopt existing tokens, components, and patterns (there is no `tailwind.config` to scan on this track). - `handoff-package` folds it into the standalone package so external readers see the as-is starting point. Record in the concept's `Project Context` that `0_context/existing-state.md` exists and is the source of as-is truth. ## Project Decomposition Gate Run this gate immediately after project-context discovery and before detailed feature-concept intake. ### Why This Exists PRDs, user stories, and waves are too late for deciding whether one broad seed is actually multiple PROJs: - **PRDs/user stories** split behavior inside an already-approved PROJ. They are good for testable feature slices, not for deciding project identity. - **Waves** split implementation order. They are good for dependency management during execution, not for product scoping. - **Brainstorming** owns product boundaries. It must decide whether the seed should become one PROJ or multiple PROJs before downstream artifacts inherit the wrong scope. Skipping this gate is acceptable only when the seed has one coherent user outcome, one main audience, and one downstream path. ### When To Decompose Split one seed idea into multiple PROJs when two or more of these are true: - It contains independent user goals that can ship, test, or be adopted separately. - It touches different subsystems with different owners, risk profiles, data models, or rollout paths. - It mixes foundation/enabling work with user-facing workflows. - It includes multiple audiences whose success criteria differ materially. - It would naturally produce several PRDs with weak dependency between them. - It needs separate UI exploration paths, such as admin tooling plus end-user workflow. - It contains a risky or unknown piece that should be isolated before broader product work. - One part is clearly MVP-critical while another is expansion, automation, analytics, migration, support tooling, or polish. Do not decompose only because a feature is complex. Keep it as one PROJ when the pieces must be designed, shipped, and validated together to create user value. ### Decomposition Output If the seed appears too broad, stop detailed questioning and present a proposed project map: ```markdown This seed looks larger than one PROJ. I recommend splitting it into: 1. PROJ-A candidate: - User value: - Scope: - Explicitly not included: - Depends on: - Suggested downstream path: visual-companion | requirements-engineer 2. PROJ-B candidate: - User value: - Scope: - Explicitly not included: - Depends on: - Suggested downstream path: visual-companion | requirements-engineer Recommended first PROJ: , because . ``` Use temporary labels such as "PROJ-A candidate" until the user approves the split. Do not allocate real PROJ numbers before approval. ### User Approval Rules Ask the user to approve or correct the split before continuing: > "Does this project split match your intent, or should any of these be merged, removed, renamed, or reordered?" This is a concrete decision, so a vague "yes" is not enough if the split has unresolved boundaries. Re-ask with specific merge/remove/reorder options when needed. After approval: - Decide whether to create concepts for all approved PROJs now or only the recommended first PROJ. - If the user wants all concepts now, process them one at a time in dependency order. - Allocate real PROJ numbers only after the split and ordering are approved. - Each PROJ gets its own folder and concept doc. - Each concept doc must record its sibling PROJs, dependencies, and excluded sibling scope. - If one PROJ blocks another, mark the blocked PROJ's next step as "wait for PROJ-" rather than handing it directly to the next skill. ### Decomposition In Concept Documents For every concept created from a decomposed seed, include: - Original seed idea. - Approved decomposition map. - This PROJ's role in the map. - Sibling PROJs and boundaries. - Dependencies and recommended order. - What intentionally belongs to another PROJ. If the user rejects decomposition, document the conscious decision in the concept under `Risks And Trade-Offs`, including why the broader scope is still acceptable as one PROJ. ## Checklist Create a task for each item and complete them in order: 1. **Explore project context** - inspect docs, specs, routes, components, APIs, recent commits, and relevant agent instructions. On the discovery track with no codebase, run the **Brownfield Context Intake** instead/in addition: capture existing surfaces, design system, vocabulary, and constraints into `0_context/`. 2. **Run project decomposition gate** - if the idea spans multiple independent user goals, subsystems, risks, rollout paths, or audiences, stop detailed questioning and propose a multi-PROJ split. If `specs/product-roadmap.md` exists, the cut and the PROJ number are already decided there: take the entry's user outcome, `Depends on`, and boundaries as given, and set its `Status` to `concept`. Only decompose further if this single entry turns out to be more than one PROJ — then split it in the roadmap too, with a changelog line. 3. **Approve project boundary** - get explicit user approval for one PROJ or an approved multi-PROJ map before feature intake. 4. **Choose processing order** - for a multi-PROJ map, confirm whether to write only the first concept or write all concepts in dependency order. 5. **Collect feature-concept intake** - gather required inputs for the current PROJ, using project discovery where possible. 6. **Research if needed** - browse only for current, niche, regulated, or unfamiliar technical/domain context. 7. **Clarifying questions** - ask one at a time until mandatory deep-dives are covered. 8. **Controlled exploration** - explore 2-4 viable directions before selecting an approach. 9. **Assumption playback** - read back every assumption and wait for confirmation/correction. 10. **Devil's-Advocate pass** - list 3-5 weaknesses, risks, or unresolved tensions and resolve them with the user. 11. **Explicit clarity confirmation** - ask exactly: "From your perspective, is everything now clear, or are there still unclear or open points?" 12. **Present feature concept** - section by section, scaled to complexity, and get approval. 13. **Allocate PROJ-X number and theme slug** - scan `specs/PROJ-*/`, pick next free integer, agree on kebab-case theme. 14. **Create PROJ folder and state** - create `specs/PROJ--/1_brainstorm/`, then run `bash ~/.codex/skills/4a_checkpoint/scripts/state.sh init `. The new file stays `CP1:pending`; only checkpoint (4a) may approve it. 15. **Write concept doc** - `specs/PROJ--/1_brainstorm/PROJ--concept.md`. 16. **Concept self-review** - fix placeholders, contradictions, ambiguity, missing deep-dives, and scope creep. 17. **User reviews written concept** - wait for approval before transition. 18. **Repeat or transition** - for multi-PROJ maps, repeat concept creation for the next approved PROJ or transition the current PROJ to visual-companion/requirements-engineer. ## Feature Concept Intake Collect these inputs before converging on the concept. Do not ask everything up front. Use project inspection first, then ask the user only for missing or ambiguous inputs. ### Auto-Discovered Inputs Gather from the repository before asking: - Existing project purpose from `README.md`, `docs/`, `specs/INDEX.md`, and current specs. - Existing routes, screens, components, APIs, schemas, and data flows. - Existing design or implementation constraints from `AGENTS.md`, docs, Tailwind/theme files, component registry, deployment config, and recent commits. - Relevant platform constraints such as Vercel runtime, storage, env vars, cron, analytics, and serverless limits. - Prior related decisions in existing PROJ folders. Summarize discoveries briefly before asking clarifying questions. ### Required User Inputs These must be known before the concept can be approved: - **Feature seed:** What is the feature idea, problem, or opportunity? - **Primary users:** Who uses this, in which concrete scenario? - **Current workflow or pain:** What happens today, and where does it break down? - **Success criteria:** How will we know the feature is finished and successful? Prefer observable or measurable signals. - **Scope boundaries:** What is in scope, out of scope, and explicitly later? - **Project boundary:** Is this one coherent PROJ, or should it be split into multiple PROJs with separate outcomes? - **Constraints:** Technical, data, auth, privacy, compliance, mobile/desktop, timeline, operational, or deployment constraints. ### Conditional Inputs Ask only when relevant: - **Data ownership:** What data is created, read, updated, deleted, imported, exported, or retained? - **Permissions:** Which users or roles can see or change what? - **Failure handling:** What should happen when an external service, database, upload, model call, or background task fails? - **Migration or compatibility:** Does this affect existing users, data, APIs, URLs, saved settings, or integrations? - **Auditability:** Do actions need logs, history, approvals, or rollback? - **Shareability:** Do screens or objects need deep links? - **Volume and performance:** Expected item counts, file sizes, traffic, latency, or concurrency. - **Internationalization/timezone:** Languages, locales, currencies, date handling, or time zones. ### High-Level Implementation Success Inputs Discuss implementation success only at the level needed to guide downstream skills: - What would make the delivered feature feel successful to users and stakeholders? - What must remain true about the existing product while this feature is added? - Which constraints would make an otherwise correct implementation unacceptable? - Which operational failures must be avoided or handled gracefully? - Which downstream artifact needs special attention: UI shape, mockups, PRDs, architecture, wave planning, QA, or documentation? Do not decide how to implement these points. Record them as product-level success conditions, constraints, risks, or handoff notes. ### Concept-Shaping Inputs Use these to choose the right direction, not to inflate scope: - **Concept emphasis:** MVP slice, UX direction, technical feasibility, scope decomposition, or risk reduction. The output remains a buildable concept either way. - **Implementation appetite:** small tactical change, solid MVP, extensible foundation, or high-polish workflow. - **Risk tolerance:** conservative, balanced, experimental. - **Decision priority:** speed, correctness, UX quality, maintainability, cost, compliance, or future extensibility. ## Clarifying Questions Mandatory deep-dives: - **Success criteria:** Ask at least two questions unless already concrete and measurable. - **Out-of-scope:** Ask at least two questions to define boundaries and "later". - **Users and scenarios:** Ask at least two questions to get concrete personas and usage contexts. - **Edge cases:** Ask at least one "what if" question per major feature area. Prefer multiple-choice questions when helpful. Open-ended questions are fine when the user has useful context that options would bias. If the user gives a vague answer, re-ask with concrete options. Do not advance on a vague yes. ## Controlled Exploration Before presenting the concept, explore product-level alternatives deliberately. This prevents the first plausible idea from becoming the concept by inertia. Choose the exploration mode from project context and user answers. Ask the user only if the right mode is genuinely ambiguous. - **Practical options:** Generate 2-3 realistic feature approaches with trade-offs. - **Broad exploration:** Generate several possible product shapes, then narrow. - **Wild alternatives:** Briefly include unusual or constraint-breaking options, then extract practical lessons. - **Progressive flow:** Start broad, cluster themes, then select a buildable direction. Do not target 50-100 ideas. This skill exists to produce a feature concept, so exploration should be enough to reveal better directions without delaying convergence. For UI features, exploration may identify that the next decision is about interface shape, but must not choose the detailed layout container. Capture likely UI tensions for `visual-companion` instead. ### Perspective Pivots When the discussion is stuck or too narrow, pivot through 3-5 lenses: - User experience - Technical feasibility - Existing system fit - Data model and ownership - Auth, permissions, security, and privacy - Operations, support, and observability - Edge cases and failure modes - Cost, latency, and deployment/runtime constraints - Future extensibility - What is intentionally not being built Use pivots as internal prompts, not as a long questionnaire. ## Approach Proposal After intake and exploration, propose 2-3 approaches. For each approach include: - What it is - Best fit - Trade-offs - Scope impact - Main risks Lead with your recommendation and explain why. The recommendation must account for project context, user goals, success criteria, constraints, and out-of-scope boundaries. ## Assumption Playback Before the Devil's-Advocate pass, explicitly read back assumptions: ```markdown I derived the following assumptions from your answers. Please confirm or correct each one: 1. ... 2. ... 3. ... ``` Wait for the user to confirm or correct each one. Corrections trigger follow-up questions, not silent re-derivation. Separate: - **Confirmed inputs:** stated directly by the user or discovered in project files. - **Assumptions:** inferred from answers and needing confirmation. - **Open questions:** still unresolved. ## Devil's-Advocate Pass List 3-5 weaknesses, risks, or unresolved tensions in the selected direction. Examples: - "The success criterion says 'fast', but we have not defined a threshold. Is under 500ms the target?" - "The out-of-scope list excludes admin tools, but support may need a manual recovery path. Is that accepted risk?" - "Two personas may update the same object at the same time. We have not chosen conflict behavior." - "This depends on durable background work, but the deployment target is serverless. We need a persistence strategy." The user must resolve each item or explicitly accept it as a conscious risk. ## Explicit Clarity Confirmation Ask exactly: > "From your perspective, is everything now clear, or are there still unclear or open points?" Only an unambiguous answer such as "everything is clear" or "nothing is unclear anymore" lets you proceed. Any vague or partial answer sends you back to clarification. ## Presenting The Feature Concept Present the concept in sections scaled to complexity. Ask for approval after each section when the concept is large or nuanced. Cover: - Original seed and decomposition map, if this came from a broader idea - Problem and goal - Primary users and scenarios - Current workflow or pain - Selected direction - Scope - Out of scope - Success criteria - Key flows or behaviors - Data and permissions, if relevant - Error and edge-case behavior - Constraints and dependencies - High-level implementation success conditions - Downstream handoff notes - Explored alternatives and why they were not selected - Risks and conscious trade-offs - Testing focus Do not over-specify implementation details. Architecture, PRDs, plans, and implementation come later. ## Concept Document After approval, allocate the PROJ folder and write: ```text specs/PROJ--/1_brainstorm/PROJ--concept.md ``` Use this structure: ```markdown # PROJ- Concept - ## Status Approved concept ## Feature Seed ## Decomposition Context - Original broader seed: - Approved project map: - This PROJ's role: - Sibling PROJs: - Depends on: - Blocks: - Scope intentionally assigned to another PROJ: ## Project Context - Existing system: - As-is reference (discovery track): `0_context/existing-state.md` if captured - Relevant constraints: - Prior related specs: ## Problem And Goal ## Primary Users And Scenarios ## Current Workflow Or Pain ## Success Criteria ## Scope ### In Scope ### Out Of Scope ### Later ## Selected Direction ## Key Behaviors And Flows ## Data, Permissions, And Constraints ## Error Handling And Edge Cases ## High-Level Implementation Success - User/stakeholder success: - Product constraints: - Operational constraints: - Existing behavior to preserve: - Downstream attention needed: ## Downstream Handoff Notes - For visual-companion: - Mockup-relevant product inputs: - For requirements-engineer: - For architecture/planning: ## Explored Alternatives ### Alternative A - Summary: - Why not selected: ### Alternative B - Summary: - Why not selected: ## Assumptions Confirmed ## Risks And Trade-Offs ## Testing Focus ## Next Step - UI feature: visual-companion - Backend/API feature: requirements-engineer ``` The concept is the root input for the rest of the chain. Keep it product-level and decision-rich, but do not turn it into PRDs, architecture, or an implementation plan. Commit with: ```bash feat(PROJ-): add concept for ``` Git is optional on the discovery track. If the workspace is not a git repository, skip the commit (or suggest an optional `git init` first — a version history is useful for tracking concept and mockup iterations). The concept file itself is the durable artifact, committed or not. ## Automatic Cross-Review Immediately after saving the concept, invoke `cross-review` in the same turn, before user review or transition. Do not ask whether to run it or wait for approval. Supply everything that establishes as-is truth for the concept: ```bash bash scripts/cross-review.sh concept \ --artifacts specs/PROJ--/1_brainstorm/PROJ--concept.md \ --ground-truth specs/PROJ--/0_context/existing-state.md \ docs/PRODUCT.md specs/product-roadmap.md \ --author-provider --round 1 ``` Drop any path that does not exist — the script fails on a missing file, and on the discovery track most of these may be absent. The grounding check ("claims about the existing product agree with the supplied context") is only as good as what you supply: with no ground truth at all, say so to the user rather than presenting the result as a grounded review. Follow `cross-review`'s automatic reconcile/re-review loop through round 3 while findings of any severity remain; stop early when clean. Escalate remaining Critical/High findings before transition. Ask only for unresolved product decisions. Additional manually requested rounds have no limit. ## Concept Self-Review Review the written concept before asking the user to review it: 1. **Placeholder scan:** no `TBD`, `TODO`, empty sections, or vague words standing in for decisions. 2. **Internal consistency:** selected direction, scope, users, success criteria, and risks do not contradict each other. 3. **Scope check:** the concept is focused enough for one PROJ, or it has been decomposed. 4. **Decomposition check:** for broad seeds, the approved project map, sibling PROJs, dependencies, and excluded sibling scope are documented. 5. **Ambiguity check:** requirements cannot be interpreted in materially different ways. 6. **Deep-dive coverage:** success criteria, out-of-scope, and users/scenarios are explicitly documented. 7. **Exploration record:** rejected/deferred alternatives are captured briefly. 8. **Assumption record:** confirmed assumptions are documented; unresolved assumptions are not hidden. 9. **Output contract check:** required downstream inputs are present for `visual-companion` or `requirements-engineer`, and for architecture/planning. 10. **Downstream boundary check:** none of these have leaked into the concept: - UI container choice such as sidepanel, modal, drawer, wizard, split view, or dedicated page. - Screen list, sitemap, detailed UI states, component reuse decision, visual styling, or UI implementation handoff. - User stories, acceptance criteria, or detailed edge-case matrix. - API design, schema design, package choice, architecture decision, task plan, test plan, file ownership, or production code. 11. **Implementation success check:** high-level implementation success is documented as product constraints, risks, or handoff notes, not as technical design. Fix issues inline. If fixing requires information not already confirmed, ask the user. ## User Review Gate After self-review, ask the user to review the written concept: > "Concept written and committed to `specs/PROJ--/1_brainstorm/PROJ--concept.md`. Automatic cross-review is complete. Please review the concept before we continue. Let me know if you want to make any changes." Wait for the user's response. If they request changes, update the concept and run self-review again. Only proceed after approval. ## Transition - If the feature has a UI component, invoke `visual-companion`. - If the feature is pure backend/API, invoke `requirements-engineer`. - If the current PROJ depends on an uncreated or unapproved sibling PROJ, pause transition and create or approve that prerequisite first. - Do NOT invoke writing-plans, architecture, executing, QA, documentation, or implementation directly from brainstorming. ## Key Principles - Feature concept is the endpoint. - Ask one question at a time. - Inspect the project before asking questions the repo can answer. - Split broad seeds into multiple PROJs before detailed intake. - Get explicit approval for project boundaries before allocating PROJ numbers. - Ask, never assume. - Vague answers are non-answers. - Explore before converging. - Keep exploration bounded by the goal of a buildable concept. - Record rejected alternatives. - YAGNI ruthlessly. - Stop only after deep-dives are covered, assumptions are confirmed, risks are addressed, and the user says nothing important is unclear.