From compound-engineering
Collaboratively explores feature requirements and options through dialogue, producing a right-sized requirements document for implementation planning. Use for vague ideas, brainstorming, or scoping ambitious requests.
npx claudepluginhub everyinc/compound-engineering-plugin --plugin compound-engineeringThis skill uses the workspace's default tool permissions.
**Note: The current year is 2026.** Use this when dating requirements documents.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Note: The current year is 2026. Use this when dating requirements documents.
Brainstorming helps answer WHAT to build through collaborative dialogue. It precedes /ce:plan, which answers HOW to build it.
The durable output of this workflow is a requirements document. In other workflows this might be called a lightweight PRD or feature brief. In compound engineering, keep the workflow name brainstorm, but make the written artifact strong enough that planning does not need to invent product behavior, scope boundaries, or success criteria.
This skill does not implement code. It explores, clarifies, and documents decisions for later planning or execution.
IMPORTANT: All file references in generated documents must use repo-relative paths (e.g., src/models/user.rb), never absolute paths. Absolute paths break portability across machines, worktrees, and teammates.
AskUserQuestion in Claude Code, request_user_input in Codex, ask_user in Gemini). Otherwise, present numbered options in chat and wait for the user's reply before proceeding.src/models/user.rb), never absolute paths. Absolute paths make documents non-portable across machines and teammates.<feature_description> #$ARGUMENTS </feature_description>
If the feature description above is empty, ask the user: "What would you like to explore? Please describe the feature, problem, or improvement you're thinking about."
Do not proceed until you have a feature description from the user.
If the user references an existing brainstorm topic or document, or there is an obvious recent matching *-requirements.md file in docs/brainstorms/:
Before proceeding to Phase 0.2, classify whether this is a software task. The key question is: does the task involve building, modifying, or architecting software? -- not whether the task mentions software topics.
Software (continue to Phase 0.2) -- the task references code, repositories, APIs, databases, or asks to build/modify/debug/deploy software.
Non-software brainstorming (route to universal brainstorming) -- BOTH conditions must be true:
Neither (respond directly, skip all brainstorming phases) -- the input is a quick-help request, error message, factual question, or single-step task that doesn't need a brainstorm.
If non-software brainstorming is detected: Read references/universal-brainstorming.md and use those facilitation principles to brainstorm with the user naturally. Do not follow the software brainstorming phases below.
Clear requirements indicators:
If requirements are already clear: Keep the interaction brief. Confirm understanding and present concise next-step options rather than forcing a long brainstorm. Only write a short requirements document when a durable handoff to planning or later review would be valuable. Skip Phase 1.1 and 1.2 entirely — go straight to Phase 1.3 or Phase 3.
Use the feature description plus a light repo scan to classify the work:
If the scope is unclear, ask one targeted question to disambiguate and then proceed.
Scan the repo before substantive brainstorming. Match depth to scope:
Lightweight — Search for the topic, check if something similar already exists, and move on.
Standard and Deep — Two passes:
Constraint Check — Check project instruction files (AGENTS.md, and CLAUDE.md only if retained as compatibility context) for workflow, product, or scope constraints that affect the brainstorm. If these add nothing, move on.
Topic Scan — Search for relevant terms. Read the most relevant existing artifact if one exists (brainstorm, plan, spec, skill, feature doc). Skim adjacent examples covering similar behavior.
If nothing obvious appears after a short scan, say so and continue. Two rules govern technical depth during the scan:
Verify before claiming — When the brainstorm touches checkable infrastructure (database tables, routes, config files, dependencies, model definitions), read the relevant source files to confirm what actually exists. Any claim that something is absent — a missing table, an endpoint that doesn't exist, a dependency not in the Gemfile, a config option with no current support — must be verified against the codebase first; if not verified, label it as an unverified assumption. This applies to every brainstorm regardless of topic.
Defer design decisions to planning — Implementation details like schemas, migration strategies, endpoint structure, or deployment topology belong in planning, not here — unless the brainstorm is itself about a technical or architectural decision, in which case those details are the subject of the brainstorm and should be explored.
Slack context (Standard and Deep only) — If any slack_* tool is available in the tool list, dispatch compound-engineering:research:slack-researcher with a brief summary of the brainstorm topic. If the agent returns an error or reports Slack MCP unavailable, log a warning ("Slack context unavailable: {reason}. Proceeding without organizational context.") and continue. Coordinate this dispatch at the start of Phase 1.1 alongside the inline Constraint Check and Topic Scan. Wait for all to complete before proceeding to Phase 1.2. Incorporate any Slack findings into the constraint and context awareness for the brainstorm session. Skip for Lightweight scope.
Before generating approaches, challenge the request to catch misframing. Match depth to scope:
Lightweight:
Standard:
Deep — Standard questions plus:
Follow the Interaction Rules above. Use the platform's blocking question tool when available.
Guidelines:
Exit condition: Continue until the idea is clear OR the user explicitly wants to proceed.
If multiple plausible directions remain, propose 2-3 concrete approaches based on research and conversation. Otherwise state the recommended direction directly.
Use at least one non-obvious angle — inversion (what if we did the opposite?), constraint removal (what if X weren't a limitation?), or analogy from how another domain solves this. The first approaches that come to mind are usually variations on the same axis.
Present approaches first, then evaluate. Let the user see all options before hearing which one is recommended — leading with a recommendation before the user has seen alternatives anchors the conversation prematurely.
When useful, include one deliberately higher-upside alternative:
For each approach, provide:
After presenting all approaches, state your recommendation and explain why. Prefer simpler solutions when added complexity creates real carrying cost, but do not reject low-cost, high-value polish just because it is not strictly necessary.
If one approach is clearly best and alternatives are not meaningful, skip the menu and state the recommendation directly.
If relevant, call out whether the choice is:
Write or update a requirements document only when the conversation produced durable decisions worth preserving. Read references/requirements-capture.md for the document template, formatting rules, visual aid guidance, and completeness checks.
For Lightweight brainstorms, keep the document compact. Skip document creation when the user only needs brief alignment and no durable decisions need to be preserved.
When a requirements document was created or updated, run the document-review skill on it before presenting handoff options. Pass the document path as the argument.
If document-review returns findings that were auto-applied, note them briefly when presenting handoff options. If residual P0/P1 findings were surfaced, mention them so the user can decide whether to address them before proceeding.
When document-review returns "Review complete", proceed to Phase 4.
Present next-step options and execute the user's selection. Read references/handoff.md for the option logic, dispatch instructions, and closing summary format.