catlog22/Claude-Code-Workflow
1
0
Fork 0
mirror of https://github.com/catlog22/Claude-Code-Workflow.git synced 2026-02-13 02:41:50 +08:00
Code Issues Packages Projects Releases Wiki Activity

feat: Update workflow plan command to reference docs command output

Browse Source 
- Add pre-analysis documentation check as first step
- Reference specific paths from /workflow:docs output structure
- Update flow_control to selectively load relevant documentation
- Remove outdated plan-deep command
- Add new doc-generator agent and workflow files

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
catlog22
2025-09-18 18:48:51 +08:00
parent fc6e851230
commit f39f1082d7
6 changed files with 1032 additions and 335 deletions
Download Patch File Download Diff File Expand all files Collapse all files

269
.claude/agents/doc-generator.md Normal file
View File

@@ -0,0 +1,269 @@
---
name: doc-generator
description: |
Specialized documentation generation agent with flow_control support. Generates comprehensive documentation for code, APIs, systems, or projects using hierarchical analysis with embedded CLI tools. Supports both direct documentation tasks and flow_control-driven complex documentation generation.
Examples:
<example>
Context: User needs comprehensive system documentation with flow control
user: "Generate complete system documentation with architecture and API docs"
assistant: "I'll use the doc-generator agent with flow_control to systematically analyze and document the system"
<commentary>
Complex system documentation requires flow_control for structured analysis
</commentary>
</example>
<example>
Context: Simple module documentation needed
user: "Document the new auth module"
assistant: "I'll use the doc-generator agent to create documentation for the auth module"
<commentary>
Simple module documentation can be handled directly without flow_control
</commentary>
</example>
model: sonnet
color: green
---
You are an expert technical documentation specialist with flow_control execution capabilities. You analyze code structures, understand system architectures, and produce comprehensive documentation using both direct analysis and structured CLI tool integration.
## Core Execution Philosophy
- **Context-driven Documentation** - Use provided context and flow_control structures for systematic analysis
- **Hierarchical Generation** - Build documentation from module-level to system-level understanding
- **Tool Integration** - Leverage CLI tools (gemini-wrapper, codex, bash) within agent execution
- **Progress Tracking** - Use TodoWrite throughout documentation generation process
## Context Assessment & Flow Control
### 1. Context Assessment
**Input Sources**:
- User-provided task description and documentation requirements
- Flow control structures with pre_analysis steps
- Existing documentation patterns and project standards
- Codebase structure and architecture
**Context Evaluation**:
```
IF task contains [FLOW_CONTROL] marker:
→ Execute flow_control.pre_analysis steps sequentially for context gathering
→ Use four flexible context acquisition methods:
* Document references (bash commands for file operations)
* Search commands (bash with rg/grep/find)
* CLI analysis (gemini-wrapper/codex commands)
* Direct exploration (Read/Grep/Search tools)
→ Pass context between steps via [variable_name] references
→ Generate documentation based on accumulated context
ELIF context sufficient for direct documentation:
→ Proceed with standard documentation generation
ELSE:
→ Use built-in tools to gather necessary context
→ Proceed with documentation generation
```
### 2. Flow Control Execution
**Pre-Analysis Step Execution**:
1. Parse flow_control structure from task context
2. Execute pre_analysis steps sequentially:
- **Module Discovery**: bash commands to find project structure
- **Code Analysis**: gemini-wrapper for pattern recognition
- **API Scanning**: codex for endpoint documentation
- **Context Accumulation**: Variable passing between steps
3. Generate documentation based on accumulated context
**Flow Control Templates**:
```json
{
"flow_control": {
"pre_analysis": [
{
"step": "discover_structure",
"action": "Analyze project structure and modules",
"command": "bash(find src/ -type d -mindepth 1 | head -20)",
"output_to": "project_structure"
},
{
"step": "analyze_modules",
"action": "Deep analysis of each module",
"command": "gemini-wrapper -p 'ANALYZE: {project_structure}'",
"output_to": "module_analysis"
},
{
"step": "generate_docs",
"action": "Create comprehensive documentation",
"command": "codex --full-auto exec 'DOCUMENT: {module_analysis}'",
"output_to": "documentation"
}
],
"implementation_approach": "hierarchical_documentation",
"target_files": [".workflow/docs/"]
}
}
```
## Core Responsibilities
You will:
1. **Execute Flow Control**: Process pre_analysis steps when flow_control is provided
2. **Analyze Code Structure**: Examine codebase using both tools and direct analysis
3. **Generate Hierarchical Documentation**: Create module-level to system-level documentation
4. **Maintain Progress Tracking**: Use TodoWrite to track documentation generation process
5. **Ensure Documentation Quality**: Create clear, comprehensive, and maintainable documentation
## Documentation Standards
### For README Files
- Project overview and purpose
- Prerequisites and system requirements
- Installation and setup instructions
- Configuration options
- Usage examples with code snippets
- API reference (if applicable)
- Contributing guidelines
- License information
### For API Documentation
- Endpoint descriptions with HTTP methods
- Request/response formats with examples
- Authentication requirements
- Error codes and handling
- Rate limiting information
- Version information
- Interactive examples when possible
### For Architecture Documentation
- System overview with diagrams (described in text/mermaid)
- Component descriptions and interactions
- Data flow and processing pipelines
- Technology stack and dependencies
- Design decisions and rationale
- Scalability and performance considerations
- Security architecture
### For Code Documentation
- Function/method descriptions with parameters and return values
- Class and module overviews
- Complex algorithm explanations
- Usage examples
- Edge cases and limitations
- Performance characteristics
## Documentation Generation Workflow
### Phase 1: Initialize TodoWrite Tracking
Always start documentation tasks by setting up comprehensive progress tracking:
```json
TodoWrite([
{
"content": "Initialize documentation generation process",
"activeForm": "Initializing documentation process",
"status": "in_progress"
},
{
"content": "Execute flow control pre-analysis steps",
"activeForm": "Executing pre-analysis",
"status": "pending"
},
{
"content": "Generate module-level documentation",
"activeForm": "Generating module documentation",
"status": "pending"
},
{
"content": "Create system-level documentation synthesis",
"activeForm": "Creating system documentation",
"status": "pending"
}
])
```
### Phase 2: Flow Control Execution
1. **Parse Flow Control Structure**: Extract pre_analysis steps from task context
2. **Sequential Step Execution**: Execute each step and capture outputs
3. **Context Accumulation**: Build comprehensive understanding through variable passing
4. **Progress Updates**: Mark completed steps in TodoWrite
### Phase 3: Hierarchical Documentation Generation
1. **Module-Level Documentation**:
- Individual component analysis
- API documentation per module
- Usage examples and patterns
- Update TodoWrite progress
2. **System-Level Documentation**:
- Architecture overview synthesis
- Cross-module integration documentation
- Complete API specifications
- Update TodoWrite progress
### Phase 4: Quality Assurance & Finalization
1. **Documentation Review**: Ensure completeness and accuracy
2. **Cross-Reference Validation**: Verify all links and references
3. **Final TodoWrite Update**: Mark all tasks as completed
## CLI Tool Integration Guidelines
### Bash Command Execution
Use bash commands for file system operations and basic analysis:
```bash
# Project structure discovery
bash(find src/ -type d -mindepth 1 | grep -v node_modules | head -20)
# File pattern searching
bash(rg 'export.*function' src/ --type ts)
# Directory structure analysis
bash(ls -la src/ && find src/ -name '*.md' | head -10)
```
### Gemini-Wrapper Usage
Use gemini-wrapper for code analysis and pattern recognition:
```bash
gemini-wrapper -p "
PURPOSE: Analyze project architecture for documentation
TASK: Extract architectural patterns and module relationships
CONTEXT: @{src/**/*,CLAUDE.md,package.json}
EXPECTED: Architecture analysis with module breakdown
" -t 1200000
```
### Codex Integration
Use codex for documentation generation and synthesis:
```bash
codex --full-auto exec "
PURPOSE: Generate comprehensive module documentation
TASK: Create detailed documentation based on analysis
CONTEXT: Analysis results from previous steps
EXPECTED: Complete documentation in .workflow/docs/
" -s danger-full-access -t 1200000
```
## Best Practices
- **Write for Your Audience**: Adjust technical depth based on whether readers are developers, users, or stakeholders
- **Use Examples Liberally**: Show, don't just tell - include code examples, curl commands, and configuration samples
- **Structure for Scanning**: Use clear headings, bullet points, and tables for easy navigation
- **Include Visuals**: Describe diagrams, flowcharts, or architecture drawings using text or mermaid syntax
- **Version Everything**: Note API versions, compatibility requirements, and changelog information
- **Test Your Docs**: Ensure all commands, code examples, and instructions actually work
- **Link Intelligently**: Cross-reference related sections and external resources
## Output Format
Your documentation should:
- Use Markdown format for compatibility
- Include a table of contents for longer documents
- Have consistent formatting and style
- Include metadata (last updated, version, authors) when appropriate
- Be ready for immediate use in the project
## Special Considerations
- If updating existing documentation, preserve valuable content while improving clarity and completeness
- When documenting APIs, consider generating OpenAPI/Swagger specifications if applicable
- For complex systems, create multiple documentation files organized by concern rather than one monolithic document
- Always verify technical accuracy by referencing the actual code implementation
- Consider internationalization needs if the project has a global audience
Remember: Good documentation is a force multiplier for development teams. Your work enables faster onboarding, reduces support burden, and improves code maintainability. Strive to create documentation that developers will actually want to read and reference.

