- Removed deprecated `gemini-init.md` command and migrated its functionality to a new structure under `.claude/commands/gemini/`. - Introduced `auto-parallel.md` for parallel brainstorming automation with dynamic role selection and concurrent execution. - Added `auto-squeeze.md` for sequential command coordination in brainstorming workflows, ensuring structured execution from framework generation to synthesis. - Updated `plan.md` to improve clarity on project structure analysis and command execution strategies. - Enhanced error handling and session management across all commands to ensure robustness and user guidance. - Improved documentation for generated files and command options to facilitate user understanding and usage.
15 KiB
Workflow Plan Command
Usage
/workflow:plan <input>
Input Detection
- Files:
.md/.txt/.json/.yaml/.yml→ Reads content and extracts requirements - Issues:
ISS-*,ISSUE-*,*-request-*→ Loads issue data and acceptance criteria - Text: Everything else → Parses natural language requirements
Core Workflow
Analysis & Planning Process
The command performs comprehensive analysis through:
0. Pre-Analysis Documentation Check ⚠️ FIRST STEP
- Selective documentation loading based on task requirements:
- Always check:
.workflow/docs/README.md- System navigation and module index - For architecture tasks:
.workflow/docs/architecture/system-design.md,module-map.md - For specific modules:
.workflow/docs/modules/[relevant-module]/overview.md - For API tasks:
.workflow/docs/api/unified-api.md
- Always check:
- Context-driven selection: Only load documentation relevant to the specific task scope
- Foundation for analysis: Use relevant docs to understand affected components and dependencies
1. Context Gathering & Intelligence Selection
- Reading relevant CLAUDE.md documentation based on task requirements
- Automatic tool assignment based on complexity:
- Simple tasks (≤3 modules): Direct CLI tools with intelligent path navigation and multi-round analysis
# Analyze specific directory cd "src/auth" && ~/.claude/scripts/gemini-wrapper -p " PURPOSE: Analyze authentication patterns TASK: Review auth implementation for security patterns CONTEXT: Focus on JWT handling and user validation EXPECTED: Security assessment and recommendations RULES: Focus on security vulnerabilities and best practices " # Implement in specific directory codex -C src/components --full-auto exec " PURPOSE: Create user profile component TASK: Build responsive profile component with form validation CONTEXT: Use existing component patterns EXPECTED: Complete component with tests RULES: Follow existing component architecture " -s danger-full-access - Complex tasks (>3 modules): Specialized general-purpose with autonomous CLI tool orchestration and cross-module coordination
- Simple tasks (≤3 modules): Direct CLI tools with intelligent path navigation and multi-round analysis
- Flow control integration with automatic tool selection
2. Project Structure Analysis ⚠️ CRITICAL PRE-PLANNING STEP
- Documentation Context First: Reference existing documentation at
.workflow/docs/README.md,.workflow/docs/modules/*/overview.md,.workflow/docs/architecture/*.mdif available - Complexity assessment: Count total saturated tasks
- Decomposition strategy: Flat (≤5) | Hierarchical (6-10) | Re-scope (>10)
- Module boundaries: Identify relationships and dependencies using existing documentation
- File grouping: Cohesive file sets and target_files generation
- Pattern recognition: Existing implementations and conventions
3. Analysis Artifacts Generated
- ANALYSIS_RESULTS.md: Context analysis, codebase structure, pattern identification, task decomposition
- Context mapping: Project structure, dependencies, cohesion groups
- Implementation strategy: Tool selection and execution approach
Implementation Standards
Context Management & Agent Execution
Agent Context Loading ⚠️ CRITICAL The following pre_analysis steps are generated for agent execution:
// Example pre_analysis steps generated by /workflow:plan for agent execution
"flow_control": {
"pre_analysis": [
{
"step": "load_planning_context",
"action": "Load plan-generated analysis and context",
"command": "bash(cat .workflow/WFS-[session]/.process/ANALYSIS_RESULTS.md 2>/dev/null || echo 'planning analysis not found')",
"output_to": "planning_context"
},
{
"step": "mcp_codebase_exploration",
"action": "Explore codebase structure and patterns using MCP tools",
"command": "mcp__code-index__find_files(pattern=\"[focus_paths_pattern]\") && mcp__code-index__search_code_advanced(pattern=\"[context_requirements_pattern]\", file_pattern=\"[target_extensions]\")",
"output_to": "codebase_structure"
},
{
"step": "mcp_external_context",
"action": "Get external API examples and best practices",
"command": "mcp__exa__get_code_context_exa(query=\"[meta_type] [context_requirements]\", tokensNum=\"dynamic\")",
"output_to": "external_context"
},
{
"step": "load_dependencies",
"action": "Retrieve dependency task summaries",
"command": "bash(cat .workflow/WFS-[session]/.summaries/IMPL-[dependency_id]-summary.md 2>/dev/null || echo 'dependency summary not found')",
"output_to": "dependency_context"
},
{
"step": "load_base_documentation",
"action": "Load core documentation files",
"commands": [
"bash(cat .workflow/docs/README.md 2>/dev/null || echo 'Base docs not found')",
"bash(cat CLAUDE.md README.md 2>/dev/null || echo 'Project docs not found')"
],
"output_to": "base_docs"
},
{
"step": "load_task_specific_docs",
"action": "Load documentation relevant to task type",
"commands": [
"bash(cat .workflow/docs/architecture/*.md 2>/dev/null || echo 'Architecture docs not found')",
"bash(cat .workflow/docs/api/*.md 2>/dev/null || echo 'API docs not found')"
],
"output_to": "task_docs"
},
{
"step": "analyze_task_patterns",
"action": "Analyze existing code patterns for task context",
"commands": [
"bash(cd \"[context.focus_paths]\")",
"bash(~/.claude/scripts/gemini-wrapper -p \"PURPOSE: Analyze task patterns for '[title]' TASK: Review existing patterns and dependencies CONTEXT: @{[session.task_json_path]} @{CLAUDE.md} @{[context.focus_paths]/**/*} EXPECTED: Pattern analysis with recommendations RULES: Focus on existing patterns and integration points\")"
],
"output_to": "task_context",
"on_error": "fail"
}
]
}
Context Accumulation Guidelines: Flow_control design should follow these principles:
- Structure Analysis: Project hierarchy and patterns
- Dependency Mapping: Previous task summaries → inheritance context
- Task Context Generation: Combined analysis → task.context fields
- CLI Tool Analysis: Use Gemini/Codex appropriately for pattern analysis when needed
MCP Integration Principles:
- Code Index First: Use
mcp__code-index__for internal codebase exploration before external tools - Exa for Context: Use
mcp__exa__get_code_context_exato supplement with external API patterns and examples - Automatic Fallback: If MCP tools unavailable, workflow uses traditional bash/CLI tools
- Enhanced Analysis: MCP tools provide deeper codebase understanding and external best practices
Benefits of MCP Integration:
- Faster Analysis: Direct codebase indexing vs. manual file searching
- External Context: Real-world API patterns and implementation examples
- Pattern Recognition: Advanced code pattern matching and similarity detection
- Comprehensive Coverage: Both internal code exploration and external best practice lookup
Implementation Approach Planning:
Each task's flow_control.implementation_approach defines execution strategy (planning phase):
-
task_description: Implementation strategy definition:
- Clear implementation goal to be executed later
- Planned reference to patterns from pre_analysis results
- Integration strategy with existing codebase
-
modification_points: Planned code modification targets:
- Specific code changes to be made during execution
- Planned use of parent task patterns via
[parent]context - Integration points with existing components via
[context]from dependencies
-
logic_flow: Business logic execution plan:
- Step-by-step workflow to be implemented
- Planned data flow between components
- Integration points using
[inherited]and[shared]context
-
target_files: Target file specifications for execution:
src/auth/login.ts:handleLogin:75-120(planned function and line range)src/middleware/auth.ts:validateToken(planned function target)- Must align with task's
context.focus_paths
Variable Reference System:
[design]- Results from pre_analysis steps[parent]- Context inherited from parent tasks[context]- Dependencies from related tasks[inherited]- Shared context from session[shared]- Global rules and patterns
Content Sources:
- Task summaries:
.workflow/WFS-[session]/.summaries/ - Documentation:
.workflow/docs/,CLAUDE.md,README.md, config files - Analysis artifacts:
.workflow/WFS-[session]/.process/ANALYSIS_RESULTS.md - Dependency contexts:
.workflow/WFS-[session]/.task/IMPL-*.json
Task Decomposition Standards
Core Principle: Task Merging Over Decomposition
- Merge Rule: Tasks that can be executed together should not be separated - avoid unnecessary decomposition
- Decomposition Criteria: Only decompose tasks in the following situations:
- Excessive Workload: Code exceeds 2500 lines or modifies more than 6 files
- Context Separation: Involves completely different tech stacks or business domains
- Dependency Blocking: Subsequent tasks must wait for prerequisite task completion
- Parallel Execution: Independent features that can be developed simultaneously by different developers
Rules:
- Maximum 10 tasks: Hard limit - exceeding requires re-scoping
- Function-based: Complete functional units with related files (logic + UI + tests + config)
- File cohesion: Group tightly coupled components in same task
- Hierarchy: Flat (≤5 tasks) | Two-level (6-10 tasks) | Re-scope (>10 tasks)
Session Management ⚠️ CRITICAL
- ⚡ FIRST ACTION: Check for all
.workflow/.active-*markers before any planning - Multiple sessions support: Different Claude instances can have different active sessions
- User selection: If multiple active sessions found, prompt user to select which one to work with
- Auto-session creation:
WFS-[topic-slug]only if no active session exists - Session continuity: MUST use selected active session to maintain context
- ⚠️ Dependency context: MUST read ALL previous task summary documents from selected session before planning
- Session isolation: Each session maintains independent context and state
Task Patterns:
- ✅ Correct (Function-based):
IMPL-001: User authentication system(models + routes + components + middleware + tests) - ❌ Wrong (File/step-based):
IMPL-001: Create database model,IMPL-002: Create API endpoint
Document Generation
Workflow: Identifier Creation → Folder Structure → IMPL_PLAN.md → .task/IMPL-NNN.json → TODO_LIST.md
Always Created:
- IMPL_PLAN.md: Requirements, task breakdown, success criteria
- Session state: Task references and paths
Auto-Created (complexity > simple):
- TODO_LIST.md: Hierarchical progress tracking
- .task/*.json: Individual task definitions with flow_control
- .process/ANALYSIS_RESULTS.md: Analysis results and planning artifacts
Document Structure:
.workflow/WFS-[topic]/
├── IMPL_PLAN.md # Main planning document
├── TODO_LIST.md # Progress tracking (if complex)
├── .process/
│ └── ANALYSIS_RESULTS.md # Analysis results and planning artifacts
└── .task/
├── IMPL-001.json # Task definitions with flow_control
└── IMPL-002.json
IMPL_PLAN.md Structure ⚠️ REQUIRED FORMAT
File Header (required):
- Identifier: Unique project identifier and session ID, format WFS-[topic]
- Source: Input type, e.g. "User requirements analysis"
- Analysis: Analysis document reference
Summary (execution overview):
- Concise description of core requirements and objectives
- Technical direction and implementation approach
Context Analysis (context analysis):
- Project - Project type and architectural patterns
- Modules - Involved modules and component list
- Dependencies - Dependency mapping and constraints
- Patterns - Identified code patterns and conventions
Task Breakdown (task decomposition):
- Task Count - Total task count and complexity level
- Hierarchy - Task organization structure (flat/hierarchical)
- Dependencies - Inter-task dependency graph
Implementation Plan (implementation plan):
- Execution Strategy - Execution strategy and methodology
- Resource Requirements - Required resources and tool selection
- Success Criteria - Success criteria and acceptance conditions
Reference Information
Task JSON Schema (5-Field Architecture)
Each task.json uses the standardized 5-field schema (aligned with task-core.md and execute.md):
{
"id": "IMPL-N[.M]",
"title": "Descriptive task name",
"status": "pending|active|completed|blocked|container",
"meta": {
"type": "feature|bugfix|refactor|test|docs",
"agent": "@code-developer|@planning-agent|@code-review-test-agent"
},
"context": {
"requirements": ["requirement1", "requirement2"],
"focus_paths": ["src/path1", "src/path2", "specific_file.ts"],
"acceptance": ["criteria1", "criteria2"],
"parent": "IMPL-N",
"depends_on": ["IMPL-N.M"],
"inherited": {
"from": "parent_task_id",
"context": ["inherited_info"]
},
"shared_context": {
"key": "shared_value"
}
},
"flow_control": {
"pre_analysis": [
{
"step": "step_name",
"action": "description",
"command": "executable_command",
"output_to": "variable_name",
"on_error": "skip_optional|fail|retry_once"
}
],
"implementation_approach": {
"task_description": "detailed implementation strategy",
"modification_points": ["specific changes"],
"logic_flow": ["step by step process"]
},
"target_files": ["file:function:lines"]
}
}
MCP Tools Integration: Enhanced with optional MCP servers for advanced analysis:
- Code Index MCP:
mcp__code-index__find_files(),mcp__code-index__search_code_advanced() - Exa MCP:
mcp__exa__get_code_context_exa()for external patterns
File Structure Reference
Architecture: @~/.claude/workflows/workflow-architecture.md
Execution Integration
Documents created for /workflow:execute:
- IMPL_PLAN.md: Context loading and requirements
- .task/*.json: Agent implementation context
- TODO_LIST.md: Status tracking (container tasks with ▸, leaf tasks with checkboxes)
Error Handling
- Vague input: Auto-reject ("fix it", "make better", etc.)
- File not found: Clear suggestions
- >10 tasks: Force re-scoping into iterations
Planning-Only Constraint
This command creates implementation plans but does not execute them.
Use /workflow:execute for actual implementation.