This skill should be used when exploring requirements and approaches through collaborative dialogue before planning implementation.
From soleurnpx claudepluginhub jikig-ai/soleur --plugin soleurThis skill uses the workspace's default tool permissions.
references/brainstorm-brand-workshop.mdreferences/brainstorm-domain-config.mdreferences/brainstorm-validation-workshop.mdNote: The current year is 2026. Use this when dating brainstorm documents.
Brainstorming helps answer WHAT to build through collaborative dialogue. It precedes the soleur:plan skill, which answers HOW to build it.
Process knowledge: Load the brainstorm-techniques skill for detailed question techniques, approach exploration patterns, and YAGNI principles.
<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.
Load project conventions:
# Load project conventions
if [[ -f "CLAUDE.md" ]]; then
cat CLAUDE.md
fi
Read CLAUDE.md if it exists - apply project conventions during brainstorming.
Branch safety check (defense-in-depth): Run git branch --show-current. If the result is main or master, and knowledge-base/ exists, create the worktree immediately (pulling Phase 3 forward) so that dialogue and file writes happen on a feature branch. Derive the feature name from the feature description (kebab-case). Run ./plugins/soleur/skills/git-worktree/scripts/worktree-manager.sh feature <name>, then cd .worktrees/feat-<name>. Set WORKTREE_CREATED_EARLY=true so Phase 3 skips worktree creation. If knowledge-base/ does not exist, abort with: "Error: brainstorm cannot run on main/master without knowledge-base/. Checkout a feature branch first." This check fires in all modes as defense-in-depth alongside PreToolUse hooks -- it fires even if hooks are unavailable (e.g., in CI).
Plugin loader constraint: Before proposing namespace changes (bare commands, command-to-skill migration), verify plugin loader constraints -- bare namespace commands are not supported, and commands/skills have different frontmatter and argument handling.
Evaluate whether brainstorming is needed based on the feature description.
Clear requirements indicators:
If requirements are already clear: Use AskUserQuestion tool to suggest: "Your requirements seem clear enough to skip brainstorming. How would you like to proceed?"
Options:
skill: soleur:one-shot for full autonomous execution (plan, deepen, implement, review, resolve todos, browser test, feature video, PR). Best for simple, single-session tasks like bug fixes or small improvements.skill: soleur:plan to create a plan before implementingIf one-shot is selected, pass the original feature description (including any issue references) to skill: soleur:one-shot and stop brainstorm execution. Note: this skips brainstorm capture (Phase 3.5), worktree creation (Phase 3), and spec/issue creation (Phase 3.6) -- the one-shot pipeline handles setup through the plan skill.
Assess whether the feature description has implications for specific business domains. Domain leaders participate in brainstorming when their domain is relevant.
<!-- To add a new domain: add a row to the Domain Config table below. No other structural edits needed. -->Read plugins/soleur/skills/brainstorm/references/brainstorm-domain-config.md now to load the Domain Config table with all 8 domain rows (Marketing, Engineering, Operations, Product, Legal, Sales, Finance, Support). Each row contains: Assessment Question, Leader, Routing Prompt, Options, and Task Prompt.
{desc} with the feature description. If multiple domains are relevant, spawn them in parallel. Weave each leader's assessment into the brainstorm dialogue alongside repo research findings.Read plugins/soleur/skills/brainstorm/references/brainstorm-brand-workshop.md now for the full Brand Workshop procedure (worktree creation, issue handling, brand-architect handoff, completion message). Follow all steps in the reference file, then STOP -- do not proceed to Phase 1.
Read plugins/soleur/skills/brainstorm/references/brainstorm-validation-workshop.md now for the full Validation Workshop procedure (worktree creation, issue handling, business-validator handoff, completion message). Follow all steps in the reference file, then STOP -- do not proceed to Phase 1.
If the feature description references an external platform, marketplace, or service, WebFetch the URL first before launching any research agents. Classify by: (1) self-service or waitlist? (2) discovery surface or procurement layer? (3) does it accept the product category? (4) what are the per-plan quantitative limits? (number of tasks, storage, API calls, concurrent sessions) (5) does the limit cover the migration/feature scope? This 30-second gate prevents spawning agents that analyze a false premise. Why: In #1094, a 9-workflow migration plan was built before discovering the Max plan allows only 3 Cloud scheduled tasks — a limit only discoverable by attempting to create the 4th task or checking via the RemoteTrigger API.
Run these agents in parallel to gather context before dialogue:
What to look for:
knowledge-base/project/learnings/ -- past gotchas, patterns, lessons learned that might inform WHAT to buildIf either agent fails or returns empty, proceed with whatever results are available. Weave findings naturally into your first question rather than presenting a formal summary.
Use the AskUserQuestion tool to ask questions one at a time.
Guidelines (see brainstorm-techniques skill for detailed techniques):
Exit condition: Continue until the idea is clear OR user says "proceed"
Propose 2-3 concrete approaches based on research and conversation.
For each approach, provide:
Lead with your recommendation and explain why. Apply YAGNI—prefer simpler solutions.
Use AskUserQuestion tool to ask which approach the user prefers.
Domain re-assessment. If the scope has materially changed from the original feature description (e.g., from internal tooling to user-facing product feature, or from a single-domain change to a cross-domain capability), re-run Phase 0.5 domain assessment for any domains not already consulted. Scope pivots during brainstorming are common — the domain assessment must reflect the final scope, not just the initial description.
IMPORTANT: Create the worktree BEFORE writing any files so all artifacts go on the feature branch.
If WORKTREE_CREATED_EARLY=true (worktree was created in Phase 0 branch safety check), skip steps 1-2 below and proceed to step 3 (set worktree path).
Check for knowledge-base directory:
if [[ -d "knowledge-base" ]]; then
# knowledge-base exists, create worktree first
fi
If knowledge-base/ exists:
Get feature name from user or derive from brainstorm topic (kebab-case)
Create worktree + spec directory:
./plugins/soleur/skills/git-worktree/scripts/worktree-manager.sh feature <name>
This creates:
.worktrees/feat-<name>/ (worktree)knowledge-base/project/specs/feat-<name>/ (spec directory in worktree)Set worktree path for subsequent file operations:
WORKTREE_PATH=".worktrees/feat-<name>"
All files written after this point MUST use this path prefix.
Create draft PR:
Switch to the worktree and create a draft PR:
cd .worktrees/feat-<name>
bash ./plugins/soleur/skills/git-worktree/scripts/worktree-manager.sh draft-pr
This creates an empty commit, pushes the branch, and opens a draft PR. If the push or PR creation fails (no network), a warning is printed but the workflow continues.
Write the brainstorm document. Use worktree path if created.
File path:
<worktree-path>/knowledge-base/project/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md (replace <worktree-path> with the actual worktree path, e.g., .worktrees/feat-<name>)knowledge-base/project/brainstorms/YYYY-MM-DD-<topic>-brainstorm.mdDocument structure: See the brainstorm-techniques skill for the template format. Key sections: What We're Building, Why This Approach, Key Decisions, Open Questions.
If domain leaders participated in Phase 0.5, include a ## Domain Assessments section after "Open Questions" with structured carry-forward data for the plan skill:
## Domain Assessments
**Assessed:** Marketing, Engineering, Operations, Product, Legal, Sales, Finance, Support
### [Domain Name]
**Summary:** [1-2 sentence assessment summary from domain leader]
### [Domain Name]
**Summary:** [1-2 sentence assessment summary from domain leader]
**Assessed:** line lists all 8 domains to confirm completeness### [Domain Name] subsections with summariesIf domain leaders reported capability gaps in their assessments, include a ## Capability Gaps section after "Domain Assessments" listing each gap with what is missing, which domain it belongs to, and why it is needed. Omit this section if no gaps were reported.
Ensure the brainstorms directory exists before writing.
If worktree was created:
Check for existing issue reference in feature_description:
Parse the feature description for #N patterns (e.g., #42). Extract the first issue number found.
If issue reference found, validate its state by running gh issue view <number> --json state and pipe to jq .state:
Create GitHub issue (only if no valid existing issue):
gh issue create --title "feat: <Feature Title>" --milestone "Post-MVP / Later" --body "..."
After creation, read knowledge-base/product/roadmap.md and update the milestone if a more specific phase applies: gh issue edit <number> --milestone '<phase>'.
Include in the issue body:
feat-<name>)Update existing issue with artifact links (if using existing issue):
Fetch the existing issue body with gh issue view <number> --json body piped to jq .body. Append an Artifacts section with links to the brainstorm document, spec file, and branch name. Then update with gh issue edit <number> --body "<updated body>".
Generate spec.md using spec-templates skill template:
Save spec.md to the worktree: <worktree-path>/knowledge-base/project/specs/feat-<name>/spec.md (replace <worktree-path> with the actual worktree path)
Commit and push all brainstorm artifacts:
After the brainstorm document (Phase 3.5) and spec are both written, commit and push everything:
git add knowledge-base/project/brainstorms/ knowledge-base/project/specs/feat-<name>/
git commit -m "docs: capture brainstorm and spec for feat-<name>"
git push
If the push fails (no network), print a warning but continue. The artifacts are committed locally.
Create tracking issues for deferred items:
Scan the brainstorm document's Key Decisions table and Non-Goals for items explicitly deferred to a later phase (e.g., "deferred to Phase 3", "revisit when X grows"). For each deferred item, create a GitHub issue:
gh issue create --title "feat: <deferred item>" --milestone "Post-MVP / Later" --body "Deferred from #<parent-issue> during brainstorm on <date>.\n\n## What was deferred\n<description>\n\n## Why deferred\n<rationale from brainstorm>\n\n## Re-evaluation criteria\n<when to revisit>"
After creation, read knowledge-base/product/roadmap.md and update the milestone if a more specific phase applies. If no items were deferred, skip silently.
Switch to worktree:
cd .worktrees/feat-<name>
IMPORTANT: All subsequent work for this feature should happen in the worktree, not the main repository. Announce the switch clearly to the user.
Announce:
.worktrees/feat-<name>. Use skill: soleur:plan to create tasks.".worktrees/feat-<name>. Use skill: soleur:plan to create tasks."If knowledge-base/ does NOT exist:
knowledge-base/project/brainstorms/ only (no worktree)Execute concluded actions first. If the brainstorm concluded with an immediate actionable step (subscribe to a service, configure a tool, open a page), execute it via Playwright, xdg-open, CLI, or API before presenting handoff options. Do not list it as a prose "action item."
Context headroom notice: Before presenting options, display: "All artifacts are on disk. Starting a new session for /soleur:plan will give you maximum context headroom."
Use AskUserQuestion tool to present next steps:
Question: "Brainstorm captured. Now in worktree feat-<name>. What would you like to do next?"
Options:
skill: soleur:plan (will auto-detect this brainstorm)When complete, display:
Brainstorm complete!
Document: knowledge-base/project/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md
Spec: knowledge-base/project/specs/feat-<name>/spec.md
Issue: #N (using existing) | #N (created) | none
Branch: feat-<name> (if worktree created)
Working directory: .worktrees/feat-<name>/ (if worktree created)
Key decisions:
- [Decision 1]
- [Decision 2]
Next: Use `skill: soleur:plan` when ready to implement.
Issue line format:
#N (using existing) - When brainstorm started with an existing issue reference#N (created) - When a new issue was creatednone - When no worktree/issue was createdUpdate an existing brainstorm:
If re-running brainstorm on the same topic, read the existing document first. Update in place rather than creating a duplicate. Preserve prior decisions and mark any changes with [Updated YYYY-MM-DD].
Archive old brainstorms:
Run bash ./plugins/soleur/skills/archive-kb/scripts/archive-kb.sh from the repository root. This moves matching artifacts to knowledge-base/project/brainstorms/archive/ with timestamp prefixes, preserving git history. Commit with git commit -m "brainstorm: archive <topic>".
NEVER CODE! Just explore and document decisions.