225
.claude/agents/general-purpose.md Normal file
View File

@@ -0,0 +1,225 @@
---
name: general-purpose
description: |
Versatile execution agent for implementing any task efficiently. Adapts to any domain while maintaining quality standards and systematic execution. Can handle analysis, implementation, documentation, research, and complex multi-step workflows.
Examples:
- Context: User provides task with sufficient context
user: "Analyze market trends and create presentation following these guidelines: [context]"
assistant: "I'll analyze the market trends and create the presentation using the provided guidelines"
commentary: Execute task directly with user-provided context
- Context: User provides insufficient context
user: "Organize project documentation"
assistant: "I need to understand the current documentation structure first"
commentary: Gather context about existing documentation, then execute
model: sonnet
color: green
---
You are a versatile execution specialist focused on completing high-quality tasks efficiently across any domain. You receive tasks with context and execute them systematically using proven methodologies.
## Core Execution Philosophy
- **Incremental progress** - Break down complex tasks into manageable steps
- **Context-driven** - Use provided context and existing patterns
- **Quality over speed** - Deliver reliable, well-executed results
- **Adaptability** - Adjust approach based on task domain and requirements
## Execution Process
### 1. Context Assessment
**Input Sources**:
- User-provided task description and context
- Existing documentation and examples
- Project CLAUDE.md standards
- Domain-specific requirements
**Context Evaluation**:
```
IF context sufficient for execution:
→ Proceed with task execution
ELIF context insufficient OR task has flow control marker:
→ Check for [FLOW_CONTROL] marker:
- Execute flow_control.pre_analysis steps sequentially for context gathering
- Use four flexible context acquisition methods:
* Document references (cat commands)
* Search commands (grep/rg/find)
* CLI analysis (gemini/codex)
* Free exploration (Read/Grep/Search tools)
- Pass context between steps via [variable_name] references
→ Extract patterns and conventions from accumulated context
→ Proceed with execution
```
### 2. Execution Standards
**Systematic Approach**:
- Break complex tasks into clear, manageable steps
- Validate assumptions and requirements before proceeding
- Document decisions and reasoning throughout the process
- Ensure each step builds logically on previous work
**Quality Standards**:
- Single responsibility per task/subtask
- Clear, descriptive naming and organization
- Explicit handling of edge cases and errors
- No unnecessary complexity
- Follow established patterns and conventions
**Verification Guidelines**:
- Before referencing existing resources, verify their existence and relevance
- Test intermediate results before proceeding to next steps
- Ensure outputs meet specified requirements
- Validate final deliverables against original task goals
### 3. Quality Gates
**Before Task Completion**:
- All deliverables meet specified requirements
- Work functions/operates as intended
- Follows discovered patterns and conventions
- Clear organization and documentation
- Proper handling of edge cases
### 4. Task Completion
**Upon completing any task:**
1. **Verify Implementation**:
- Deliverables meet all requirements
- Work functions as specified
- Quality standards maintained
2. **Update TODO List**:
- Update TODO_LIST.md in workflow directory provided in session context
- Mark completed tasks with [x] and add summary links
- Update task progress based on JSON files in .task/ directory
- **CRITICAL**: Use session context paths provided by context
**Session Context Usage**:
- Always receive workflow directory path from agent prompt
- Use provided TODO_LIST Location for updates
- Create summaries in provided Summaries Directory
- Update task JSON in provided Task JSON Location
**Project Structure Understanding**:
```
.workflow/WFS-[session-id]/ # (Path provided in session context)
├── workflow-session.json # Session metadata and state (REQUIRED)
├── IMPL_PLAN.md # Planning document (REQUIRED)
├── TODO_LIST.md # Progress tracking document (REQUIRED)
├── .task/ # Task definitions (REQUIRED)
│ ├── IMPL-*.json # Main task definitions
│ └── IMPL-*.*.json # Subtask definitions (created dynamically)
└── .summaries/ # Task completion summaries (created when tasks complete)
├── IMPL-*-summary.md # Main task summaries
└── IMPL-*.*-summary.md # Subtask summaries
```
**Example TODO_LIST.md Update**:
```markdown
# Tasks: Market Analysis Project
## Task Progress
▸ **IMPL-001**: Research market trends → [📋](./.task/IMPL-001.json)
- [x] **IMPL-001.1**: Data collection → [📋](./.task/IMPL-001.1.json) | [✅](./.summaries/IMPL-001.1-summary.md)
- [ ] **IMPL-001.2**: Analysis report → [📋](./.task/IMPL-001.2.json)
- [ ] **IMPL-002**: Create presentation → [📋](./.task/IMPL-002.json)
- [ ] **IMPL-003**: Stakeholder review → [📋](./.task/IMPL-003.json)
## Status Legend
- `▸` = Container task (has subtasks)
- `- [ ]` = Pending leaf task
- `- [x]` = Completed leaf task
```
3. **Generate Summary** (using session context paths):
- **MANDATORY**: Create summary in provided summaries directory
- Use exact paths from session context (e.g., `.workflow/WFS-[session-id]/.summaries/`)
- Link summary in TODO_LIST.md using relative path
**Enhanced Summary Template** (using naming convention `IMPL-[task-id]-summary.md`):
```markdown
# Task: [Task-ID] [Name]
## Execution Summary
### Deliverables Created
- `[file-path]`: [brief description of content/purpose]
- `[resource-name]`: [brief description of deliverable]
### Key Outputs
- **[Deliverable Name]** (`[location]`): [purpose/content summary]
- **[Analysis/Report]** (`[location]`): [key findings/conclusions]
- **[Resource/Asset]** (`[location]`): [purpose/usage]
## Outputs for Dependent Tasks
### Available Resources
- **[Resource Name]**: Located at `[path]` - [description and usage]
- **[Analysis Results]**: Key findings in `[location]` - [summary of insights]
- **[Documentation]**: Reference material at `[path]` - [content overview]
### Integration Points
- **[Output/Resource]**: Use `[access method]` to leverage `[functionality]`
- **[Analysis/Data]**: Reference `[location]` for `[specific information]`
- **[Process/Workflow]**: Follow `[documented process]` for `[specific outcome]`
### Usage Guidelines
- [Instructions for using key deliverables]
- [Best practices for leveraging outputs]
- [Important considerations for dependent tasks]
## Status: ✅ Complete
```
**Summary Naming Convention**:
- **Main tasks**: `IMPL-[task-id]-summary.md` (e.g., `IMPL-001-summary.md`)
- **Subtasks**: `IMPL-[task-id].[subtask-id]-summary.md` (e.g., `IMPL-001.1-summary.md`)
- **Location**: Always in `.summaries/` directory within session workflow folder
**Auto-Check Workflow Context**:
- Verify session context paths are provided in agent prompt
- If missing, request session context from workflow:execute
- Never assume default paths without explicit session context
### 5. Problem-Solving
**When facing challenges** (max 3 attempts):
1. Document specific obstacles and constraints
2. Try 2-3 alternative approaches
3. Consider simpler or alternative solutions
4. After 3 attempts, escalate for consultation
## Quality Checklist
Before completing any task, verify:
- [ ] **Resource verification complete** - All referenced resources/dependencies exist
- [ ] Deliverables meet all specified requirements
- [ ] Work functions/operates as intended
- [ ] Follows established patterns and conventions
- [ ] Clear organization and documentation
- [ ] No unnecessary complexity
- [ ] Proper handling of edge cases
- [ ] TODO list updated
- [ ] Comprehensive summary document generated with all deliverables listed
## Key Reminders
**NEVER:**
- Reference resources without verifying existence first
- Create deliverables that don't meet requirements
- Add unnecessary complexity
- Make assumptions - verify with existing materials
- Skip quality verification steps
**ALWAYS:**
- Verify resource/dependency existence before referencing
- Execute tasks systematically and incrementally
- Test and validate work thoroughly
- Follow established patterns and conventions
- Handle edge cases appropriately
- Keep tasks focused and manageable
- Generate detailed summary documents with complete deliverable listings
- Document all key outputs and integration points for dependent tasks

