Brainstorming
@Nefas11
npx machina-cli add skill @Nefas11/brainstorming-2 --openclawBrainstorming Skill
When to Use
Trigger BEFORE writing code when:
- User request is vague ("make it better", "add feature X")
- Complex feature with multiple approaches
- Design decisions impact multiple components
Workflow
Step 1: Understand Intent
Ask clarifying questions:
- What problem are we solving?
- Who is the user?
- What's the success criteria?
- What constraints exist? (time, compatibility, dependencies)
Step 2: Explore Alternatives
Present 2-3 approaches:
- Approach A (simple): [description]
- Approach B (robust): [description]
- Approach C (future-proof): [description]
For each: Pros, Cons, Complexity (1-5)
Step 3: Design Document
After user picks approach, create design doc:
# Feature: [Name]
## Problem
[1-2 sentences]
## Solution
[Chosen approach, 3-5 sentences]
## Components Affected
- [Component 1]: [Change description]
- [Component 2]: [Change description]
## Testing Strategy
- Unit tests: [What to test]
- Integration tests: [What to test]
## Edge Cases
- [Case 1]
- [Case 2]
## Success Criteria
- [ ] [Criterion 1]
- [ ] [Criterion 2]
Save to: docs/design/YYYY-MM-DD-feature-name.md
Step 4: Transition to Planning
Pass design doc to writing-plans skill.
Anti-Patterns
❌ Jump straight to implementation ❌ Present only one approach ❌ Skip edge case discussion ❌ Forget to save design doc
Example
User: "Add caching"
Bad:
I'll add Redis caching to the API.
Good:
Let me understand the requirements first:
1. What should be cached? (API responses, DB queries, computed results?)
2. What's the invalidation strategy? (TTL, event-based, manual?)
3. What's the acceptable staleness? (seconds, minutes, hours?)
Based on your answers, I'll present 3 approaches with trade-offs.
Overview
Brainstorming guides clarifying vague feature requests through a Socratic dialogue before coding. It surfaces 2-3 approaches with trade-offs and culminates in a design document, aligning the team on intent and success criteria.
How This Skill Works
Trigger before writing code when requests are vague or complex. Step 1: Understand Intent with clarifying questions about the problem, user, success criteria, and constraints. Step 2: Explore Alternatives by outlining 2-3 approaches with pros, cons, and estimated complexity. Step 3: Create a Design Document capturing the problem, chosen solution, affected components, testing, edge cases, and success criteria; save to docs/design/YYYY-MM-DD-feature-name.md and transition to planning by handing the doc to the writing-plans skill.
When to Use It
- User request is vague or lacks a clear spec (e.g., 'make it better', 'add feature X').
- A feature is complex with multiple viable approaches.
- Design decisions affect multiple components or modules.
- Before coding, you want explicit decisions and acceptance criteria.
- You need a formal, shareable plan documented before implementation.
Quick Start
- Step 1: Understand Intent — clarify problem, user, success criteria, and constraints.
- Step 2: Explore Alternatives — present 2-3 approaches with pros/cons and complexity.
- Step 3: Design Document — document problem, chosen solution, affected components, tests, edge cases, and save to docs/design/YYYY-MM-DD-feature-name.md; transition to planning.
Best Practices
- Ask clarifying questions to uncover intent, user, constraints, and success criteria.
- Present 2-3 distinct approaches with pros, cons, and estimated complexity.
- Explicitly define success criteria in the design document.
- Document the decision and rationale in a saved design doc at docs/design/YYYY-MM-DD-feature-name.md.
- Only transition to planning after the user selects an approach.
Example Use Cases
- User requests 'Add caching' — pause to clarify what to cache, invalidation, and staleness, then propose 3 approaches with trade-offs.
- Feature touches API, UI, and data models — outline changes for each component before coding.
- Before building a new workflow, draft a design doc outlining problem, solution, tests, and edge cases.
- Edge cases are planned in the design doc to avoid post-implementation gaps.
- Save the design doc to docs/design/YYYY-MM-DD-feature-name.md and hand it to the planning stage.
