Claude Skills for Brainstorming

A brainstorming skill divides the work into stages that do not usually belong together: generating ideas, checking them against constraints, and choosing among what remains. Keeping those stages separate produces better ideas and clearer records of why certain options were dropped.

Tools like fenbs record which ideas were accepted, which were rejected and why, and what rules constrained the session. That record means the next time a similar problem comes up, a connected assistant reads the past decisions rather than generating the same rejected options again.

Why structured brainstorming skills work better than open prompts

An open prompt like "give me ideas for X" produces a mix of categories without distinction. Some ideas are variations of the same concept. Some violate constraints you did not think to state. The useful ones are buried in a long list that requires judgment to read.

A structured skill separates divergent thinking (many options, no judgment) from convergent thinking (filtering against constraints, then choosing). Mixing them produces mediocre results at both: Claude filters during generation, which limits the range, and generates during selection, which muddles the decision.

Three skills handle this cleanly: one for generating, one for filtering, one for selecting. Run them in order and review the output between each step. The final shortlist has a documented reason for every item on it, and the rejected options are not just gone but recorded with the reason they were dropped.

The documented rejections are often the most valuable output. In a later session, they prevent the team from re-evaluating options that were already considered. They also reveal whether the constraints were the right ones: if a constraint eliminated fifteen of twenty ideas, it may be worth revisiting.

A skill for generating ideas without constraints

The generation skill asks for quantity over quality. The only rule is no self-filtering: Claude should not discard ideas because they seem impractical. That judgment belongs in the next step. Letting it enter the generation step shrinks the range before you have had a chance to evaluate it.

Generate ideas for the following goal.

Goal: {{what you are trying to achieve}}
Context: {{any relevant background, but not constraints}}

Rules:
- Generate at least 20 ideas
- Do not filter for practicality or feasibility
- Include at least three ideas that are unconventional or counterintuitive
- Group similar ideas loosely but do not combine them
- No evaluation or commentary on any idea

Output a numbered list only.

The unconventional ideas rule is deliberate. A list of twenty safe ideas is less useful than a list of seventeen safe ideas and three unusual ones. The unusual ideas often trigger combinations or variations that would not have appeared otherwise. Even rejected unconventional ideas can reframe the constraints.

A skill for filtering ideas against constraints

Once you have a list, the filter skill applies the real constraints and returns what survives. It also tells you why each idea was dropped, which is as useful as the ideas that remain. An idea eliminated by a constraint that turns out to be negotiable is worth knowing about.

Filter the following idea list against the constraints below.

Ideas:
{{paste the numbered list from the generation skill}}

Constraints:
- Budget: {{e.g., under $5,000 to implement}}
- Timeline: {{e.g., must be ready in 6 weeks}}
- Team: {{e.g., no engineering resources available}}
- Other: {{any additional constraints}}

For each idea, output:
  Idea number | Keep / Drop | Reason (one sentence)

After the list:
  Ideas kept: [count]
  Ideas dropped: [count]
  Note any constraint that eliminated most ideas (it may need revisiting).

The note at the end is worth reading carefully. If one constraint drops fifteen of twenty ideas, it is a signal worth bringing to the team. The constraint might be fixed. It might be negotiable. It might be a proxy for a different concern that has a narrower scope. Surfacing it explicitly is more useful than having it quietly determine the outcome.

A skill for selecting and ranking what remains

With a filtered shortlist, the selection skill ranks the remaining ideas by criteria you choose. The output is preparation for a human decision, not a replacement for one. The person reviewing the ranking may weigh the criteria differently than the skill did, or may have context the skill did not.

Rank the following shortlisted ideas by the selection criteria below.

Shortlisted ideas:
{{paste the kept ideas from the filter skill}}

Selection criteria and weighting:
- {{Criterion 1}}: {{weight, e.g., 40%}}
- {{Criterion 2}}: {{weight, e.g., 35%}}
- {{Criterion 3}}: {{weight, e.g., 25%}}

For each idea, output:
  Rank | Idea | Score per criterion (High/Medium/Low) | One-sentence summary of fit

End with:
  Top recommendation: [idea] with one-paragraph rationale
  Key trade-off: [what the top recommendation gives up]

Note: This ranking is a tool for discussion, not a final decision.

The "key trade-off" field at the end is important. Every top-ranked idea gives up something. Naming that trade-off explicitly makes the discussion more productive. Instead of debating whether the top idea is right, the team can debate whether the trade-off is acceptable. That is a more specific and answerable question. It also prevents the common outcome where the top-ranked idea is agreed on in the room but quietly abandoned later because the trade-off was never acknowledged.

If the selection skill consistently produces a ranking that does not match the team's instinct, check the criteria and their weights. The weights determine the outcome as much as the ideas do. If a team weights "speed to market" at 40% but the most important constraint is actually budget, the ranking will reflect speed, not the real priority. Adjusting the weights is part of the skill refinement process.

How to do this with fenbs

1. Create a free account and add a project for the initiative this brainstorm belongs to.
2. Add the three skills to Skills and prompts: "Generate ideas", "Filter ideas", "Rank ideas".
3. Connect Claude over MCP from Integrations. Run the skills in sequence, reviewing the output between each step.
4. After the session, record the accepted ideas as tasks and the key rejected options as Decisions and rules with the reason for each rejection.
5. The next time a similar question comes up, ask Claude to read the project decisions before generating. It will skip the already-rejected territory.

For more skill design patterns, see Claude skills examples and how to create a Claude skill. The claude skills marketplace lists ready-made skills you can adapt for your own brainstorming sessions.