Socratic design refinement - transforms rough ideas into validated designs through structured questioning, alternative exploration, and incremental validation.
Inherits all available tools
Additional assets for this skill
This skill inherits all available tools. When active, it can use any tool Claude has access to.
name: brainstorming description: | Socratic design refinement - transforms rough ideas into validated designs through structured questioning, alternative exploration, and incremental validation.
trigger: |
skip_when: |
sequence: before: [writing-plans, using-git-worktrees]
Transform rough ideas into fully-formed designs through structured questioning and alternative exploration.
Core principle: Research first, ask targeted questions to fill gaps, explore alternatives, present design incrementally for validation.
Announce at start: "I'm using the brainstorming skill to refine your idea into a design."
| Phase | Key Activities | Tool Usage | Output |
|---|---|---|---|
| Prep: Autonomous Recon | Inspect repo/docs/commits, form initial model | Native tools (ls, cat, git log, etc.) | Draft understanding to confirm |
| 1. Understanding | Share findings, ask only for missing context | AskUserQuestion for real decisions | Purpose, constraints, criteria (confirmed) |
| 2. Exploration | Propose 2-3 approaches | AskUserQuestion for approach selection | Architecture options with trade-offs |
| 3. Design Presentation | Present in 200-300 word sections | Open-ended questions | Complete design with validation |
| 4. Design Documentation | Write design document | writing-clearly-and-concisely skill | Design doc in docs/plans/ |
| 5. Worktree Setup | Set up isolated workspace | using-git-worktrees skill | Ready development environment |
| 6. Planning Handoff | Create implementation plan | writing-plans skill | Detailed task breakdown |
Copy this checklist to track progress:
Brainstorming Progress:
- [ ] Prep: Autonomous Recon (repo/docs/commits reviewed, initial model shared)
- [ ] Phase 1: Understanding (purpose, constraints, criteria gathered)
- [ ] Phase 2: Exploration (2-3 approaches proposed and evaluated)
- [ ] Phase 3: Design Presentation (design validated in sections)
- [ ] Phase 4: Design Documentation (design written to docs/plans/)
- [ ] Phase 5: Worktree Setup (if implementing)
- [ ] Phase 6: Planning Handoff (if implementing)
MANDATORY evidence (paste ALL): ls -la, git log --oneline -10, head -50 README.md, find . -name "*test*" | wc -l, check package.json/requirements.txt/go.mod.
Only after ALL evidence pasted: Form your model and share findings. Skip any = not following skill.
Maximum 3 questions per phase. More = insufficient research.
Question count:
Hit limit? Do research instead of asking.
Example summary + targeted question:
Based on the README and yesterday's commit, we're expanding localization to dashboard and billing emails; admin console is still untouched. Only gap I see is whether support responses need localization in this iteration. Did I miss anything important?
CRITICAL: Once you enter a phase, you CANNOT skip ahead.
Violations:
WAIT means WAIT. No assumptions.
Example using AskUserQuestion:
Question: "Which architectural approach should we use?"
Options:
- "Direct API calls with retry logic" (simple, synchronous, easier to debug) ← recommended for current scope
- "Event-driven with message queue" (scalable, complex setup, eventual consistency)
- "Hybrid with background jobs" (balanced, moderate complexity, best of both)
I recommend the direct API approach because it matches existing patterns and minimizes new infrastructure. Let me know if you see a blocker that pushes us toward the other options.
Design Acceptance Gate:
Design is NOT approved until human EXPLICITLY says one of:
These do NOT mean approval:
No explicit approval = keep refining
After validating the design, write it to a permanent document:
docs/plans/YYYY-MM-DD-<topic>-design.md (use actual date and descriptive topic)When design is approved and implementation will follow:
Ask: "Ready to create the implementation plan?"
When your human partner confirms (any affirmative response):
Use AskUserQuestion when:
Best practices:
Use open-ended questions for:
Frame them to confirm or expand your current understanding rather than reopening settled topics.
Example decision flow:
| Trigger | Action |
|---|---|
| New constraint revealed | → Return to Phase 1 |
| Partner questions approach | → Return to Phase 2 |
| Requirements unclear | → Return to Phase 1 |
| Something doesn't make sense | → Go back and clarify |
Avoid forcing forward linearly when going backward would give better results.
This skill uses these universal patterns:
skills/shared-patterns/state-tracking.mdskills/shared-patterns/failure-recovery.mdskills/shared-patterns/exit-criteria.mdskills/shared-patterns/todowrite-integration.mdApply ALL patterns when using this skill.
| Principle | Application |
|---|---|
| One question at a time | Phase 1: Single targeted question only for gaps you can’t close yourself |
| Structured choices | Use AskUserQuestion tool for 2-4 options with trade-offs |
| YAGNI ruthlessly | Remove unnecessary features from all designs |
| Explore alternatives | Always propose 2-3 approaches before settling |
| Incremental validation | Present design in sections, validate each |
| Flexible progression | Go backward when needed - flexibility > rigidity |
| Own the initiative | Recommend priorities and next steps; ask if you should proceed only when requirements conflict |
| Announce usage | State skill usage at start of session |