mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-02-11 02:33:51 +08:00
docs: clarify brainstorm vs plan workflow and add decision guide
Major improvements to workflow understanding and guidance: 1. New Document: WORKFLOW_DECISION_GUIDE.md - Comprehensive decision flowchart for full software lifecycle - Interactive Mermaid diagram with 40+ decision points - Clear guidance on when to use each command - Real-world scenarios for all workflow types - Quick reference tables by knowledge level, project stage, and mode - Expert tips and common pitfalls 2. Clarified Brainstorm vs Plan Relationship Core concept correction: - Brainstorm: Use when you know WHAT to build, NOT HOW - Plan: Use when you know both WHAT and HOW - Plan can accept user input OR brainstorm output 3. Updated Documentation Files - GETTING_STARTED.md: Added clear distinction and decision criteria - GETTING_STARTED_CN.md: Chinese version with same clarifications - FAQ.md: Enhanced brainstorm usage explanation with workflow comparison table - README.md: Added Workflow Decision Guide link - README_CN.md: Added Chinese link to decision guide 4. Key Improvements When to Use Brainstorming: - Unclear solution approach (multiple ways to solve) - Architectural exploration needed - Requirements clarification (high-level clear, details not) - Multiple trade-offs to analyze - Unfamiliar domain When to Skip Brainstorming: - Clear implementation approach - Similar to existing code patterns - Well-defined requirements - Simple features 5. Decision Flowchart Covers: - Ideation phase (know what to build?) - Design phase (know how to build?) - UI design phase (need UI design?) - Planning phase (complexity level?) - Testing phase (TDD, post-test, test-fix?) - Review phase (security, architecture, quality?) - Completion Benefits: - Eliminates confusion about brainstorm usage - Provides clear decision criteria for all commands - Visual flowchart helps users navigate workflows - Comprehensive coverage of all development stages - Reduces trial-and-error in workflow selection Files modified: 5 Files added: 1 (WORKFLOW_DECISION_GUIDE.md)
This commit is contained in:
@@ -114,7 +114,7 @@ For UI-focused projects, start with design exploration before implementation: **
|
||||
|
||||
### Scenario 3: Complex Feature with Multi-Agent Brainstorming
|
||||
|
||||
For complex features requiring thorough analysis, use the complete workflow: **brainstorm → plan → execute**
|
||||
**Use brainstorming when you know WHAT to build, but don't know HOW to build it.** The complete workflow: **brainstorm → plan → execute**
|
||||
|
||||
```bash
|
||||
# Step 1: Multi-agent brainstorming (auto-creates session)
|
||||
@@ -136,9 +136,16 @@ For complex features requiring thorough analysis, use the complete workflow: **b
|
||||
- **Comprehensive specification**: Generates integrated requirements and design document
|
||||
|
||||
**When to Use Brainstorming**:
|
||||
- Complex features requiring multiple perspectives
|
||||
- Architectural decisions with significant impact
|
||||
- When you need thorough requirements before implementation
|
||||
- **You know WHAT to build, but NOT HOW** - Need to explore solution approaches
|
||||
- **Multiple solution paths exist** - Need expert analysis to choose the best approach
|
||||
- **Unclear technical requirements** - Need to clarify architecture, data models, APIs
|
||||
- **Significant architectural decisions** - Need multi-perspective analysis before committing
|
||||
|
||||
**When to Skip Brainstorming** (use `/workflow:plan` directly):
|
||||
- You already know the implementation approach
|
||||
- Clear technical requirements from the start
|
||||
- Simple, straightforward features
|
||||
- Similar to existing implementations in your codebase
|
||||
|
||||
### Scenario 4: Quality Assurance - Action Plan Verification
|
||||
|
||||
|
||||
Reference in New Issue
Block a user