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

fix: Clarify pre_analysis execution flow in workflow commands

Browse Source 
- Fix execute.md: Clarify that pre_analysis steps are passed to agents for execution, not executed by workflow:execute command
- Fix plan.md: Add explicit note that pre_analysis steps are generated for agent execution
- Streamline verbose sections while preserving critical operational details
- Maintain consistency between plan and execute commands regarding pre_analysis handling

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

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
catlog22
2025-09-24 17:06:15 +08:00
parent 27cf20d57f
commit f4d1f23e6d
3 changed files with 101 additions and 95 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -60,9 +60,10 @@ The command performs comprehensive analysis through:
### Context Management & Agent Execution
**Agent Context Loading** ⚠️ CRITICAL
Agents automatically load context from plan-generated documents during execution:
The following pre_analysis steps are generated for agent execution:
```json
// Example pre_analysis steps generated by /workflow:plan for agent execution
"flow_control": {
"pre_analysis": [
{
@@ -87,39 +88,25 @@ Agents automatically load context from plan-generated documents during execution
}
```
**Context Accumulation & Inheritance**:
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
**Context Accumulation Guidelines**:
Flow_control design should follow these principles:
1. **Structure Analysis**: Project hierarchy and patterns
2. **Dependency Mapping**: Previous task summaries → inheritance context
3. **Task Context Generation**: Combined analysis → task.context fields
**Content Sources**:
- Task summaries: `.workflow/WFS-[session]/.summaries/IMPL-[task-id]-summary.md`
- Generated documentation: `.workflow/docs/` (architecture, modules, APIs from `/workflow:docs`)
- Documentation: `CLAUDE.md`, `README.md`, config files
- Schema definitions: `.json`, `.yaml`, `.sql` files
- Dependency contexts: `.workflow/WFS-[session]/.task/IMPL-*.json`
- Task summaries: `.workflow/WFS-[session]/.summaries/`
- Documentation: `.workflow/docs/`, `CLAUDE.md`, `README.md`, config files
- Analysis artifacts: `.workflow/WFS-[session]/.process/ANALYSIS_RESULTS.md`
**Trigger Conditions**: Task has `context.depends_on` array, references external docs, builds on previous summaries, requires config/schema files
- Dependency contexts: `.workflow/WFS-[session]/.task/IMPL-*.json`
### Task Decomposition Standards
**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
- **Function-based decomposition**: By complete functional units, not files/steps
- **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 Assessment**:
- **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
**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