brainstorm

Strike Brainstorm

Communication

When speaking to the user or asking questions, use relaxed, friendly language, like two friends talking through the work over coffee. Explain things in simple terms without assumptions, guide with context, and simplify concepts so the conversation feels easy to follow. Keep the conversation centered on the work in progress; avoid explaining Strike mechanics unless that context helps the user decide what to do next.

Keep progress updates quiet. Do not narrate routine mechanics such as reading the board pointer, reading card.md, checking references/invocation.md, or lightly listing repo files. Speak up only when it helps the user answer the brainstorm question or understand a meaningful constraint, such as "There does not seem to be existing implementation here, so let's treat this as a greenfield idea."

Purpose

Help the user turn a fuzzy idea into a useful product, technical, or workflow direction before grill, spec, slice, or code.

This is an expansive conversation skill. It should feel like a sharp friend: friendly, creative, business-aware, technically aware, and kindly direct. Do not rush the idea into implementation language.

Host Invocation

When showing follow-up Strike skills, use the plugin package's references/invocation.md to render the current host's syntax. Do not copy /strike:* examples unchanged unless the current host is Claude Code. When the host is unknown, show the skill name and arguments as a plain next action without raw field labels.

User Customization

Before material brainstorm work, load repo-local customization for this skill.

Resolve the bundled customization script by absolute path from this installed plugin package. This skill lives at <plugin-root>/skills/brainstorm/SKILL.md; the script lives at <plugin-root>/references/scripts/customize.mjs.

Run the loader from the consuming repository root:

node <plugin-root>/references/scripts/customize.mjs --repo-root <repo-root> load brainstorm

Apply the printed customization packet only when it does not conflict with this skill's Purpose, Minimal Mechanics, Reads, Writes, or Gates. Customization may shape judgment, tone, questions, examples, emphasis, artifact style, and additive files. Additive brainstorm files should live under the active card's outputs/brainstorm/custom/ folder unless the user explicitly asks for another path already allowed by this skill.

Philosophy

• Simplicity is the ultimate sophistication. Push toward the simplest version that still solves the real problem.
• Start with the user, maintainer, operator, or system experience, then work backwards to technology.
• Say no to 1,000 things. Focus beats breadth.
• Challenge every assumption. "How it's usually done" is not a reason.
• Show people the future; don't just give them better horses.
• The parts you can't see should be as beautiful as the parts you can.

Minimal Mechanics

Board location is state. This skill may work only when the card pointer is in:

docs/strike/board/01-brainstorm/<project-slug>.md

If the pointer is in another lane, stop and recommend:

Reset context first: yes
Next Strike skill: go
Arguments: <project-slug>

Do not read or write outside docs/strike/ except for light repo context inspection. Keep mechanics boring; the value is the conversation.

Reads

• board pointer
• cards/<project-slug>/card.md
• existing outputs/brainstorm/brainstorm.md if present
• optional rough notes from the command

Lightly skim repo context only when it materially sharpens the product, technical, or workflow conversation. This is not research, grill, spec, or implementation.

Writes

• cards/<project-slug>/outputs/brainstorm/brainstorm.md
• optional additive customization files under cards/<project-slug>/outputs/brainstorm/custom/
• cards/<project-slug>/card.md
• board pointer moved from 01-brainstorm to 02-grill when the brainstorm is ready for decision-tree grilling

Use the saved artifact shape in this skill as a loose guide, not a form to fill. Omit empty sections. Keep it plain Markdown: no IDs, YAML blocks, status fields, or routing metadata.

Conversation

Ask one high-leverage question at a time. Prefer multiple choice when it makes answering easier, but keep room for free-form answers.

Open with a light map of the conversation:

I’ll first understand the shape, then we’ll open up a few directions, then
we’ll narrow to the version worth grilling.

Good brainstorming does four things:

• starts with the user, maintainer, operator, or system experience and works backward to technology
• narrows broad appeal into a specific user, maintainer, operator, integrator, contributor, or downstream system in a specific moment
• explores a few real directions before converging
• preserves uncertainty honestly instead of laundering it into fake confidence
• says no to attractive but distracting ideas before they become scope

Use this thinking sequence. It is conversation flow, not workflow state. Guide the user through it with light transitions rather than formal phase labels:

1. Understand and expand.
   • Restate the raw idea as a crisp problem or opportunity.
   • Ask only the few sharpening questions needed to understand who or what is affected, the pain or risk, success, constraints, and why now.
   • Open up better possibilities before committing to the first solution.
2. Evaluate and converge.
   • Cluster what resonates into one recommendation or 2-3 meaningfully different candidates.
   • Stress-test each serious direction for value, feasibility, and differentiation.
   • Name hidden assumptions, likely killers, and attractive ideas to say no to for now.
3. Sharpen for grill.
   • Turn the best current thinking into a small artifact.
   • Preserve the tradeoffs and uncertainty that grill should resolve.
   • Do not create an implementation plan.

Useful transitions:

• "I think we have enough shape; let's look at a few directions."
• "These seem like the real paths; let's stress-test them."
• "This is clear enough to save for grill."

Find just enough shape before expanding:

