Interactive design refinement using Socratic method
Facilitates collaborative design refinement through structured Socratic questioning and iterative validation.
/plugin marketplace add pproenca/dot-claude/plugin install dev-workflow@pproencatopic or @design-doc.mdRefine this idea into a design through collaborative dialogue.
$ARGUMENTS
If empty or no arguments: Use AskUserQuestion to ask what the user wants to brainstorm.
Check project state first:
ls -la
git log --oneline -5 2>/dev/null || true
If $ARGUMENTS references a file (@...), read it.
Ask questions one at a time using AskUserQuestion:
Use structured options (2-4 per question):
AskUserQuestion:
header: "Scope"
question: "What is the primary goal?"
multiSelect: false
options:
- label: "Option A"
description: "Trade-off explanation"
- label: "Option B"
description: "Trade-off explanation"
Reserve open-ended questions for truly exploratory topics.
Propose 2-3 approaches with trade-offs.
Use AskUserQuestion to present options:
AskUserQuestion:
header: "Approach"
question: "Which direction?"
multiSelect: false
options:
- label: "[Recommended approach]"
description: "Key benefit and trade-off"
- label: "[Alternative approach]"
description: "Key benefit and trade-off"
Lead with recommended option.
Once requirements are clear:
Write to docs/plans/YYYY-MM-DD-<topic>-design.md
Commit: git add -A && git commit -m "docs: <topic> design"
Use AskUserQuestion:
AskUserQuestion:
header: "Next"
question: "Design saved. What next?"
multiSelect: false
options:
- label: "Create plan"
description: "Use /dev-workflow:write-plan to create detailed implementation plan"
- label: "Keep exploring"
description: "Continue refining the design"
- label: "Done"
description: "End session, design is complete"
If "Create plan" selected:
/dev-workflow:write-plan @docs/plans/[design-file].md
This invokes the write-plan command with the design document as context.
Before saving, verify the design does NOT include:
| Red Flag | Action |
|---|---|
| "For future extensibility" | Remove - solve today's problem |
| Abstract classes with 1 implementation | Simplify to concrete |
| Plugin/hook systems without plugins | Remove until needed |
| More than 3 new files per feature | Consolidate |
These will be enforced by code-architect during planning, but catching early saves iteration.
/brainstormYou MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores requirements and design before implementation.
/brainstormUse when creating or developing, before writing code or implementation plans - refines rough ideas into fully-formed designs through collaborative questioning, alternative exploration, and incremental validation. Don't use during clear 'mechanical' processes