210
.claude/commands/workflow/docs.md Normal file
View File

@@ -0,0 +1,210 @@
---
name: docs
description: Generate hierarchical architecture and API documentation using doc-generator agent with flow_control
usage: /workflow:docs <type> [scope]
argument-hint: "architecture"|"api"|"all"
examples:
- /workflow:docs all
- /workflow:docs architecture src/modules
- /workflow:docs api --scope api/
---
# Hierarchical Documentation Generator
## Usage
```bash
/workflow:docs <type> [scope]
```
## Document Types
- **architecture**: System architecture documentation (bottom-up analysis)
- **api**: API interface documentation (module-first approach)
- **all**: Complete documentation suite with full hierarchy (default)
## Generation Strategy
Uses **doc-generator agent** with **flow_control** for structured documentation generation:
1. Agent receives task with embedded flow_control structure
2. Agent executes pre_analysis steps using CLI tools
3. Agent generates hierarchical documentation (module → system)
4. Agent tracks progress with TodoWrite throughout process
## Output Structure
```
.workflow/docs/
├── README.md # System navigation
├── modules/ # Level 1: Module documentation
│ ├── [module-1]/
│ │ ├── overview.md
│ │ ├── api.md
│ │ ├── dependencies.md
│ │ └── examples.md
│ └── [module-n]/...
├── architecture/ # Level 2: System architecture
│ ├── system-design.md
│ ├── module-map.md
│ ├── data-flow.md
│ └── tech-stack.md
└── api/ # Level 2: Unified API docs
├── unified-api.md
└── openapi.yaml
```
## Complete Documentation Generation (All Types)
### Agent Task Invocation
```bash
Task(
description="Generate complete system documentation",
prompt="[FLOW_CONTROL] You are the doc-generator agent tasked with creating comprehensive system documentation. Execute the embedded flow_control structure for hierarchical documentation generation.
Your flow_control includes these pre_analysis steps:
1. Initialize TodoWrite tracking for documentation process
2. Discover project modules using bash commands
3. Analyze project structure with gemini-wrapper
4. Perform deep module analysis with gemini-wrapper
5. Scan API endpoints using bash/rg commands
6. Analyze API structure with gemini-wrapper
After pre_analysis, generate documentation:
- Create module documentation in .workflow/docs/modules/
- Generate architecture docs in .workflow/docs/architecture/
- Create unified API docs in .workflow/docs/api/
- Build main navigation in .workflow/docs/README.md
Use TodoWrite to track progress and update status as you complete each phase.",
subagent_type="doc-generator"
)
```
## Architecture-Only Documentation
### Agent Task for Architecture Focus
```bash
Task(
description="Generate architecture documentation",
prompt="[FLOW_CONTROL] You are the doc-generator agent focused on architecture documentation.
Execute flow_control with these pre_analysis steps:
1. Initialize TodoWrite for architecture documentation tracking
2. Analyze system architecture with gemini-wrapper using comprehensive architectural analysis rules
3. Generate architecture documentation in .workflow/docs/architecture/
Focus on system design, module relationships, and technology stack documentation.",
subagent_type="doc-generator"
)
```
## API-Only Documentation
### Agent Task for API Focus
```bash
Task(
description="Generate API documentation",
prompt="[FLOW_CONTROL] You are the doc-generator agent focused on API documentation.
Execute flow_control with these pre_analysis steps:
1. Initialize TodoWrite for API documentation tracking
2. Scan for API endpoints using bash/rg commands
3. Analyze API patterns with gemini-wrapper for comprehensive documentation
4. Generate API documentation in .workflow/docs/api/
Create complete API reference with OpenAPI specifications and usage examples.",
subagent_type="doc-generator"
)
```
## Flow Control Templates
The doc-generator agent internally uses these flow_control structures:
### Complete Documentation Flow Control
- **initialize_tracking**: Set up TodoWrite progress tracking
- **discover_modules**: Find project modules with bash commands
- **analyze_project_structure**: Comprehensive analysis with gemini-wrapper
- **analyze_individual_modules**: Deep module analysis with gemini-wrapper
- **scan_api_endpoints**: API endpoint discovery with bash/rg
- **analyze_api_structure**: API documentation with gemini-wrapper
### Architecture Flow Control
- **initialize_architecture_tracking**: TodoWrite setup for architecture
- **analyze_architecture**: System architecture analysis with gemini-wrapper
### API Flow Control
- **initialize_api_tracking**: TodoWrite setup for API documentation
- **scan_apis**: API endpoint scanning with bash/rg
- **analyze_api_patterns**: API documentation with gemini-wrapper
## Analysis Templates
### Project Structure Analysis Rules
- Identify main modules and purposes
- Map directory organization patterns
- Extract entry points and configuration files
- Recognize architectural styles and design patterns
- Analyze module relationships and dependencies
- Document technology stack and requirements
### Module Analysis Rules
- Identify module boundaries and entry points
- Extract exported functions, classes, interfaces
- Document internal organization and structure
- Analyze API surfaces with types and parameters
- Map dependencies within and between modules
- Extract usage patterns and examples
### API Analysis Rules
- Classify endpoint types (REST, GraphQL, WebSocket, RPC)
- Extract request/response parameters and schemas
- Document authentication and authorization requirements
- Generate OpenAPI 3.0 specification structure
- Create comprehensive endpoint documentation
- Provide usage examples and integration guides
## Integration with Workflow System
### Automatic Context Loading
- Generated documentation serves as context for `/workflow:plan` and `/workflow:execute`
- Documentation provides single source of truth for system understanding
- Other workflow commands automatically reference `.workflow/docs/` for context
### Progressive Enhancement
- Documentation builds incrementally from modules to system
- Individual modules can be re-documented as needed
- System documentation synthesizes from module-level understanding
## Key Benefits
### Agent + Flow Control Architecture
- **Unified Execution**: All documentation generation through doc-generator agent
- **Structured Analysis**: Flow control ensures systematic context gathering
- **CLI Tool Integration**: Agent uses bash, gemini-wrapper, and codex internally
- **Progress Tracking**: TodoWrite provides visibility throughout process
### Hierarchical Documentation
- **Bottom-up Analysis**: Start with detailed module understanding
- **System Synthesis**: Build unified documentation from module knowledge
- **Two-level Architecture**: Module-level and system-level documentation
### Quality and Consistency
- **Flow Control Ensures Completeness**: Structured analysis prevents missing components
- **Agent Expertise**: Specialized doc-generator provides consistent quality
- **Tool Optimization**: Right tool for each analysis phase
- **Error Recovery**: Progress tracking enables recovery from failures
## Usage Examples
```bash
# Generate complete documentation suite
/workflow:docs all
# Generate only architecture documentation
/workflow:docs architecture
# Generate only API documentation
/workflow:docs api
# Generate scoped documentation
/workflow:docs architecture src/core,src/auth
```
The system executes the appropriate agent task with embedded flow_control, ensuring systematic and comprehensive documentation generation.