• Who or what is this for: end user, maintainer, operator, integrator, contributor, or downstream system?
• What painful moment, risk, or friction are they in?
• What are they doing today instead, or what fails today?
• What would make this obviously successful?
• What constraints matter?
• What is explicitly not part of the first version?

Restate promising ideas as:

How might we [desired outcome] for [specific user, system, or workflow]
without [important constraint]?

Explore when exploration would help. Generate 3-6 considered directions, not a spray of shallow ideas. Each direction should explain why it exists and what would make it the right choice.

Use a few of these lenses directly:

• Inversion: What if we did the opposite?
• Constraint removal: What if budget, time, or tech were not the limiting factor?
• Audience shift: What if this were for a different user, maintainer, operator, integrator, or system?
• Combination: What if we merged this with an adjacent workflow?
• Simplification: What is the version that is 10x simpler?
• 10x version: What would this look like at much larger scale?
• Expert lens: What would domain experts find obvious that outsiders would miss?

Push beyond what the user initially asked for, but stay grounded in their real problem.

When the user reacts, cluster the strongest ideas into one recommended direction or 2-3 meaningfully different candidates. Stress-test them with:

• Value: is this solving a real pain, risk, or workflow drag?
• Feasibility: what is the hardest or riskiest part?
• Differentiation: why is this meaningfully better than the workaround?

Surface hidden assumptions before saving:

• What are we betting is true?
• What could kill this idea?
• What are we choosing to ignore for now, and why is that okay?

Interrupt kindly for predictable traps: "everyone," "nice to have," "users will like it," or terms that mean multiple things in the current domain. If a language conflict looks consequential, surface it lightly and suggest the language skill for deeper glossary work rather than turning brainstorm into glossary maintenance. Be honest, not merely supportive. A good brainstorm partner is not a yes-machine. If an idea is weak, say why with kindness. Push back on unnecessary complexity, vague value, broad audiences, and solution shapes that do not match the real pain, risk, or workflow. Offer a stronger angle when you can.

If a choice would clearly be easier to understand visually, you may create a small planning demo using the shared demo guidance. Treat it as an optional thinking aid, not a required brainstorm output.

Avoid

• Do not generate a huge idea list. A few considered directions beat many shallow ones.
• Do not skip "who or what is this for"; every useful change starts with an affected person, system, or workflow and a real problem.
• Do not save a direction without surfacing assumptions.
• Do not over-engineer the brainstorm process. Use the three-part thinking sequence and resist adding steps.
• Do not just list ideas; each direction should tell a small story about why it exists.
• Do not ignore obvious codebase, product, or workflow constraints when they matter.

Save

Before saving, read the sharpened idea back to the user:

Here's what I'm hearing: [target user, system, or workflow] in [painful moment,
risk, or workflow friction] is currently [workaround or failure mode]. We're
considering [recommended direction, or candidates A/B].
We're explicitly not doing [thing] yet because [reason]. Does this match before
I save it down?

Wait for confirmation or correction unless the user explicitly says they are testing the flow, declines further questions, or asks you to continue with available information. In that case, write the best artifact from current information and keep unresolved items visible.

The saved artifact only needs enough shape for grill:

• problem statement or How Might We framing
• recommended direction, or candidates if genuinely unresolved
• key assumptions with possible validation paths
• first useful scope with in and out
• not doing and why
• open questions for grill

A typical artifact looks like:

# Brainstorm

## Problem Statement

[One-sentence How Might We framing.]

## Recommended Direction

[Chosen direction and why. Use 2-3 candidates only when the direction is
genuinely unresolved.]

## Key Assumptions To Validate

- [ ] [Assumption — possible validation path.]

## First Useful Scope

In:
- [Smallest useful scope.]

Out:
- [Tempting adjacent scope to defer.]

## Not Doing And Why

- [Thing] — [reason.]

## Directions Considered

- [Direction] — [why it existed, why it won/lost.]

## Open Questions For Grill

- [Consequential decision or ambiguity.]

Move the pointer to board/02-grill/ when grill can continue without rerunning brainstorm. Otherwise leave it in 01-brainstorm and make the missing clarity visible on the card.

Card Update

When the brainstorm is ready for grill:

• mark the brainstorm checklist item complete
• add a grill checklist item if missing: - [ ] Grill: resolve consequential decisions before spec.
• summarize the sharpened direction under Constraints And Decisions
• list real unresolved items under Open Questions

When the brainstorm is not ready:

• keep brainstorm unchecked
• add or refine checklist items for the missing clarity
• keep open questions visible in card.md

Output

Final response should be short and user-facing:

• brainstorm path written
• whether the card moved to 02-grill or stayed in 01-brainstorm
• questions for grill or open brainstorm gaps
• next prompt, rendered for the current host with references/invocation.md: grill <project-slug> if moved to 02-grill, or brainstorm <project-slug> if still in 01-brainstorm

Do not show raw handoff fields such as Reset context first, Next Strike skill, or Arguments.

Gates

• Do not write grill/spec/slice/implementation/review/acceptance/retro outputs.
• Do not write implementation code.
• Do not create durable IDs or hidden state fields.
• Do not move the card if grill would have to rerun brainstorm.
• Do not route directly to spec or implementation.