Collaborative design methodology for creative work. Use before research or planning when requirements are unclear, multiple approaches exist, or the idea needs exploration. Refines ideas through progressive questioning.
/plugin marketplace add bostonaholic/rpikit/plugin install rpikit@rpikitThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Explore ideas collaboratively before committing to an approach.
Jumping from vague ideas to implementation wastes effort. This skill provides structured exploration to refine concepts, surface constraints, and evaluate approaches before committing to research or planning. Good brainstorming prevents building the wrong thing.
Use brainstorming when:
Skip brainstorming when:
Goal: Clarify what the user wants to accomplish.
Ask questions one at a time using AskUserQuestion:
What problem are you solving?
Who is this for?
What does success look like?
What constraints exist?
What have you considered?
Prefer multiple-choice questions when possible. Open-ended is fine for exploration, but specific choices accelerate understanding.
Goal: Present options with trade-offs.
After understanding the idea, present 2-3 approaches:
## Approach A: [Name]
[2-3 sentences describing the approach]
**Pros**: [Key advantages]
**Cons**: [Key disadvantages]
**Best when**: [Situations where this shines]
## Approach B: [Name]
[2-3 sentences describing the approach]
**Pros**: [Key advantages]
**Cons**: [Key disadvantages]
**Best when**: [Situations where this shines]
## Approach C: [Name] (if applicable)
...
## Recommendation
[Which approach and why, based on stated constraints]
Use AskUserQuestion to get user's preference:
Goal: Document the agreed design.
After selecting an approach, document it:
docs/plans/YYYY-MM-DD-<topic>-design.mdDesign document structure:
# Design: <Topic> (YYYY-MM-DD)
## Problem Statement
[What problem this solves]
## Chosen Approach
[Selected approach and rationale]
## Design Details
[Specific design decisions]
## Trade-offs Accepted
[What we're giving up and why it's acceptable]
## Open Questions
[Anything still unresolved]
## Next Steps
- [ ] Research phase (if needed)
- [ ] Planning phase
- [ ] Implementation
Start broad, narrow based on answers:
1. "What are you trying to build?" (broad)
2. "Which users will interact with this?" (narrowing)
3. "What's the most important interaction?" (specific)
Make implicit assumptions explicit:
"I'm assuming this needs to integrate with the existing auth system.
Is that correct?"
When multiple valid choices exist:
"There's a trade-off here:
- Option A is simpler but less flexible
- Option B is more flexible but more complex
Which matters more for this use case?"
When requirements are vague:
"Can you give me an example of what you'd expect to happen
when a user does X?"
You Aren't Gonna Need It.
Ruthlessly apply this during brainstorming:
User: "We should also add support for X in case we need it"
Response: "Let's focus on the core need first. We can add X
later if it becomes necessary. What's the minimum we need now?"
After brainstorming, guide to appropriate next step:
If design is complete and validated:
"Design documented at docs/plans/YYYY-MM-DD-<topic>-design.md
Ready to proceed?"
- "Start research" → /rpikit:research
- "Create implementation plan" → /rpikit:plan
- "Continue brainstorming" → More exploration
If more investigation needed:
"The design needs more context about [topic].
Recommend research phase to investigate before planning."
Brainstorming is an optional pre-phase:
[Brainstorming] → Research → Plan → Implement
^
Optional when requirements unclear
Brainstorming output (design document) feeds into research or planning.
Wrong: "Let's build X using Y framework" Right: "What problem are we solving? Who is it for?"
Wrong: Endless exploration without converging Right: Time-box exploration, make decisions
Wrong: Designing every possible feature Right: YAGNI - minimum viable solution first
Wrong: Designing without considering limitations Right: Surface constraints early, design within them
Wrong: Presenting complete design without validation Right: Incremental presentation with checkpoints
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.