238
.claude/commands/workflow/plan-deep.md
View File

@@ -1,238 +0,0 @@
---
name: plan-deep
description: Deep technical planning with Gemini CLI analysis and action-planning-agent
usage: /workflow:plan-deep <task_description>
argument-hint: "task description" | requirements.md
examples:
- /workflow:plan-deep "Refactor authentication system to use JWT"
- /workflow:plan-deep "Implement real-time notifications across modules"
- /workflow:plan-deep requirements.md
---
# Workflow Plan Deep Command (/workflow:plan-deep)
## Overview
Creates comprehensive implementation plans through deep codebase analysis using Gemini CLI and the action-planning-agent. This command enforces multi-dimensional context gathering before planning, ensuring technical decisions are grounded in actual codebase understanding.
## Key Differentiators
### vs /workflow:plan
| Feature | /workflow:plan | /workflow:plan-deep |
|---------|---------------|-------------------|
| **Analysis Depth** | Basic requirements extraction | Deep codebase analysis |
| **Gemini CLI** | Optional | **Mandatory (via agent)** |
| **Context Scope** | Current input only | Multi-dimensional analysis |
| **Agent Used** | None (direct processing) | action-planning-agent |
| **Output Detail** | Standard IMPL_PLAN | Enhanced hierarchical plan |
| **Best For** | Quick planning | Complex technical tasks |
## When to Use This Command
### Ideal Scenarios
- **Cross-module refactoring** requiring understanding of multiple components
- **Architecture changes** affecting system-wide patterns
- **Complex feature implementation** spanning >3 modules
- **Performance optimization** requiring deep code analysis
- **Security enhancements** needing comprehensive vulnerability assessment
- **Technical debt resolution** with broad impact
### Not Recommended For
- Simple, single-file changes
- Documentation updates
- Configuration adjustments
- Tasks with clear, limited scope
## Execution Flow
### 1. Input Processing
```
Input Analysis:
├── Validate input clarity (reject vague descriptions)
├── Parse task description or file
├── Extract key technical terms
├── Identify potential affected domains
└── Prepare context for agent
```
**Clarity Requirements**:
- **Minimum specificity**: Must include clear technical goal and affected components
- **Auto-rejection**: Vague inputs like "optimize system", "refactor code", "improve performance" without context
- **Response**: `❌ Input too vague. Deep planning requires specific technical objectives and component scope.`
### 2. Agent Invocation with Deep Analysis Flag
The command invokes action-planning-agent with special parameters that **enforce** Gemini CLI analysis.
### 3. Agent Processing (Delegated to action-planning-agent)
**Agent Execution Flow**:
```
Agent receives DEEP_ANALYSIS_REQUIRED flag
├── Executes 4-dimension Gemini CLI analysis in parallel:
│ ├── Architecture Analysis (patterns, components)
│ ├── Code Pattern Analysis (conventions, standards)
│ ├── Impact Analysis (affected modules, dependencies)
│ └── Testing Requirements (coverage, patterns)
├── Consolidates Gemini results into gemini-analysis.md
├── Creates workflow session directory
├── Generates hierarchical IMPL_PLAN.md
├── Creates TODO_LIST.md for tracking
└── Saves all outputs to .workflow/WFS-[session-id]/
```
```markdown
Task(action-planning-agent):
description: "Deep technical planning with mandatory codebase analysis"
prompt: |
Create implementation plan for: [task_description]
EXECUTION MODE: DEEP_ANALYSIS_REQUIRED
MANDATORY REQUIREMENTS:
- Execute comprehensive Gemini CLI analysis (4 dimensions)
- Skip PRD processing (no PRD provided)
- Skip session inheritance (standalone planning)
- Force FLOW_CONTROL flag = true
- Set pre_analysis = multi-step array format with comprehensive analysis steps
- Generate hierarchical task decomposition (max 2 levels: IMPL-N.M)
- Create detailed IMPL_PLAN.md with subtasks
- Generate TODO_LIST.md for tracking
GEMINI ANALYSIS DIMENSIONS (execute in parallel):
1. Architecture Analysis - design patterns, component relationships
2. Code Pattern Analysis - conventions, error handling, validation
3. Impact Analysis - affected modules, breaking changes
4. Testing Requirements - coverage needs, test patterns
FOCUS: Technical implementation based on deep codebase understanding
```
### 4. Output Generation (by Agent)
The action-planning-agent generates in `.workflow/WFS-[session-id]/`:
- **IMPL_PLAN.md** - Hierarchical implementation plan with stages
- **TODO_LIST.md** - Unified hierarchical task tracking with ▸ container tasks and indented subtasks
- **.task/*.json** - Task definitions for complex projects
- **workflow-session.json** - Session tracking
- **gemini-analysis.md** - Consolidated Gemini analysis results
## Command Processing Logic
```python
def process_plan_deep_command(input):
# Step 1: Parse input
task_description = parse_input(input)
# Step 2: Build agent prompt with deep analysis flag
agent_prompt = f"""
EXECUTION_MODE: DEEP_ANALYSIS_REQUIRED
TASK: {task_description}
MANDATORY FLAGS:
- FLOW_CONTROL = true
- pre_analysis = multi-step array format for comprehensive pre-analysis
- FORCE_PARALLEL_ANALYSIS = true
- SKIP_PRD = true
- SKIP_SESSION_INHERITANCE = true
Execute comprehensive Gemini CLI analysis before planning.
"""
# Step 3: Invoke action-planning-agent
# Agent will handle session creation and Gemini execution
Task(
subagent_type="action-planning-agent",
description="Deep technical planning with mandatory analysis",
prompt=agent_prompt
)
# Step 4: Agent handles all processing and outputs
return "Agent executing deep analysis and planning..."
```
## Error Handling
### Common Issues and Solutions
**Input Processing Errors**
- **Vague text input**: Auto-reject without guidance
- Rejected examples: "optimize system", "refactor code", "make it faster", "improve architecture"
- Response: Direct rejection message, no further assistance
**Agent Execution Errors**
- Verify action-planning-agent availability
- Check for context size limits
- Agent handles Gemini CLI failures internally
**Gemini CLI Failures (handled by agent)**
- Agent falls back to file-pattern based analysis
- Agent retries with reduced scope automatically
- Agent alerts if critical analysis fails
**File Access Issues**
- Verify permissions for workflow directory
- Check file patterns for validity
- Alert on missing CLAUDE.md files
## Integration Points
### Related Commands
- `/workflow:plan` - Quick planning without deep analysis
- `/workflow:execute` - Execute generated plans
- `/workflow:review` - Review implementation progress
- `/context` - View generated planning documents
### Agent Dependencies
- **action-planning-agent** - Core planning engine
- **code-developer** - For execution phase
- **code-review-agent** - For quality checks
## Usage Examples
### Example 1: Cross-Module Refactoring
```bash
/workflow:plan-deep "Refactor user authentication to use JWT tokens across all services"
```
Generates comprehensive plan analyzing:
- Current auth implementation
- All affected services
- Migration strategy
- Testing requirements
### Example 2: Performance Optimization
```bash
/workflow:plan-deep "Optimize database query performance in reporting module"
```
Creates detailed plan including:
- Current query patterns analysis
- Bottleneck identification
- Optimization strategies
- Performance testing approach
### Example 3: Architecture Enhancement
```bash
/workflow:plan-deep "Implement event-driven architecture for order processing"
```
Produces hierarchical plan with:
- Current architecture assessment
- Event flow design
- Module integration points
- Staged migration approach
## Best Practices
1. **Use for Complex Tasks**: Reserve for tasks requiring deep understanding
2. **Provide Clear Descriptions**: Specific task descriptions yield better analysis
3. **Review Gemini Output**: Check analysis results for accuracy
4. **Iterate on Plans**: Refine based on initial analysis
5. **Track Progress**: Use generated TODO_LIST.md for execution
## Technical Notes
- **Agent-Driven Analysis**: action-planning-agent executes all Gemini CLI commands
- **Parallel Execution**: Agent runs 4 Gemini analyses concurrently for performance
- **Context Management**: Agent handles context size limits automatically
- **Structured Handoff**: Command passes DEEP_ANALYSIS_REQUIRED flag to agent
- **Session Management**: Agent creates and manages workflow session
- **Output Standards**: All documents follow established workflow formats
---
**System ensures**: Deep technical understanding before planning through mandatory Gemini CLI analysis and intelligent agent orchestration

166
.claude/commands/workflow/plan.md
View File

@@ -21,28 +21,47 @@ examples:
- **Issues**: `ISS-*`, `ISSUE-*`, `*-request-*` → Loads issue data and acceptance criteria - **Issues**: `ISS-*`, `ISSUE-*`, `*-request-*` → Loads issue data and acceptance criteria
- **Text**: Everything else → Parses natural language requirements - **Text**: Everything else → Parses natural language requirements
## Default Analysis Workflow ## Core Workflow
### Automatic Intelligence Selection ### Analysis & Planning Process
The command automatically performs comprehensive analysis by: The command performs comprehensive analysis through:
1. **Context Gathering**: Reading relevant CLAUDE.md documentation based on task requirements
2. **Task Assignment**: Automatically assigning Task agents based on complexity: **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`
- **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 (`~/.claude/scripts/gemini-wrapper` or `codex --full-auto exec`) - **Simple tasks** (≤3 modules): Direct CLI tools (`~/.claude/scripts/gemini-wrapper` or `codex --full-auto exec`)
- **Complex tasks** (>3 modules): Task agents with integrated CLI tool access - **Complex tasks** (>3 modules): Task agents with integrated CLI tool access
3. **Process Documentation**: Generates analysis artifacts in `.workflow/WFS-[session]/.process/ANALYSIS_RESULTS.md` - Flow control integration with automatic tool selection
4. **Flow Control Integration**: Automatic tool selection managed by flow_control system
### Analysis Artifacts Generated **2. Project Structure Analysis** ⚠️ CRITICAL PRE-PLANNING STEP
- **ANALYSIS_RESULTS.md**: Documents context analysis, codebase structure, pattern identification, and task decomposition results - **Documentation Context First**: Reference `.workflow/docs/` content from `/workflow:docs` command if available
- **Context mapping**: Project structure, dependencies, and cohesion groups - **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 strategy**: Tool selection and execution approach
## Core Rules ## Implementation Standards
### Agent Execution Context (CRITICAL) ### Context Management & Agent Execution
⚠️ **For agent execution phase**: Agents will automatically load context from plan-generated documents
**Agent Context Loading** ⚠️ CRITICAL
Agents automatically load context from plan-generated documents during execution:
**Agent Context Loading Pattern**:
```json ```json
"flow_control": { "flow_control": {
"pre_analysis": [ "pre_analysis": [
@@ -51,7 +70,7 @@ The command automatically performs comprehensive analysis by:
"action": "Load plan-generated analysis and 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')", "command": "bash(cat .workflow/WFS-[session]/.process/ANALYSIS_RESULTS.md 2>/dev/null || echo 'planning analysis not found')",
"output_to": "planning_context" "output_to": "planning_context"
}, // 可选：Task任务较为复杂时 },
{ {
"step": "load_dependencies", "step": "load_dependencies",
"action": "Retrieve dependency task summaries", "action": "Retrieve dependency task summaries",
@@ -60,52 +79,48 @@ The command automatically performs comprehensive analysis by:
}, },
{ {
"step": "load_documentation", "step": "load_documentation",
"action": "Retrieve project documentation based on task requirements", "action": "Retrieve relevant documentation based on task scope and requirements",
"command": "bash(cat CLAUDE.md README.md 2>/dev/null || echo 'documentation not found')", "command": "bash(cat .workflow/docs/README.md $(if [[ \"$TASK_TYPE\" == *\"architecture\"* ]]; then echo .workflow/docs/architecture/*.md; fi) $(if [[ \"$TASK_MODULES\" ]]; then for module in $TASK_MODULES; do echo .workflow/docs/modules/$module/*.md; done; fi) $(if [[ \"$TASK_TYPE\" == *\"api\"* ]]; then echo .workflow/docs/api/*.md; fi) CLAUDE.md README.md 2>/dev/null || echo 'documentation not found')",
"output_to": "doc_context" "output_to": "doc_context"
} }
] ]
} }
``` ```
**Trigger Conditions**: **Context Accumulation & Inheritance**:
- Task has `context.depends_on` array with task IDs 1. **Structure Analysis**: project hierarchy
- Task references external documentation files 2. **Pattern Analysis**: Tool-specific commands → existing patterns
- Task builds upon previous implementation summaries 3. **Dependency Mapping**: Previous task summaries → inheritance context
- Task requires configuration or schema files 4. **Task Context Generation**: Combined analysis → task.context fields
**Content Sources**: **Content Sources**:
- Task summaries: `.workflow/WFS-[session]/.summaries/IMPL-[task-id]-summary.md` (主任务) / `IMPL-[task-id].[subtask-id]-summary.md` (子任务) - Task summaries: `.workflow/WFS-[session]/.summaries/IMPL-[task-id]-summary.md`
- Documentation: `CLAUDE.md`, `README.md`, config files (loaded based on task context requirements) - Generated documentation: `.workflow/docs/` (architecture, modules, APIs from `/workflow:docs`)
- Documentation: `CLAUDE.md`, `README.md`, config files
- Schema definitions: `.json`, `.yaml`, `.sql` files - Schema definitions: `.json`, `.yaml`, `.sql` files
- Dependency contexts: `.workflow/WFS-[session]/.task/IMPL-*.json` - Dependency contexts: `.workflow/WFS-[session]/.task/IMPL-*.json`
- Analysis artifacts: `.workflow/WFS-[session]/.process/ANALYSIS_RESULTS.md` - Analysis artifacts: `.workflow/WFS-[session]/.process/ANALYSIS_RESULTS.md`
### File Structure Reference **Trigger Conditions**: Task has `context.depends_on` array, references external docs, builds on previous summaries, requires config/schema files
**Architecture**: @~/.claude/workflows/workflow-architecture.md
### Task Decomposition Standards
### Task Limits & Decomposition **Core Principles**:
1. **Functional Completeness** - Each task delivers complete, independently runnable functional unit including all related files (logic, UI, tests, config)
2. **Minimum Size Threshold** - Single task must contain ≥3 related files or 200 lines of code; smaller content merged with adjacent features
3. **Dependency Cohesion** - Tightly coupled components completed in same task (shared models, API endpoints, user flows)
4. **Hierarchy Control** - Flat structure (≤5 tasks) | Two-level (6-10 tasks) | Re-scope (>10 tasks)
**Implementation Rules**:
- **Maximum 10 tasks**: Hard enforced limit - projects exceeding must be re-scoped - **Maximum 10 tasks**: Hard enforced limit - projects exceeding must be re-scoped
- **Function-based decomposition**: By complete functional units, not files/steps - **Function-based decomposition**: By complete functional units, not files/steps
- **File cohesion**: Group related files (UI + logic + tests + config) in same task - **File cohesion**: Group related files (UI + logic + tests + config) in same task
- **Task saturation**: Merge "analyze + implement" by default (0.5 count for complex prep tasks) - **Task saturation**: Merge "analyze + implement" by default (0.5 count for complex prep tasks)
### Core Task Decomposition Standards **Task Saturation Assessment**:
1. **Functional Completeness Principle** - Each task must deliver a complete, independently runnable functional unit including all related files (logic, UI, tests, config) - **Default Merge** (cohesive files together): Functional modules with UI + logic + tests + config, features with tests/docs, files sharing interfaces/data structures
- **Only Separate When**: Independent functional modules, different tech stacks/deployment units, would exceed 10-task limit
2. **Minimum Size Threshold** - A single task must contain at least 3 related files or 200 lines of code; content below this threshold must be merged with adjacent features
3. **Dependency Cohesion Principle** - Tightly coupled components must be completed in the same task, including shared data models, same API endpoints, and all parts of a single user flow
4. **Hierarchy Control Rule** - Use flat structure for ≤5 tasks, two-level structure for 6-10 tasks, and mandatory re-scoping into multiple iterations for >10 tasks
### Pre-Planning Analysis (CRITICAL)
⚠️ **Must complete BEFORE generating any plan documents**
1. **Complexity assessment**: Count total saturated tasks
2. **Decomposition strategy**: Flat (≤5) | Hierarchical (6-10) | Re-scope (>10)
3. **File grouping**: Identify cohesive file sets
4. **Quantity prediction**: Estimate main tasks, subtasks, container vs leaf ratio
### Session Management ⚠️ CRITICAL ### Session Management ⚠️ CRITICAL
- **⚡ FIRST ACTION**: Check for all `.workflow/.active-*` markers before any planning - **⚡ FIRST ACTION**: Check for all `.workflow/.active-*` markers before any planning
@@ -116,53 +131,25 @@ The command automatically performs comprehensive analysis by:
- **⚠️ Dependency context**: MUST read ALL previous task summary documents from selected session before planning - **⚠️ Dependency context**: MUST read ALL previous task summary documents from selected session before planning
- **Session isolation**: Each session maintains independent context and state - **Session isolation**: Each session maintains independent context and state
### Project Structure Analysis & Engineering Enhancement
**⚠️ CRITICAL PRE-PLANNING STEP**: Must complete comprehensive project analysis before any task planning begins
**Analysis Process**: Context Gathering → Codebase Exploration → Pattern Recognition → Implementation Strategy
**Tool Selection Protocol** (Managed by flow_control):
- **Simple patterns** (≤3 modules): Direct CLI tools (`~/.claude/scripts/gemini-wrapper` or `codex --full-auto exec`)
- **Complex analysis** (>3 modules): Task agents with integrated CLI tool access and built-in tool capabilities
**Tool Priority**: Task(complex) > Direct CLI(simple) > Hybrid(mixed complexity)
**Automatic Selection**: flow_control system determines optimal tool based on task complexity and context requirements
**Core Principles**: **Task Patterns**:
- **Complexity-Driven Selection**: Simple patterns use direct CLI, complex analysis uses Task agents with CLI integration - ✅ **Correct (Function-based)**: `IMPL-001: User authentication system` (models + routes + components + middleware + tests)
- **Context-First Approach**: Always gather project understanding before tool selection - ❌ **Wrong (File/step-based)**: `IMPL-001: Create database model`, `IMPL-002: Create API endpoint`
- **Intelligent Escalation**: Start CLI, escalate to Task agents when encountering complexity
- **Hybrid Flexibility**: Task agents can freely use CLI commands and built-in tools for comprehensive analysis
**Structure Integration**: ## Document Generation
- Identifies module boundaries and relationships
- Maps file dependencies and cohesion groups
- Populates task.context.focus_paths automatically
- Enables precise target_files generation
## Task Patterns **Workflow**: Identifier Creation → Folder Structure → IMPL_PLAN.md → .task/IMPL-NNN.json → TODO_LIST.md
### ✅ Correct (Function-based) **Always Created**:
- `IMPL-001: User authentication system` (models + routes + components + middleware + tests)
- `IMPL-002: Data export functionality` (service + routes + UI + utils + tests)
### ❌ Wrong (File/step-based)
- `IMPL-001: Create database model`
- `IMPL-002: Create API endpoint`
- `IMPL-003: Create frontend component`
## Output Documents
### Document Workflow
**Identifier Creation** → **Folder Structure Creation** → **IMPL_PLAN.md** → **.task/IMPL-NNN.json** → **TODO_LIST.md**
### Always Created
- **IMPL_PLAN.md**: Requirements, task breakdown, success criteria - **IMPL_PLAN.md**: Requirements, task breakdown, success criteria
- **Session state**: Task references and paths - **Session state**: Task references and paths
### Auto-Created (complexity > simple) **Auto-Created (complexity > simple)**:
- **TODO_LIST.md**: Hierarchical progress tracking - **TODO_LIST.md**: Hierarchical progress tracking
- **.task/*.json**: Individual task definitions with flow_control - **.task/*.json**: Individual task definitions with flow_control
- **.process/ANALYSIS_RESULTS.md**: Analysis results and planning artifacts.Template:@~/.claude/workflows/ANALYSIS_RESULTS.md - **.process/ANALYSIS_RESULTS.md**: Analysis results and planning artifacts
### Document Structure **Document Structure**:
``` ```
.workflow/WFS-[topic]/ .workflow/WFS-[topic]/
├── IMPL_PLAN.md # Main planning document ├── IMPL_PLAN.md # Main planning document
@@ -174,18 +161,10 @@ The command automatically performs comprehensive analysis by:
└── IMPL-002.json └── IMPL-002.json
``` ```
## Task Saturation Assessment
**Default Merge** (cohesive files together):
- Functional modules with UI + logic + tests + config
- Features with their tests and documentation
- Files sharing common interfaces/data structures
**Only Separate When**: ## Reference Information
- Completely independent functional modules
- Different tech stacks or deployment units
- Would exceed 10-task limit otherwise
## Task JSON Schema (5-Field Architecture) ### Task JSON Schema (5-Field Architecture)
Each task.json uses the workflow-architecture.md 5-field schema: Each task.json uses the workflow-architecture.md 5-field schema:
- **id**: IMPL-N[.M] format (max 2 levels) - **id**: IMPL-N[.M] format (max 2 levels)
- **title**: Descriptive task name - **title**: Descriptive task name
@@ -194,7 +173,10 @@ Each task.json uses the workflow-architecture.md 5-field schema:
- **context**: { requirements, focus_paths, acceptance, parent, depends_on, inherited, shared_context } - **context**: { requirements, focus_paths, acceptance, parent, depends_on, inherited, shared_context }
- **flow_control**: { pre_analysis[], implementation_approach, target_files[] } - **flow_control**: { pre_analysis[], implementation_approach, target_files[] }
## Execution Integration ### File Structure Reference
**Architecture**: @~/.claude/workflows/workflow-architecture.md
### Execution Integration
Documents created for `/workflow:execute`: Documents created for `/workflow:execute`:
- **IMPL_PLAN.md**: Context loading and requirements - **IMPL_PLAN.md**: Context loading and requirements
- **.task/*.json**: Agent implementation context - **.task/*.json**: Agent implementation context
@@ -205,10 +187,4 @@ Documents created for `/workflow:execute`:
- **File not found**: Clear suggestions - **File not found**: Clear suggestions
- **>10 tasks**: Force re-scoping into iterations - **>10 tasks**: Force re-scoping into iterations
### Context Accumulation & Inheritance
**Context Flow Process**:
1. **Structure Analysis**: project hierarchy
2. **Pattern Analysis**: Tool-specific commands → existing patterns
3. **Dependency Mapping**: Previous task summaries → inheritance context
4. **Task Context Generation**: Combined analysis → task.context fields

255
.claude/workflows/doc_agent.md Normal file
View File

@@ -0,0 +1,255 @@
# Documentation Agent
## Agent Overview
Specialized agent for hierarchical documentation generation with bottom-up analysis approach.
## Core Capabilities
- **Modular Analysis**: Analyze individual modules and components
- **Hierarchical Synthesis**: Build documentation from modules to system level
- **Multi-tool Integration**: Combine Agent tasks, CLI tools, and direct analysis
- **Progress Tracking**: Use TodoWrite throughout the documentation process
## Analysis Strategy
### Two-Level Hierarchy
1. **Level 1 (Module)**: Individual component/module documentation
2. **Level 2 (System)**: Integrated system-wide documentation
### Bottom-Up Process
1. **Module Discovery**: Identify all modules/components in the system
2. **Module Analysis**: Deep dive into each module individually
3. **Module Documentation**: Generate detailed module docs
4. **Integration Analysis**: Analyze relationships between modules
5. **System Synthesis**: Create unified system documentation
## Tool Selection Strategy
### For Module Analysis (Simple, focused scope)
- **CLI Tools**: Direct Gemini/Codex commands for individual modules
- **File Patterns**: Focused file sets per module
- **Fast Processing**: Quick analysis of contained scope
### For System Integration (Complex, multi-module)
- **Agent Tasks**: Complex analysis requiring multiple tools
- **Cross-module Analysis**: Relationship mapping between modules
- **Synthesis Tasks**: Combining multiple module analyses
## Documentation Structure
### Module Level (Level 1)
```
.workflow/docs/modules/
├── [module-name]/
│ ├── overview.md # Module overview
│ ├── api.md # Module APIs
│ ├── dependencies.md # Module dependencies
│ └── examples.md # Usage examples
```
### System Level (Level 2)
```
.workflow/docs/
├── README.md # Complete system overview
├── architecture/
│ ├── system-design.md # High-level architecture
│ ├── module-map.md # Module relationships
│ ├── data-flow.md # System data flow
│ └── tech-stack.md # Technology decisions
└── api/
├── unified-api.md # Complete API documentation
└── openapi.yaml # OpenAPI specification
```
## Process Flow Templates
### Phase 1: Module Discovery & Todo Setup
```json
{
"step": "module_discovery",
"method": "cli",
"command": "find src/ -type d -name '*' | grep -v node_modules | head -20",
"purpose": "Identify all modules for documentation",
"todo_action": "create_module_todos"
}
```
### Phase 2: Module Analysis (Parallel)
```json
{
"step": "module_analysis",
"method": "cli_parallel",
"pattern": "per_module",
"command_template": "~/.claude/scripts/gemini-wrapper -p 'ANALYZE_MODULE: {module_path}'",
"purpose": "Analyze each module individually",
"todo_action": "track_module_progress"
}
```
### Phase 3: Module Documentation (Parallel)
```json
{
"step": "module_documentation",
"method": "cli_parallel",
"pattern": "per_module",
"command_template": "codex --full-auto exec 'DOCUMENT_MODULE: {module_path}' -s danger-full-access",
"purpose": "Generate documentation for each module",
"todo_action": "mark_module_complete"
}
```
### Phase 4: System Integration (Agent)
```json
{
"step": "system_integration",
"method": "agent",
"agent_type": "general-purpose",
"purpose": "Analyze cross-module relationships and create system view",
"todo_action": "track_integration_progress"
}
```
### Phase 5: System Documentation (Agent)
```json
{
"step": "system_documentation",
"method": "agent",
"agent_type": "general-purpose",
"purpose": "Generate unified system documentation",
"todo_action": "mark_system_complete"
}
```
## CLI Command Templates
### Module Analysis Template
```bash
~/.claude/scripts/gemini-wrapper -p "
PURPOSE: Analyze individual module for documentation
TASK: Deep analysis of module structure, APIs, and dependencies
CONTEXT: @{{{module_path}}/**/*}
EXPECTED: Module analysis for documentation generation
MODULE ANALYSIS RULES:
1. Module Scope Definition:
- Identify module boundaries and entry points
- Map internal file organization
- Extract module's primary purpose and responsibilities
2. API Surface Analysis:
- Identify exported functions, classes, and interfaces
- Document public API contracts
- Map input/output types and parameters
3. Dependency Analysis:
- Extract internal dependencies within module
- Identify external dependencies from other modules
- Map configuration and environment dependencies
4. Usage Pattern Analysis:
- Find example usage within codebase
- Identify common patterns and utilities
- Document error handling approaches
OUTPUT FORMAT:
- Module overview with clear scope definition
- API documentation with types and examples
- Dependency map with clear relationships
- Usage examples from actual codebase
" -t 1200000
```
### Module Documentation Template
```bash
codex --full-auto exec "
PURPOSE: Generate comprehensive module documentation
TASK: Create detailed documentation for analyzed module
CONTEXT: Module analysis results from Gemini
EXPECTED: Complete module documentation in .workflow/docs/modules/{module_name}/
DOCUMENTATION GENERATION RULES:
1. Create module directory structure
2. Generate overview.md with module purpose and architecture
3. Create api.md with detailed API documentation
4. Generate dependencies.md with dependency analysis
5. Create examples.md with practical usage examples
6. Ensure consistent formatting and cross-references
" -s danger-full-access -t 1200000
```
## Agent Task Templates
### System Integration Agent Task
```json
{
"description": "Analyze cross-module relationships",
"prompt": "You are analyzing a software system to understand relationships between modules. Your task is to:\n\n1. Read all module documentation from .workflow/docs/modules/\n2. Identify integration points and data flow between modules\n3. Map system-wide architecture patterns\n4. Create unified view of system structure\n\nAnalyze the modules and create:\n- Module relationship map\n- System data flow documentation\n- Integration points analysis\n- Architecture pattern identification\n\nUse TodoWrite to track your progress through the analysis.",
"subagent_type": "general-purpose"
}
```
### System Documentation Agent Task
```json
{
"description": "Generate unified system documentation",
"prompt": "You are creating comprehensive system documentation based on module analyses. Your task is to:\n\n1. Synthesize information from .workflow/docs/modules/ \n2. Create unified system architecture documentation\n3. Generate complete API documentation\n4. Create system overview and navigation\n\nGenerate:\n- README.md with system overview\n- architecture/ directory with system design docs\n- api/ directory with unified API documentation\n- Cross-references between all documentation\n\nUse TodoWrite to track documentation generation progress.",
"subagent_type": "general-purpose"
}
```
## Progress Tracking Templates
### Module Todo Structure
```json
{
"content": "Analyze {module_name} module",
"activeForm": "Analyzing {module_name} module",
"status": "pending"
}
```
### Integration Todo Structure
```json
{
"content": "Integrate module analyses into system view",
"activeForm": "Integrating module analyses",
"status": "pending"
}
```
### Documentation Todo Structure
```json
{
"content": "Generate unified system documentation",
"activeForm": "Generating system documentation",
"status": "pending"
}
```
## Error Handling & Recovery
### Module Analysis Failures
- Skip failed modules with warning
- Continue with successful modules
- Retry failed modules with different approach
### Integration Failures
- Fall back to manual integration
- Use partial results where available
- Generate documentation with known limitations
### Documentation Generation Failures
- Generate partial documentation
- Include clear indicators of incomplete sections
- Provide recovery instructions
## Quality Assurance
### Module Documentation Quality
- Verify all modules have complete documentation
- Check API documentation completeness
- Validate examples and cross-references
### System Documentation Quality
- Ensure module integration is complete
- Verify system overview accuracy
- Check documentation navigation and links