brainstorming
npx machina-cli add skill a5c-ai/babysitter/brainstorming --openclawBrainstorming Ideas Into Designs
Overview
Collaborative design refinement through Socratic dialogue. Explore project context, ask clarifying questions one at a time, propose 2-3 approaches, present design in sections for incremental approval, then transition to planning.
Core principle: No implementation until design is approved. Every project goes through this.
When to Use
- Before ANY creative or implementation work
- New features, components, modifications
- Even "simple" projects (unexamined assumptions cause wasted work)
Process
- Explore project context - files, docs, recent commits
- Ask clarifying questions - one at a time, prefer multiple choice
- Propose 2-3 approaches - with tradeoffs and recommendation
- Present design in sections - get approval after each section
- Write design doc - save to
docs/plans/YYYY-MM-DD-<topic>-design.md - Transition to writing-plans - the ONLY next step
HARD GATE
Do NOT invoke any implementation, write any code, or take action until design is approved.
Key Principles
- One question at a time
- YAGNI ruthlessly
- Incremental validation
- Scale sections to complexity
Agents Used
agents/code-reviewer/- For design document review- Process agents defined in
brainstorming.js
Tool Use
Invoke via babysitter process: methodologies/superpowers/brainstorming
Source
git clone https://github.com/a5c-ai/babysitter/blob/main/plugins/babysitter/skills/babysit/process/methodologies/superpowers/skills/brainstorming/SKILL.mdView on GitHub Overview
Brainstorming is a collaborative design refinement process that uses Socratic dialogue to explore project context, clarify questions one at a time, and propose 2-3 approaches with a sectioned design for incremental approval. It enforces a design-first flow with a hard gate: no implementation until the design is approved.
How This Skill Works
Start by exploring project context (files, docs, recent commits) and asking clarifying questions one at a time. Then propose 2-3 approaches with tradeoffs and a recommended option, presenting the design in sections for incremental approval. Once the sections are approved, write the formal design doc saved to docs/plans/YYYY-MM-DD-<topic>-design.md and transition to planning; do not implement anything until the hard gate is lifted.
When to Use It
- Before ANY creative or implementation work
- For new features or components
- When modifying behavior or functionality
- For designing or refactoring projects that seem simple but risk hidden assumptions
- When starting any project to avoid wasted work from unexamined assumptions
Quick Start
- Step 1: Explore project context (files, docs, recent commits)
- Step 2: Ask clarifying questions one at a time (prefer multiple choice)
- Step 3: Propose 2-3 approaches with tradeoffs and a recommended design
Best Practices
- Ask one clarifying question at a time, preferring multiple choice
- Propose 2-3 design approaches with clear tradeoffs and a recommended option
- Present the design in sections and secure approval after each section
- Write and save a formal design doc at docs/plans/YYYY-MM-DD-<topic>-design.md
- Enforce the hard gate: no coding or implementation until design is approved
Example Use Cases
- Designing a new user onboarding flow for a SaaS product
- Planning a modular feature set for a mobile app
- Refactoring a legacy module with staged approvals to minimize risk
- Designing a feature toggle system with tradeoffs for performance and safety
- Mapping out a redesigned login and security flow
