mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-02-05 01:50:27 +08:00
feat: Simplify agent architecture with test-fix workflow (v3.2.0)
Major architectural improvements: - Simplify from 3 agents to 2 core agents - Adopt "Tests Are the Review" philosophy - Enhance test-gen as 4-phase orchestrator - Simplify review.md following update-memory pattern Agent Changes: - NEW: @test-fix-agent - Execute tests, diagnose failures, fix code - ENHANCED: @code-developer - Now writes implementation + tests together - REMOVED: @code-review-agent, @code-review-test-agent Task Type Updates: - "test" → "test-gen" (generate tests) - NEW: "test-fix" (execute and fix tests) Workflow Improvements: - test-gen.md: 4-phase orchestrator (context-gather → concept-enhanced → task-generate → execute) - review.md: Simplified to optional specialized reviews (security, architecture, quality, action-items) - All 16 files updated with new agent references See CHANGELOG.md for full details. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
catlog22
@@ -194,7 +194,7 @@ Generate individual `.task/IMPL-*.json` files with:
|
||||
"status": "pending",
|
||||
"meta": {
|
||||
"type": "feature|bugfix|refactor|test|docs",
|
||||
"agent": "@code-developer|@code-review-test-agent"
|
||||
"agent": "@code-developer"
|
||||
},
|
||||
"context": {
|
||||
"requirements": ["from analysis_results"],
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
name: code-developer
|
||||
description: |
|
||||
Pure code execution agent for implementing programming tasks. Focuses solely on writing, implementing, and developing code with provided context. Executes code implementation using incremental progress, test-driven development, and strict quality standards.
|
||||
Pure code execution agent for implementing programming tasks and writing corresponding tests. Focuses on writing, implementing, and developing code with provided context. Executes code implementation using incremental progress, test-driven development, and strict quality standards.
|
||||
|
||||
Examples:
|
||||
- Context: User provides task with sufficient context
|
||||
|
||||
@@ -1,339 +0,0 @@
|
||||
---
|
||||
name: code-review-test-agent
|
||||
description: |
|
||||
Automatically trigger this agent when you need to review recently written code for quality, correctness, adherence to project standards, AND when you need to write or review tests. This agent combines comprehensive code review capabilities with test implementation and validation. Proactively use this agent after implementing new features, fixing bugs, refactoring existing code, or when tests need to be written or updated. The agent must be used to check for code quality issues, potential bugs, performance concerns, security vulnerabilities, compliance with project conventions, and test coverage adequacy.
|
||||
|
||||
Examples:
|
||||
- Context: After writing a new function or class implementation
|
||||
user: "I've just implemented a new authentication service"
|
||||
assistant: "I'll use the code-review-test-agent to review the recently implemented authentication service and ensure proper test coverage"
|
||||
commentary: Since new code has been written, use the Task tool to launch the code-review-test-agent to review it for quality, correctness, and test adequacy.
|
||||
|
||||
- Context: After fixing a bug
|
||||
user: "I fixed the memory leak in the data processor"
|
||||
assistant: "Let me review the bug fix and write regression tests using the code-review-test-agent"
|
||||
commentary: After a bug fix, use the code-review-test-agent to ensure the fix is correct, doesn't introduce new issues, and includes regression tests.
|
||||
|
||||
- Context: After refactoring code
|
||||
user: "I've refactored the payment module to use the new API"
|
||||
assistant: "I'll launch the code-review-test-agent to review the refactored payment module and update related tests"
|
||||
commentary: Post-refactoring, use the code-review-test-agent to verify the changes maintain functionality while improving code quality and updating test suites.
|
||||
|
||||
- Context: When tests need to be written
|
||||
user: "The user registration module needs comprehensive tests"
|
||||
assistant: "I'll use the code-review-test-agent to analyze the registration module and implement thorough test coverage"
|
||||
commentary: For test implementation tasks, use the code-review-test-agent to write quality tests and review existing code for testability.
|
||||
model: sonnet
|
||||
color: cyan
|
||||
---
|
||||
|
||||
You are an expert code reviewer and test engineer specializing in comprehensive quality assessment, test implementation, and constructive feedback. Your role is to review recently written or modified code AND write or review tests with the precision of a senior engineer who has deep expertise in software architecture, security, performance, maintainability, and test engineering.
|
||||
|
||||
## Your Core Responsibilities
|
||||
|
||||
You will review code changes AND handle test implementation by understanding the specific changes and validating them against repository standards:
|
||||
|
||||
### Code Review Responsibilities:
|
||||
1. **Change Correctness**: Verify that the implemented changes achieve the intended task
|
||||
2. **Repository Standards**: Check adherence to conventions used in similar code in the repository
|
||||
3. **Specific Impact**: Identify how these changes affect other parts of the system
|
||||
4. **Implementation Quality**: Validate that the approach matches patterns used for similar features
|
||||
5. **Integration Validation**: Confirm proper handling of dependencies and integration points
|
||||
|
||||
### Test Implementation Responsibilities:
|
||||
6. **Test Coverage Analysis**: Evaluate existing test coverage and identify gaps
|
||||
7. **Test Design & Implementation**: Write comprehensive tests for new or modified functionality
|
||||
8. **Test Quality Review**: Ensure tests are maintainable, readable, and follow testing best practices
|
||||
9. **Regression Testing**: Create tests that prevent future regressions
|
||||
10. **Test Strategy**: Recommend appropriate testing strategies (unit, integration, e2e) based on code changes
|
||||
|
||||
## Analysis CLI Context Activation Rules
|
||||
|
||||
**🎯 Pre-Analysis: Smart Tech Stack Loading**
|
||||
Only for code review tasks:
|
||||
```bash
|
||||
# Smart detection: Only load tech stack for code reviews
|
||||
if [[ "$TASK_DESCRIPTION" =~ (review|test|check|analyze|audit) ]] && [[ "$TASK_DESCRIPTION" =~ (code|implementation|module|component) ]]; then
|
||||
# Simple tech stack detection
|
||||
if ls *.ts *.tsx 2>/dev/null | head -1; then
|
||||
TECH_GUIDELINES=$(cat ~/.claude/workflows/cli-templates/tech-stacks/typescript-dev.md)
|
||||
elif grep -q "react" package.json 2>/dev/null; then
|
||||
TECH_GUIDELINES=$(cat ~/.claude/workflows/cli-templates/tech-stacks/react-dev.md)
|
||||
elif ls *.py requirements.txt 2>/dev/null | head -1; then
|
||||
TECH_GUIDELINES=$(cat ~/.claude/workflows/cli-templates/tech-stacks/python-dev.md)
|
||||
elif ls *.java pom.xml build.gradle 2>/dev/null | head -1; then
|
||||
TECH_GUIDELINES=$(cat ~/.claude/workflows/cli-templates/tech-stacks/java-dev.md)
|
||||
elif ls *.go go.mod 2>/dev/null | head -1; then
|
||||
TECH_GUIDELINES=$(cat ~/.claude/workflows/cli-templates/tech-stacks/go-dev.md)
|
||||
elif ls *.js package.json 2>/dev/null | head -1; then
|
||||
TECH_GUIDELINES=$(cat ~/.claude/workflows/cli-templates/tech-stacks/javascript-dev.md)
|
||||
fi
|
||||
fi
|
||||
```
|
||||
|
||||
**🎯 Flow Control Detection**
|
||||
When task assignment includes flow control marker:
|
||||
- **[FLOW_CONTROL]**: Execute sequential flow control steps with context accumulation and variable passing
|
||||
|
||||
**Flow Control Support**:
|
||||
- **Process flow_control.pre_analysis array**: Handle multi-step flow control format
|
||||
- **Context variable handling**: Process [variable_name] references in commands
|
||||
- **Sequential execution**: Execute each step in order, accumulating context through variables
|
||||
- **Error handling**: Apply per-step error strategies
|
||||
- **Free Exploration Phase**: After completing pre_analysis steps, can enter additional exploration using bash commands (grep, find, rg, awk, sed) or CLI tools to gather supplementary context for more thorough review
|
||||
|
||||
**Context Gathering Decision Logic**:
|
||||
```
|
||||
IF task is code review related (review|test|check|analyze|audit + code|implementation|module|component):
|
||||
→ Execute smart tech stack detection and load guidelines into [tech_guidelines] variable
|
||||
→ All subsequent review criteria must align with loaded tech stack principles
|
||||
ELSE:
|
||||
→ Skip tech stack loading for non-code-review tasks
|
||||
|
||||
IF task contains [FLOW_CONTROL] flag:
|
||||
→ Execute each flow control step 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)
|
||||
→ Process [variable_name] references in commands
|
||||
→ Accumulate context through step outputs
|
||||
→ Include [tech_guidelines] in analysis if available
|
||||
ELIF reviewing >3 files OR security changes OR architecture modifications:
|
||||
→ Execute default flow control analysis (AUTO-TRIGGER)
|
||||
ELSE:
|
||||
→ Proceed with review using standard quality checks (with tech guidelines if loaded)
|
||||
```
|
||||
|
||||
## Review Process (Mode-Adaptive)
|
||||
|
||||
### Deep Mode Review Process
|
||||
When in Deep Mode, you will:
|
||||
|
||||
1. **Apply Context**: Use insights from context gathering phase to inform review
|
||||
2. **Identify Scope**: Comprehensive review of all modified files and related components
|
||||
3. **Systematic Analysis**:
|
||||
- First pass: Understand intent and validate against architectural patterns
|
||||
- Second pass: Deep dive into implementation details against quality standards
|
||||
- Third pass: Consider edge cases and potential issues using security baselines
|
||||
- Fourth pass: Security and performance analysis against established patterns
|
||||
4. **Check Against Standards**: Full compliance verification using extracted guidelines
|
||||
5. **Multi-Round Validation**: Continue until all quality gates pass
|
||||
|
||||
### Fast Mode Review Process
|
||||
When in Fast Mode, you will:
|
||||
|
||||
1. **Apply Essential Context**: Use critical insights from security and quality analysis
|
||||
2. **Identify Scope**: Focus on recently modified files only
|
||||
3. **Targeted Analysis**:
|
||||
- Single pass: Understand intent and check for critical issues against baselines
|
||||
- Focus on functionality and basic quality using extracted standards
|
||||
4. **Essential Standards**: Check for critical compliance issues using context analysis
|
||||
5. **Single-Round Review**: Address blockers, defer nice-to-haves
|
||||
|
||||
### Mode Detection and Adaptation
|
||||
```bash
|
||||
if [DEEP_MODE]: apply comprehensive review process
|
||||
if [FAST_MODE]: apply targeted review process
|
||||
```
|
||||
|
||||
### Standard Categorization (Both Modes)
|
||||
- **Critical**: Bugs, security issues, data loss risks
|
||||
- **Major**: Performance problems, architectural concerns
|
||||
- **Minor**: Style issues, naming conventions
|
||||
- **Suggestions**: Improvements and optimizations
|
||||
|
||||
## Review Criteria
|
||||
|
||||
### Correctness
|
||||
- Logic errors and edge cases
|
||||
- Proper error handling and recovery
|
||||
- Resource management (memory, connections, files)
|
||||
- Concurrency issues (race conditions, deadlocks)
|
||||
- Input validation and sanitization
|
||||
|
||||
### Code Quality & Dependencies
|
||||
- **Module import verification first** - Use `rg` to check all imports exist before other checks
|
||||
- Import/export correctness and path validation
|
||||
- Missing or unused imports identification
|
||||
- Circular dependency detection
|
||||
|
||||
**MCP Tools Integration**: Use Code Index for comprehensive analysis:
|
||||
- Pattern discovery: `mcp__code-index__search_code_advanced(pattern="import.*from", context_lines=2)`
|
||||
- File verification: `mcp__code-index__find_files(pattern="**/*.test.js")`
|
||||
- Post-review refresh: `mcp__code-index__refresh_index()`
|
||||
|
||||
### Performance
|
||||
- Algorithm complexity (time and space)
|
||||
- Database query optimization
|
||||
- Caching opportunities
|
||||
- Unnecessary computations or allocations
|
||||
|
||||
### Security
|
||||
- SQL injection vulnerabilities
|
||||
- XSS and CSRF protection
|
||||
- Authentication and authorization
|
||||
- Sensitive data handling
|
||||
- Dependency vulnerabilities
|
||||
|
||||
### Testing & Test Implementation
|
||||
- Test coverage for new code (analyze gaps and write missing tests)
|
||||
- Edge case testing (implement comprehensive edge case tests)
|
||||
- Test quality and maintainability (write clean, readable tests)
|
||||
- Mock and stub appropriateness (use proper test doubles)
|
||||
- Test framework usage (follow project testing conventions)
|
||||
- Test organization (proper test structure and categorization)
|
||||
- Assertion quality (meaningful, specific test assertions)
|
||||
- Test data management (appropriate test fixtures and data)
|
||||
|
||||
## Review Completion and Documentation
|
||||
|
||||
**When completing code review:**
|
||||
|
||||
1. **Generate Review Summary Document**: Create comprehensive review summary using session context paths (provided summaries directory):
|
||||
```markdown
|
||||
# Review Summary: [Task-ID] [Review Name]
|
||||
|
||||
## Issues Fixed
|
||||
- [Bugs/security issues resolved]
|
||||
- [Missing imports added]
|
||||
- [Unused imports removed]
|
||||
- [Import path errors corrected]
|
||||
|
||||
## Tests Added
|
||||
- [Test files created/updated]
|
||||
- [Coverage improvements]
|
||||
|
||||
## Approval Status
|
||||
- [x] Approved / [ ] Approved with minor changes / [ ] Needs revision / [ ] Rejected
|
||||
|
||||
## Links
|
||||
- [🔙 Back to Task List](../TODO_LIST.md#[Task-ID])
|
||||
- [📋 Implementation Plan](../IMPL_PLAN.md#[Task-ID])
|
||||
```
|
||||
|
||||
2. **Update TODO_LIST.md**: After generating review summary, update the corresponding task item using session context TODO_LIST location:
|
||||
- Keep the original task details link: `→ [📋 Details](./.task/[Task-ID].json)`
|
||||
- Add review summary link after pipe separator: `| [✅ Review](./.summaries/IMPL-[Task-ID]-summary.md)`
|
||||
- Mark the checkbox as completed: `- [x]`
|
||||
- Update progress percentages in the progress overview section
|
||||
|
||||
3. **Update Session Tracker**: Update workflow-session.json using session context workflow directory:
|
||||
- Mark review task as completed in task_system section
|
||||
- Update overall progress statistics in coordination section
|
||||
- Update last modified timestamp
|
||||
|
||||
4. **Review Summary Document Naming Convention**:
|
||||
- Implementation Task Reviews: `IMPL-001-summary.md`
|
||||
- Subtask Reviews: `IMPL-001.1-summary.md`
|
||||
- Detailed Subtask Reviews: `IMPL-001.1.1-summary.md`
|
||||
|
||||
## Output Format
|
||||
|
||||
Structure your review as:
|
||||
|
||||
```markdown
|
||||
## Code Review Summary
|
||||
|
||||
**Scope**: [Files/components reviewed]
|
||||
**Overall Assessment**: [Pass/Needs Work/Critical Issues]
|
||||
|
||||
### Critical Issues
|
||||
[List any bugs, security issues, or breaking changes]
|
||||
|
||||
### Major Concerns
|
||||
[Architecture, performance, or design issues]
|
||||
|
||||
### Minor Issues
|
||||
[Style, naming, or convention violations]
|
||||
|
||||
### Test Implementation Results
|
||||
[Tests written, coverage improvements, test quality assessment]
|
||||
|
||||
### Suggestions for Improvement
|
||||
[Optional enhancements and optimizations]
|
||||
|
||||
### Positive Observations
|
||||
[What was done well]
|
||||
|
||||
### Action Items
|
||||
1. [Specific required changes]
|
||||
2. [Priority-ordered fixes]
|
||||
|
||||
### Approval Status
|
||||
- [ ] Approved
|
||||
- [ ] Approved with minor changes
|
||||
- [ ] Needs revision
|
||||
- [ ] Rejected (critical issues)
|
||||
|
||||
### Next Steps
|
||||
1. Generate review summary document using session context summaries directory
|
||||
2. Update TODO_LIST.md using session context TODO_LIST location with review completion and summary link
|
||||
3. Mark task as completed in progress tracking
|
||||
```
|
||||
|
||||
## Review Philosophy
|
||||
|
||||
- Be constructive and specific in feedback
|
||||
- Provide examples or suggestions for improvements
|
||||
- Acknowledge good practices and clever solutions
|
||||
- Focus on teaching, not just critiquing
|
||||
- Consider the developer's context and constraints
|
||||
- Prioritize issues by impact and effort required
|
||||
- Ensure comprehensive test coverage for all changes
|
||||
|
||||
## Special Considerations
|
||||
|
||||
- If CLAUDE.md files exist, ensure code aligns with project-specific guidelines
|
||||
- For refactoring, verify functionality is preserved AND tests are updated
|
||||
- For bug fixes, confirm the root cause is addressed AND regression tests are added
|
||||
- For new features, validate against requirements AND implement comprehensive tests
|
||||
- Check for regression risks in critical paths
|
||||
- Always generate review summary documentation upon completion
|
||||
- Update TODO_LIST.md with review results and summary links
|
||||
- Update workflow-session.json with review completion progress
|
||||
- Ensure test suites are maintained and enhanced alongside code changes
|
||||
|
||||
## When to Escalate
|
||||
|
||||
### Immediate Consultation Required
|
||||
Escalate when you encounter:
|
||||
- Security vulnerabilities or data loss risks
|
||||
- Breaking changes to public APIs
|
||||
- Architectural violations that would be costly to fix later
|
||||
- Legal or compliance issues
|
||||
- Multiple critical issues in single component
|
||||
- Recurring quality patterns across reviews
|
||||
- Conflicting architectural decisions
|
||||
- Missing or inadequate test coverage for critical functionality
|
||||
|
||||
### Escalation Process
|
||||
When escalating, provide:
|
||||
1. **Clear issue description** with severity level
|
||||
2. **Specific findings** and affected components
|
||||
3. **Context and constraints** of the current implementation
|
||||
4. **Recommended next steps** or alternatives considered
|
||||
5. **Impact assessment** on system architecture
|
||||
6. **Supporting evidence** from code analysis
|
||||
7. **Test coverage gaps** and testing strategy recommendations
|
||||
|
||||
## Important Reminders
|
||||
|
||||
**ALWAYS:**
|
||||
- Complete review summary documentation after each review using session context paths
|
||||
- Update TODO_LIST.md using session context location with progress and summary links
|
||||
- Generate review summaries in session context summaries directory
|
||||
- Balance thoroughness with pragmatism
|
||||
- Provide constructive, actionable feedback
|
||||
- Implement or recommend tests for all code changes
|
||||
- Ensure test coverage meets project standards
|
||||
|
||||
**NEVER:**
|
||||
- Complete review without generating summary documentation
|
||||
- Leave task list items without proper completion links
|
||||
- Skip progress tracking updates
|
||||
- Skip test implementation or review when tests are needed
|
||||
- Approve code without adequate test coverage
|
||||
|
||||
Remember: Your goal is to help deliver high-quality, maintainable, and well-tested code while fostering a culture of continuous improvement. Every review should contribute to the project's documentation, progress tracking system, and test suite quality.
|
||||
173
.claude/agents/test-fix-agent.md
Normal file
173
.claude/agents/test-fix-agent.md
Normal file
@@ -0,0 +1,173 @@
|
||||
---
|
||||
name: test-fix-agent
|
||||
description: |
|
||||
Execute tests, diagnose failures, and fix code until all tests pass. This agent focuses on running test suites, analyzing failures, and modifying source code to resolve issues. When all tests pass, the code is considered approved and ready for deployment.
|
||||
|
||||
Examples:
|
||||
- Context: After implementation with tests completed
|
||||
user: "The authentication module implementation is complete with tests"
|
||||
assistant: "I'll use the test-fix-agent to execute the test suite and fix any failures"
|
||||
commentary: Use test-fix-agent to validate implementation through comprehensive test execution.
|
||||
|
||||
- Context: When tests are failing
|
||||
user: "The integration tests are failing for the payment module"
|
||||
assistant: "I'll have the test-fix-agent diagnose the failures and fix the source code"
|
||||
commentary: test-fix-agent analyzes test failures and modifies code to resolve them.
|
||||
|
||||
- Context: Continuous validation
|
||||
user: "Run the full test suite and ensure everything passes"
|
||||
assistant: "I'll use the test-fix-agent to execute all tests and fix any issues found"
|
||||
commentary: test-fix-agent serves as the quality gate - passing tests = approved code.
|
||||
model: sonnet
|
||||
color: green
|
||||
---
|
||||
|
||||
You are a specialized **Test Execution & Fix Agent**. Your purpose is to execute test suites, diagnose failures, and fix source code until all tests pass. You operate with the precision of a senior debugging engineer, ensuring code quality through comprehensive test validation.
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
**"Tests Are the Review"** - When all tests pass, the code is approved and ready. No separate review process is needed.
|
||||
|
||||
## Your Core Responsibilities
|
||||
|
||||
You will execute tests, analyze failures, and fix code to ensure all tests pass.
|
||||
|
||||
### Test Execution & Fixing Responsibilities:
|
||||
1. **Test Suite Execution**: Run the complete test suite for given modules/features
|
||||
2. **Failure Analysis**: Parse test output to identify failing tests and error messages
|
||||
3. **Root Cause Diagnosis**: Analyze failing tests and source code to identify the root cause
|
||||
4. **Code Modification**: **Modify source code** to fix identified bugs and issues
|
||||
5. **Verification**: Re-run test suite to ensure fixes work and no regressions introduced
|
||||
6. **Approval Certification**: When all tests pass, certify code as approved
|
||||
|
||||
## Execution Process
|
||||
|
||||
### 1. Context Assessment & Test Discovery
|
||||
- Analyze task context to identify test files and source code paths
|
||||
- Load test framework configuration (Jest, Pytest, Mocha, etc.)
|
||||
- Identify test command from project configuration
|
||||
|
||||
```bash
|
||||
# Detect test framework and command
|
||||
if [ -f "package.json" ]; then
|
||||
TEST_CMD=$(cat package.json | jq -r '.scripts.test')
|
||||
elif [ -f "pytest.ini" ] || [ -f "setup.py" ]; then
|
||||
TEST_CMD="pytest"
|
||||
fi
|
||||
```
|
||||
|
||||
### 2. Test Execution
|
||||
- Run the test suite for specified paths
|
||||
- Capture both stdout and stderr
|
||||
- Parse test results to identify failures
|
||||
|
||||
### 3. Failure Diagnosis & Fixing Loop
|
||||
```
|
||||
WHILE tests are failing:
|
||||
1. Analyze failure output
|
||||
2. Identify root cause in source code
|
||||
3. Modify source code to fix issue
|
||||
4. Re-run affected tests
|
||||
5. Verify fix doesn't break other tests
|
||||
END WHILE
|
||||
```
|
||||
|
||||
### 4. Code Quality Certification
|
||||
- All tests pass → Code is APPROVED ✅
|
||||
- Generate summary documenting:
|
||||
- Issues found
|
||||
- Fixes applied
|
||||
- Final test results
|
||||
|
||||
## Fixing Criteria
|
||||
|
||||
### Bug Identification
|
||||
- Logic errors causing test failures
|
||||
- Edge cases not handled properly
|
||||
- Integration issues between components
|
||||
- Incorrect error handling
|
||||
- Resource management problems
|
||||
|
||||
### Code Modification Approach
|
||||
- **Minimal changes**: Fix only what's needed
|
||||
- **Preserve functionality**: Don't change working code
|
||||
- **Follow patterns**: Use existing code conventions
|
||||
- **Test-driven fixes**: Let tests guide the solution
|
||||
|
||||
### Verification Standards
|
||||
- All tests pass without errors
|
||||
- No new test failures introduced
|
||||
- Performance remains acceptable
|
||||
- Code follows project conventions
|
||||
|
||||
## Output Format
|
||||
|
||||
When you complete a test-fix task, provide:
|
||||
|
||||
```markdown
|
||||
# Test-Fix Summary: [Task-ID] [Feature Name]
|
||||
|
||||
## Execution Results
|
||||
|
||||
### Initial Test Run
|
||||
- **Total Tests**: [count]
|
||||
- **Passed**: [count]
|
||||
- **Failed**: [count]
|
||||
- **Errors**: [count]
|
||||
|
||||
## Issues Found & Fixed
|
||||
|
||||
### Issue 1: [Description]
|
||||
- **Test**: `tests/auth/login.test.ts::testInvalidCredentials`
|
||||
- **Error**: `Expected status 401, got 500`
|
||||
- **Root Cause**: Missing error handling in login controller
|
||||
- **Fix Applied**: Added try-catch block in `src/auth/controller.ts:45`
|
||||
- **Files Modified**: `src/auth/controller.ts`
|
||||
|
||||
### Issue 2: [Description]
|
||||
- **Test**: `tests/payment/process.test.ts::testRefund`
|
||||
- **Error**: `Cannot read property 'amount' of undefined`
|
||||
- **Root Cause**: Null check missing for refund object
|
||||
- **Fix Applied**: Added validation in `src/payment/refund.ts:78`
|
||||
- **Files Modified**: `src/payment/refund.ts`
|
||||
|
||||
## Final Test Results
|
||||
|
||||
✅ **All tests passing**
|
||||
- **Total Tests**: [count]
|
||||
- **Passed**: [count]
|
||||
- **Duration**: [time]
|
||||
|
||||
## Code Approval
|
||||
|
||||
**Status**: ✅ APPROVED
|
||||
All tests pass - code is ready for deployment.
|
||||
|
||||
## Files Modified
|
||||
- `src/auth/controller.ts`: Added error handling
|
||||
- `src/payment/refund.ts`: Added null validation
|
||||
```
|
||||
|
||||
## Important Reminders
|
||||
|
||||
**ALWAYS:**
|
||||
- **Execute tests first** - Understand what's failing before fixing
|
||||
- **Diagnose thoroughly** - Find root cause, not just symptoms
|
||||
- **Fix minimally** - Change only what's needed to pass tests
|
||||
- **Verify completely** - Run full suite after each fix
|
||||
- **Document fixes** - Explain what was changed and why
|
||||
- **Certify approval** - When tests pass, code is approved
|
||||
|
||||
**NEVER:**
|
||||
- Skip test execution - always run tests first
|
||||
- Make changes without understanding the failure
|
||||
- Fix symptoms without addressing root cause
|
||||
- Break existing passing tests
|
||||
- Skip final verification
|
||||
- Leave tests failing - must achieve 100% pass rate
|
||||
|
||||
## Quality Certification
|
||||
|
||||
**Your ultimate responsibility**: Ensure all tests pass. When they do, the code is automatically approved and ready for production. You are the final quality gate.
|
||||
|
||||
**Tests passing = Code approved = Mission complete** ✅
|
||||
@@ -88,8 +88,9 @@ Files updated: .task/IMPL-1.json + 2 subtask files + TODO_LIST.md
|
||||
### Agent Assignment
|
||||
- **Design/Planning** → `@planning-agent`
|
||||
- **Implementation** → `@code-developer`
|
||||
- **Testing** → `@code-review-test-agent`
|
||||
- **Review** → `@review-agent`
|
||||
- **Testing** → `@code-developer` (type: "test-gen")
|
||||
- **Test Validation** → `@test-fix-agent` (type: "test-fix")
|
||||
- **Review** → `@general-purpose` (optional)
|
||||
|
||||
### Context Inheritance
|
||||
- Subtasks inherit parent requirements
|
||||
@@ -161,8 +162,8 @@ See @~/.claude/workflows/workflow-architecture.md for:
|
||||
|
||||
▸ impl-1: Build authentication (container)
|
||||
├── impl-1.1: Design schema → @planning-agent
|
||||
├── impl-1.2: Implement logic → @code-developer
|
||||
└── impl-1.3: Write tests → @code-review-test-agent
|
||||
├── impl-1.2: Implement logic + tests → @code-developer
|
||||
└── impl-1.3: Execute & fix tests → @test-fix-agent
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
@@ -107,8 +107,9 @@ Tasks inherit from:
|
||||
Based on task type and title keywords:
|
||||
- **Build/Implement** → @code-developer
|
||||
- **Design/Plan** → @planning-agent
|
||||
- **Test/Validate** → @code-review-test-agent
|
||||
- **Review/Audit** → @review-agent`
|
||||
- **Test Generation** → @code-developer (type: "test-gen")
|
||||
- **Test Execution/Fix** → @test-fix-agent (type: "test-fix")
|
||||
- **Review/Audit** → @general-purpose (optional, only when explicitly requested)
|
||||
|
||||
## Validation Rules
|
||||
|
||||
|
||||
@@ -24,8 +24,8 @@ examples:
|
||||
- Executes step-by-step, requiring user confirmation at each checkpoint.
|
||||
- Allows for dynamic adjustments and manual review during the process.
|
||||
- **review**
|
||||
- Executes under the supervision of a `@review-agent`.
|
||||
- Performs quality checks and provides detailed feedback at each step.
|
||||
- Optional manual review using `@general-purpose`.
|
||||
- Used only when explicitly requested by user.
|
||||
|
||||
### 🤖 **Agent Selection Logic**
|
||||
|
||||
@@ -45,10 +45,12 @@ FUNCTION select_agent(task, agent_override):
|
||||
RETURN "@code-developer"
|
||||
WHEN CONTAINS "Design schema", "Plan":
|
||||
RETURN "@planning-agent"
|
||||
WHEN CONTAINS "Write tests":
|
||||
RETURN "@code-review-test-agent"
|
||||
WHEN CONTAINS "Write tests", "Generate tests":
|
||||
RETURN "@code-developer" // type: test-gen
|
||||
WHEN CONTAINS "Execute tests", "Fix tests", "Validate":
|
||||
RETURN "@test-fix-agent" // type: test-fix
|
||||
WHEN CONTAINS "Review code":
|
||||
RETURN "@review-agent"
|
||||
RETURN "@general-purpose" // Optional manual review
|
||||
DEFAULT:
|
||||
RETURN "@code-developer" // Default agent
|
||||
END CASE
|
||||
@@ -232,13 +234,15 @@ Different agents receive context tailored to their function, including implement
|
||||
- Implementation risks and mitigation strategies
|
||||
- Architecture implications from implementation.context_notes
|
||||
|
||||
**`@code-review-test-agent`**:
|
||||
- Files to test from implementation.files[].path
|
||||
- Logic flows to validate from implementation.modifications.logic_flow
|
||||
- Error conditions to test from implementation.context_notes.error_handling
|
||||
- Performance benchmarks from implementation.context_notes.performance_considerations
|
||||
**`@test-fix-agent`**:
|
||||
- Test files to execute from task.context.focus_paths
|
||||
- Source files to fix from implementation.files[].path
|
||||
- Expected behaviors from implementation.modifications.logic_flow
|
||||
- Error conditions to validate from implementation.context_notes.error_handling
|
||||
- Performance requirements from implementation.context_notes.performance_considerations
|
||||
|
||||
**`@review-agent`**:
|
||||
**`@general-purpose`**:
|
||||
- Used for optional manual reviews when explicitly requested
|
||||
- Code quality standards and implementation patterns
|
||||
- Security considerations from implementation.context_notes.risks
|
||||
- Dependency validation from implementation.context_notes.dependencies
|
||||
|
||||
@@ -185,9 +185,9 @@ TodoWrite({
|
||||
activeForm: "Executing IMPL-1.2: Implement auth logic"
|
||||
},
|
||||
{
|
||||
content: "Execute IMPL-2: Review implementations [code-review-agent]",
|
||||
content: "Execute TEST-FIX-1: Validate implementation tests [test-fix-agent]",
|
||||
status: "pending",
|
||||
activeForm: "Executing IMPL-2: Review implementations"
|
||||
activeForm: "Executing TEST-FIX-1: Validate implementation tests"
|
||||
}
|
||||
]
|
||||
});
|
||||
@@ -384,8 +384,8 @@ Task(subagent_type="{meta.agent}",
|
||||
"title": "Task title",
|
||||
"status": "pending|active|completed|blocked",
|
||||
"meta": {
|
||||
"type": "feature|bugfix|refactor|test|docs",
|
||||
"agent": "@code-developer|@planning-agent|@code-review-test-agent"
|
||||
"type": "feature|bugfix|refactor|test-gen|test-fix|docs",
|
||||
"agent": "@code-developer|@test-fix-agent|@general-purpose"
|
||||
},
|
||||
"context": {
|
||||
"requirements": ["req1", "req2"],
|
||||
@@ -451,8 +451,9 @@ Task(subagent_type="{meta.agent}",
|
||||
meta.agent specified → Use specified agent
|
||||
meta.agent missing → Infer from meta.type:
|
||||
- "feature" → @code-developer
|
||||
- "test" → @code-review-test-agent
|
||||
- "review" → @code-review-agent
|
||||
- "test-gen" → @code-developer
|
||||
- "test-fix" → @test-fix-agent
|
||||
- "review" → @general-purpose
|
||||
- "docs" → @doc-generator
|
||||
```
|
||||
|
||||
|
||||
@@ -1,85 +1,272 @@
|
||||
---
|
||||
name: review
|
||||
description: Execute review phase for quality validation
|
||||
usage: /workflow:review
|
||||
argument-hint: none
|
||||
description: Optional specialized review (security, architecture, docs) for completed implementation
|
||||
usage: /workflow:review [--type=<type>] [session-id]
|
||||
argument-hint: "[--type=security|architecture|action-items|quality] [session-id]"
|
||||
examples:
|
||||
- /workflow:review
|
||||
- /workflow:review # Quality review of active session
|
||||
- /workflow:review --type=security # Security audit of active session
|
||||
- /workflow:review --type=architecture WFS-user-auth # Architecture review of specific session
|
||||
- /workflow:review --type=action-items # Pre-deployment verification
|
||||
---
|
||||
|
||||
# Workflow Review Command (/workflow:review)
|
||||
### 🚀 Command Overview: `/workflow:review`
|
||||
|
||||
## Overview
|
||||
Final phase for quality validation, testing, and completion.
|
||||
**Optional specialized review** for completed implementations. In the standard workflow, **passing tests = approved code**. Use this command only when specialized review is required (security, architecture, compliance, docs).
|
||||
|
||||
## Core Principles
|
||||
**Session Management:** @~/.claude/workflows/workflow-architecture.md
|
||||
## Philosophy: "Tests Are the Review"
|
||||
|
||||
## Review Process
|
||||
- ✅ **Default**: All tests pass → Code approved
|
||||
- 🔍 **Optional**: Specialized reviews for:
|
||||
- 🔒 Security audits (vulnerabilities, auth/authz)
|
||||
- 🏗️ Architecture compliance (patterns, technical debt)
|
||||
- 📋 Action items verification (requirements met, acceptance criteria)
|
||||
|
||||
1. **Validation Checks**
|
||||
- All tasks completed
|
||||
- Tests passing
|
||||
- Code quality metrics
|
||||
- Documentation complete
|
||||
## Review Types
|
||||
|
||||
2. **Generate Review Report**
|
||||
| Type | Focus | Use Case |
|
||||
|------|-------|----------|
|
||||
| `quality` | Code quality, best practices, maintainability | Default general review |
|
||||
| `security` | Security vulnerabilities, data handling, access control | Security audits |
|
||||
| `architecture` | Architectural patterns, technical debt, design decisions | Architecture compliance |
|
||||
| `action-items` | Requirements met, acceptance criteria verified, action items completed | Pre-deployment verification |
|
||||
|
||||
**Notes**:
|
||||
- For documentation generation, use `/workflow:tools:docs`
|
||||
- For CLAUDE.md updates, use `/update-memory-related`
|
||||
|
||||
## Execution Template
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# Optional specialized review for completed implementation
|
||||
|
||||
# Step 1: Session ID resolution
|
||||
if [ -n "$SESSION_ARG" ]; then
|
||||
sessionId="$SESSION_ARG"
|
||||
else
|
||||
sessionId=$(find .workflow/ -name '.active-*' | head -1 | sed 's/.*active-//')
|
||||
fi
|
||||
|
||||
# Step 2: Validation
|
||||
if [ ! -d ".workflow/${sessionId}" ]; then
|
||||
echo "❌ Session ${sessionId} not found"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Check for completed tasks
|
||||
if [ ! -d ".workflow/${sessionId}/.summaries" ] || [ -z "$(ls .workflow/${sessionId}/.summaries/IMPL-*.md 2>/dev/null)" ]; then
|
||||
echo "❌ No completed implementation found. Complete implementation first"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Step 3: Determine review type (default: quality)
|
||||
review_type="${TYPE_ARG:-quality}"
|
||||
|
||||
# Redirect docs review to specialized command
|
||||
if [ "$review_type" = "docs" ]; then
|
||||
echo "💡 For documentation generation, please use:"
|
||||
echo " /workflow:tools:docs"
|
||||
echo ""
|
||||
echo "The docs command provides:"
|
||||
echo " - Hierarchical architecture documentation"
|
||||
echo " - API documentation generation"
|
||||
echo " - Documentation structure analysis"
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# Step 4: Analysis handover → Model takes control
|
||||
# BASH_EXECUTION_STOPS → MODEL_ANALYSIS_BEGINS
|
||||
```
|
||||
|
||||
### 🧠 Model Analysis Phase
|
||||
|
||||
After bash validation, the model takes control to:
|
||||
|
||||
1. **Load Context**: Read completed task summaries and changed files
|
||||
```bash
|
||||
# Load implementation summaries
|
||||
cat .workflow/${sessionId}/.summaries/IMPL-*.md
|
||||
|
||||
# Load test results (if available)
|
||||
cat .workflow/${sessionId}/.summaries/TEST-FIX-*.md 2>/dev/null
|
||||
|
||||
# Get changed files
|
||||
git log --since="$(cat .workflow/${sessionId}/workflow-session.json | jq -r .created_at)" --name-only --pretty=format: | sort -u
|
||||
```
|
||||
|
||||
2. **Perform Specialized Review**: Based on `review_type`
|
||||
|
||||
**Security Review** (`--type=security`):
|
||||
- Use MCP code search for security patterns:
|
||||
```bash
|
||||
mcp__code-index__search_code_advanced(pattern="password|token|secret|auth", file_pattern="*.{ts,js,py}")
|
||||
mcp__code-index__search_code_advanced(pattern="eval|exec|innerHTML|dangerouslySetInnerHTML", file_pattern="*.{ts,js,tsx}")
|
||||
```
|
||||
- Use Gemini for security analysis:
|
||||
```bash
|
||||
cd .workflow/${sessionId} && ~/.claude/scripts/gemini-wrapper -p "
|
||||
PURPOSE: Security audit of completed implementation
|
||||
TASK: Review code for security vulnerabilities, insecure patterns, auth/authz issues
|
||||
CONTEXT: @{.summaries/IMPL-*.md,../..,../../CLAUDE.md}
|
||||
EXPECTED: Security findings report with severity levels
|
||||
RULES: Focus on OWASP Top 10, authentication, authorization, data validation, injection risks
|
||||
" --approval-mode yolo
|
||||
```
|
||||
|
||||
**Architecture Review** (`--type=architecture`):
|
||||
- Use Qwen for architecture analysis:
|
||||
```bash
|
||||
cd .workflow/${sessionId} && ~/.claude/scripts/qwen-wrapper -p "
|
||||
PURPOSE: Architecture compliance review
|
||||
TASK: Evaluate adherence to architectural patterns, identify technical debt, review design decisions
|
||||
CONTEXT: @{.summaries/IMPL-*.md,../..,../../CLAUDE.md}
|
||||
EXPECTED: Architecture assessment with recommendations
|
||||
RULES: Check for patterns, separation of concerns, modularity, scalability
|
||||
" --approval-mode yolo
|
||||
```
|
||||
|
||||
**Quality Review** (`--type=quality`):
|
||||
- Use Gemini for code quality:
|
||||
```bash
|
||||
cd .workflow/${sessionId} && ~/.claude/scripts/gemini-wrapper -p "
|
||||
PURPOSE: Code quality and best practices review
|
||||
TASK: Assess code readability, maintainability, adherence to best practices
|
||||
CONTEXT: @{.summaries/IMPL-*.md,../..,../../CLAUDE.md}
|
||||
EXPECTED: Quality assessment with improvement suggestions
|
||||
RULES: Check for code smells, duplication, complexity, naming conventions
|
||||
" --approval-mode yolo
|
||||
```
|
||||
|
||||
**Action Items Review** (`--type=action-items`):
|
||||
- Verify all requirements and acceptance criteria met:
|
||||
```bash
|
||||
# Load task requirements and acceptance criteria
|
||||
find .workflow/${sessionId}/.task -name "IMPL-*.json" -exec jq -r '
|
||||
"Task: " + .id + "\n" +
|
||||
"Requirements: " + (.context.requirements | join(", ")) + "\n" +
|
||||
"Acceptance: " + (.context.acceptance | join(", "))
|
||||
' {} \;
|
||||
|
||||
# Check implementation summaries against requirements
|
||||
cd .workflow/${sessionId} && ~/.claude/scripts/gemini-wrapper -p "
|
||||
PURPOSE: Verify all requirements and acceptance criteria are met
|
||||
TASK: Cross-check implementation summaries against original requirements
|
||||
CONTEXT: @{.task/IMPL-*.json,.summaries/IMPL-*.md,../..,../../CLAUDE.md}
|
||||
EXPECTED:
|
||||
- Requirements coverage matrix
|
||||
- Acceptance criteria verification
|
||||
- Missing/incomplete action items
|
||||
- Pre-deployment readiness assessment
|
||||
RULES:
|
||||
- Check each requirement has corresponding implementation
|
||||
- Verify all acceptance criteria are met
|
||||
- Flag any incomplete or missing action items
|
||||
- Assess deployment readiness
|
||||
" --approval-mode yolo
|
||||
```
|
||||
|
||||
|
||||
3. **Generate Review Report**: Create structured report
|
||||
```markdown
|
||||
# Review Report
|
||||
# Review Report: ${review_type}
|
||||
|
||||
## Task Completion
|
||||
- Total: 10
|
||||
- Completed: 10
|
||||
- Success Rate: 100%
|
||||
**Session**: ${sessionId}
|
||||
**Date**: $(date)
|
||||
**Type**: ${review_type}
|
||||
|
||||
## Quality Metrics
|
||||
- Test Coverage: 85%
|
||||
- Code Quality: A
|
||||
- Documentation: Complete
|
||||
## Summary
|
||||
- Tasks Reviewed: [count IMPL tasks]
|
||||
- Files Changed: [count files]
|
||||
- Severity: [High/Medium/Low]
|
||||
|
||||
## Issues Found
|
||||
- Minor: 2
|
||||
- Major: 0
|
||||
- Critical: 0
|
||||
## Findings
|
||||
|
||||
### Critical Issues
|
||||
- [Issue 1 with file:line reference]
|
||||
- [Issue 2 with file:line reference]
|
||||
|
||||
### Recommendations
|
||||
- [Recommendation 1]
|
||||
- [Recommendation 2]
|
||||
|
||||
### Positive Observations
|
||||
- [Good pattern observed]
|
||||
|
||||
## Action Items
|
||||
- [ ] [Action 1]
|
||||
- [ ] [Action 2]
|
||||
```
|
||||
|
||||
3. **Update Session**
|
||||
```json
|
||||
{
|
||||
"current_phase": "REVIEW",
|
||||
"phases": {
|
||||
"REVIEW": {
|
||||
"status": "completed",
|
||||
"output": "REVIEW.md",
|
||||
"test_results": {
|
||||
"passed": 45,
|
||||
"failed": 0,
|
||||
"coverage": 85
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
4. **Output Files**:
|
||||
```bash
|
||||
# Save review report
|
||||
Write(.workflow/${sessionId}/REVIEW-${review_type}.md)
|
||||
|
||||
# Update session metadata
|
||||
# (optional) Update workflow-session.json with review status
|
||||
```
|
||||
|
||||
## Auto-fix (Default)
|
||||
Auto-fix is enabled by default:
|
||||
- Automatically fixes minor issues
|
||||
- Runs formatters and linters
|
||||
- Updates documentation
|
||||
- Re-runs tests
|
||||
5. **Optional: Update Memory** (if docs review or significant findings):
|
||||
```bash
|
||||
# If architecture or quality issues found, suggest memory update
|
||||
if [ "$review_type" = "architecture" ] || [ "$review_type" = "quality" ]; then
|
||||
echo "💡 Consider updating project documentation:"
|
||||
echo " /update-memory-related"
|
||||
fi
|
||||
```
|
||||
|
||||
## Completion Criteria
|
||||
- All tasks marked complete
|
||||
- Tests passing (configurable threshold)
|
||||
- No critical issues
|
||||
- Documentation updated
|
||||
## Usage Examples
|
||||
|
||||
## Output Files
|
||||
- `REVIEW.md` - Review report
|
||||
- `workflow-session.json` - Updated with results
|
||||
- `test-results.json` - Detailed test output
|
||||
```bash
|
||||
# General quality review after implementation
|
||||
/workflow:review
|
||||
|
||||
# Security audit before deployment
|
||||
/workflow:review --type=security
|
||||
|
||||
# Architecture review for specific session
|
||||
/workflow:review --type=architecture WFS-payment-integration
|
||||
|
||||
# Documentation review
|
||||
/workflow:review --type=docs
|
||||
```
|
||||
|
||||
## ✨ Features
|
||||
|
||||
- **Simple Validation**: Check session exists and has completed tasks
|
||||
- **No Complex Orchestration**: Direct analysis, no multi-phase pipeline
|
||||
- **Specialized Reviews**: Different prompts and tools for different review types
|
||||
- **MCP Integration**: Fast code search for security and architecture patterns
|
||||
- **CLI Tool Integration**: Gemini for analysis, Qwen for architecture
|
||||
- **Structured Output**: Markdown reports with severity levels and action items
|
||||
- **Optional Memory Update**: Suggests documentation updates for significant findings
|
||||
|
||||
## Integration with Workflow
|
||||
|
||||
```
|
||||
Standard Workflow:
|
||||
plan → execute → test-gen → execute ✅
|
||||
|
||||
Optional Review (when needed):
|
||||
plan → execute → test-gen → execute → review (security/architecture/docs)
|
||||
```
|
||||
|
||||
**When to Use**:
|
||||
- Before production deployment (security review + action-items review)
|
||||
- After major feature (architecture review)
|
||||
- Before code freeze (quality review)
|
||||
- Pre-deployment verification (action-items review)
|
||||
|
||||
**When NOT to Use**:
|
||||
- Regular development (tests are sufficient)
|
||||
- Simple bug fixes (test-fix-agent handles it)
|
||||
- Minor changes (update-memory-related is enough)
|
||||
|
||||
## Related Commands
|
||||
- `/workflow:execute` - Must complete first
|
||||
- `/task:status` - Check task completion
|
||||
- `/workflow:status` - View overall status
|
||||
|
||||
- `/workflow:execute` - Must complete implementation first
|
||||
- `/workflow:test-gen` - Primary quality gate (tests)
|
||||
- `/workflow:tools:docs` - Generate hierarchical documentation (use instead of `--type=docs`)
|
||||
- `/update-memory-related` - Update CLAUDE.md docs after architecture findings
|
||||
- `/workflow:status` - Check session status
|
||||
|
||||
@@ -1,145 +1,365 @@
|
||||
---
|
||||
name: test-gen
|
||||
description: Generate comprehensive test workflow based on completed implementation tasks
|
||||
description: Orchestrate test-fix workflow by analyzing implementation and generating TEST-FIX tasks
|
||||
usage: /workflow:test-gen [session-id]
|
||||
argument-hint: "WFS-session-id"
|
||||
argument-hint: "[session-id]"
|
||||
examples:
|
||||
- /workflow:test-gen
|
||||
- /workflow:test-gen WFS-user-auth
|
||||
allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*)
|
||||
---
|
||||
|
||||
# Workflow Test Generation Command
|
||||
# Workflow Test Generation Command (/workflow:test-gen)
|
||||
|
||||
## Overview
|
||||
Analyzes completed implementation sessions and generates comprehensive test requirements, then calls workflow:plan to create test workflow.
|
||||
## Coordinator Role
|
||||
|
||||
## Usage
|
||||
```bash
|
||||
/workflow:test-gen # Auto-detect active session
|
||||
/workflow:test-gen WFS-session-id # Analyze specific session
|
||||
**This command is a pure orchestrator**: Analyze completed implementation session, generate test-fix workflow through standardized tool commands, and trigger automated test validation.
|
||||
|
||||
**Execution Flow**:
|
||||
1. Initialize TodoWrite → Execute Phase 1 → Parse output → Update TodoWrite
|
||||
2. Execute Phase 2 with Phase 1 data → Parse output → Update TodoWrite
|
||||
3. Execute Phase 3 with Phase 2 data → Parse output → Update TodoWrite
|
||||
4. Execute Phase 4 with Phase 3 validation → Update TodoWrite → Return summary
|
||||
|
||||
## Core Rules
|
||||
|
||||
1. **Start Immediately**: First action is TodoWrite initialization, second action is Phase 1 session discovery
|
||||
2. **No Preliminary Analysis**: Do not read files or analyze before Phase 1
|
||||
3. **Parse Every Output**: Extract required data from each phase for next phase
|
||||
4. **Sequential Execution**: Each phase depends on previous phase's output
|
||||
5. **Complete All Phases**: Do not return to user until Phase 4 completes
|
||||
6. **Track Progress**: Update TodoWrite after every phase completion
|
||||
7. **Use Standard Tools**: Follow plan.md pattern using context-gather, concept-enhanced, task-generate
|
||||
|
||||
## 4-Phase Execution
|
||||
|
||||
### Phase 1: Session Discovery & Context Gathering
|
||||
**Command**: `SlashCommand(command="/workflow:tools:context-gather --session [sessionId] \"TEST-FIX: Validate implementation for [sessionId]\"")`
|
||||
|
||||
**Session ID Resolution**:
|
||||
- If argument provided → Use directly as `sessionId`
|
||||
- If no argument → Auto-detect from `.workflow/.active-*` marker
|
||||
- Format: `WFS-[session-name]`
|
||||
|
||||
**Task Description Structure**:
|
||||
```
|
||||
GOAL: Execute and validate all tests for completed implementation
|
||||
SCOPE: Test execution, failure diagnosis, code fixing
|
||||
CONTEXT: Implementation session [sessionId] with completed IMPL tasks
|
||||
```
|
||||
|
||||
## Dynamic Session ID Resolution
|
||||
**Parse Output**:
|
||||
- Extract: context package path (store as `contextPath`)
|
||||
- Typical pattern: `.workflow/[sessionId]/.process/context-package-test.json`
|
||||
|
||||
The `${SESSION_ID}` variable is dynamically resolved based on:
|
||||
**Validation**:
|
||||
- Session directory `.workflow/[sessionId]/` exists
|
||||
- Session has completed IMPL tasks (check .summaries/IMPL-*-summary.md)
|
||||
- Context package created successfully
|
||||
|
||||
1. **Command argument**: If session-id provided as argument, use it directly
|
||||
2. **Auto-detection**: If no argument, detect from active session markers
|
||||
3. **Format**: Always in format `WFS-session-name`
|
||||
**TodoWrite**: Mark phase 1 completed, phase 2 in_progress
|
||||
|
||||
```bash
|
||||
# Example resolution logic:
|
||||
# If argument provided: SESSION_ID = "WFS-user-auth"
|
||||
# If no argument: SESSION_ID = $(find .workflow/ -name '.active-*' | head -1 | sed 's/.*active-//')
|
||||
---
|
||||
|
||||
### Phase 2: Implementation Analysis
|
||||
**Command**: `SlashCommand(command="/workflow:tools:concept-enhanced --session [sessionId] --context [contextPath]")`
|
||||
|
||||
**Input**: `sessionId` from Phase 1, `contextPath` from Phase 1
|
||||
|
||||
**Expected Analysis**:
|
||||
- Review completed implementation summaries
|
||||
- Identify test files and coverage gaps
|
||||
- Assess test execution strategy
|
||||
- Determine failure diagnosis approach
|
||||
|
||||
**Parse Output**:
|
||||
- Verify `.workflow/[sessionId]/.process/ANALYSIS_RESULTS.md` created
|
||||
- Extract test execution recommendations
|
||||
- Identify critical test areas
|
||||
|
||||
**Validation**:
|
||||
- File `.workflow/[sessionId]/.process/ANALYSIS_RESULTS.md` exists
|
||||
- Contains test strategy and execution plan
|
||||
- Lists focus test paths and acceptance criteria
|
||||
|
||||
**TodoWrite**: Mark phase 2 completed, phase 3 in_progress
|
||||
|
||||
---
|
||||
|
||||
### Phase 3: TEST-FIX Task Generation
|
||||
**Command**: `SlashCommand(command="/workflow:tools:task-generate --session [sessionId]")`
|
||||
|
||||
**Input**: `sessionId` from Phase 1
|
||||
|
||||
**Expected Behavior**:
|
||||
- Parse ANALYSIS_RESULTS.md for test requirements
|
||||
- Generate TEST-FIX-001.json with:
|
||||
- `meta.type: "test-fix"`
|
||||
- `meta.agent: "@test-fix-agent"`
|
||||
- `context.requirements`: Test execution requirements
|
||||
- `context.focus_paths`: Test files and source files
|
||||
- `context.acceptance`: All tests pass criteria
|
||||
- `flow_control.pre_analysis`: Load implementation summaries
|
||||
- `flow_control.implementation_approach`: Test execution strategy
|
||||
|
||||
**Parse Output**:
|
||||
- Verify `.workflow/[sessionId]/.task/TEST-FIX-001.json` exists
|
||||
- Verify `.workflow/[sessionId]/IMPL_PLAN.md` updated
|
||||
- Verify `.workflow/[sessionId]/TODO_LIST.md` updated
|
||||
|
||||
**Validation**:
|
||||
- Task JSON has correct structure (id, meta.type="test-fix", meta.agent="@test-fix-agent")
|
||||
- IMPL_PLAN.md contains test-fix strategy
|
||||
- TODO_LIST.md shows TEST-FIX-001 task
|
||||
|
||||
**TodoWrite**: Mark phase 3 completed, phase 4 in_progress
|
||||
|
||||
---
|
||||
|
||||
### Phase 4: Execute Test-Fix Workflow
|
||||
**Command**: `SlashCommand(command="/workflow:execute --session [sessionId]")`
|
||||
|
||||
**Input**: `sessionId` from Phase 1
|
||||
|
||||
**Expected Behavior**:
|
||||
- Workflow executor detects TEST-FIX-001 task
|
||||
- Assigns to @test-fix-agent
|
||||
- Agent executes tests using flow_control.pre_analysis
|
||||
- If failures: diagnoses and fixes code
|
||||
- Re-runs tests until all pass
|
||||
- Generates completion summary
|
||||
|
||||
**Validation**:
|
||||
- Workflow execution started successfully
|
||||
- TEST-FIX-001 task status updated to "active" or "completed"
|
||||
|
||||
**TodoWrite**: Mark phase 4 completed
|
||||
|
||||
**Return to User**:
|
||||
```
|
||||
Test-fix workflow initiated for session: [sessionId]
|
||||
- TEST-FIX-001 created and executing
|
||||
- @test-fix-agent validating implementation
|
||||
- Progress: /workflow:status [sessionId]
|
||||
```
|
||||
|
||||
## Implementation Flow
|
||||
---
|
||||
|
||||
### Step 1: Identify Target Session
|
||||
```bash
|
||||
# Auto-detect active session (if no session-id provided)
|
||||
find .workflow/ -name '.active-*' | head -1 | sed 's/.*active-//'
|
||||
## TodoWrite Pattern
|
||||
|
||||
# Use provided session-id or detected session-id
|
||||
# SESSION_ID = provided argument OR detected active session
|
||||
```javascript
|
||||
// Initialize (before Phase 1)
|
||||
TodoWrite({todos: [
|
||||
{"content": "Execute context gathering for test-fix", "status": "in_progress", "activeForm": "Executing context gathering for test-fix"},
|
||||
{"content": "Execute implementation analysis", "status": "pending", "activeForm": "Executing implementation analysis"},
|
||||
{"content": "Execute TEST-FIX task generation", "status": "pending", "activeForm": "Executing TEST-FIX task generation"},
|
||||
{"content": "Execute test-fix workflow", "status": "pending", "activeForm": "Executing test-fix workflow"}
|
||||
]})
|
||||
|
||||
// After Phase 1
|
||||
TodoWrite({todos: [
|
||||
{"content": "Execute context gathering for test-fix", "status": "completed", "activeForm": "Executing context gathering for test-fix"},
|
||||
{"content": "Execute implementation analysis", "status": "in_progress", "activeForm": "Executing implementation analysis"},
|
||||
{"content": "Execute TEST-FIX task generation", "status": "pending", "activeForm": "Executing TEST-FIX task generation"},
|
||||
{"content": "Execute test-fix workflow", "status": "pending", "activeForm": "Executing test-fix workflow"}
|
||||
]})
|
||||
|
||||
// Continue pattern for Phase 2, 3, 4...
|
||||
```
|
||||
|
||||
### Step 2: Get Session Start Time
|
||||
```bash
|
||||
cat .workflow/WFS-${SESSION_ID}/workflow-session.json | jq -r .created_at
|
||||
## Data Flow
|
||||
|
||||
```
|
||||
Session ID (from argument or auto-detect)
|
||||
↓
|
||||
Phase 1: context-gather --session sessionId "test-fix description"
|
||||
↓ Output: contextPath (context-package-test.json)
|
||||
↓
|
||||
Phase 2: concept-enhanced --session sessionId --context contextPath
|
||||
↓ Input: sessionId + contextPath
|
||||
↓ Output: ANALYSIS_RESULTS.md (test execution strategy)
|
||||
↓
|
||||
Phase 3: task-generate --session sessionId
|
||||
↓ Input: sessionId + ANALYSIS_RESULTS.md
|
||||
↓ Output: TEST-FIX-001.json, IMPL_PLAN.md, TODO_LIST.md
|
||||
↓
|
||||
Phase 4: execute --session sessionId
|
||||
↓ Input: sessionId + TEST-FIX-001.json
|
||||
↓ Output: Test execution and fixing
|
||||
↓
|
||||
Return summary to user
|
||||
```
|
||||
|
||||
### Step 3: Git Change Analysis (using session start time)
|
||||
```bash
|
||||
git log --since="$(cat .workflow/WFS-${SESSION_ID}/workflow-session.json | jq -r .created_at)" --name-only --pretty=format: | sort -u | grep -v '^$'
|
||||
## Context Gathering Customization
|
||||
|
||||
context-gather will analyze:
|
||||
- Completed IMPL task summaries
|
||||
- Git changes since session start
|
||||
- Test files in focus_paths
|
||||
- Implementation files to be tested
|
||||
- Test framework configuration
|
||||
|
||||
## Analysis Focus
|
||||
|
||||
concept-enhanced will analyze:
|
||||
- Test coverage gaps
|
||||
- Test execution strategy (unit, integration, e2e)
|
||||
- Failure diagnosis approaches
|
||||
- Code fixing patterns
|
||||
- Test framework best practices
|
||||
|
||||
## Task Generation Output
|
||||
|
||||
task-generate creates TEST-FIX-001.json with:
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "TEST-FIX-001",
|
||||
"title": "Execute and validate tests for [sessionId]",
|
||||
"status": "pending",
|
||||
"meta": {
|
||||
"type": "test-fix",
|
||||
"agent": "@test-fix-agent"
|
||||
},
|
||||
"context": {
|
||||
"requirements": [
|
||||
"Execute complete test suite for all implemented modules",
|
||||
"Diagnose and fix any test failures",
|
||||
"Ensure all tests pass before completion"
|
||||
],
|
||||
"focus_paths": ["src/**/*.test.ts", "src/**/implementation.ts"],
|
||||
"acceptance": [
|
||||
"All tests pass successfully",
|
||||
"No test failures or errors",
|
||||
"Code is approved and ready for deployment"
|
||||
],
|
||||
"depends_on": [],
|
||||
"artifacts": []
|
||||
},
|
||||
"flow_control": {
|
||||
"pre_analysis": [
|
||||
{
|
||||
"step": "load_implementation_summaries",
|
||||
"action": "Load completed IMPL task summaries",
|
||||
"commands": [
|
||||
"bash(find .workflow/[sessionId]/.summaries/ -name 'IMPL-*-summary.md' 2>/dev/null)",
|
||||
"Read(.workflow/[sessionId]/.summaries/IMPL-001-summary.md)"
|
||||
],
|
||||
"output_to": "implementation_context",
|
||||
"on_error": "skip_optional"
|
||||
},
|
||||
{
|
||||
"step": "analyze_test_files",
|
||||
"action": "Identify test files and coverage",
|
||||
"commands": [
|
||||
"mcp__code-index__find_files(pattern=\"*.test.*\")",
|
||||
"mcp__code-index__search_code_advanced(pattern=\"test|describe|it\", file_pattern=\"*.test.*\")"
|
||||
],
|
||||
"output_to": "test_inventory",
|
||||
"on_error": "fail"
|
||||
}
|
||||
],
|
||||
"implementation_approach": {
|
||||
"task_description": "Execute tests and fix failures until all pass",
|
||||
"modification_points": [
|
||||
"Run test suite using detected framework",
|
||||
"Parse test output to identify failures",
|
||||
"Diagnose root cause of failures",
|
||||
"Modify source code to fix issues",
|
||||
"Re-run tests to verify fixes"
|
||||
],
|
||||
"logic_flow": [
|
||||
"Load implementation context",
|
||||
"Identify test framework and configuration",
|
||||
"Execute complete test suite",
|
||||
"If failures: analyze error messages",
|
||||
"Fix source code based on diagnosis",
|
||||
"Re-run tests",
|
||||
"Repeat until all tests pass"
|
||||
]
|
||||
},
|
||||
"target_files": ["src/**/*.test.ts", "src/**/implementation.ts"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Step 4: Filter Code Files
|
||||
```bash
|
||||
git log --since="$(cat .workflow/WFS-${SESSION_ID}/workflow-session.json | jq -r .created_at)" --name-only --pretty=format: | sort -u | grep -E '\.(js|ts|jsx|tsx|py|java|go|rs)$'
|
||||
## Error Handling
|
||||
|
||||
### Phase 1 Failures
|
||||
- **No session found**: Return error "No active session detected. Provide session-id or run /workflow:plan first"
|
||||
- **Invalid session**: Return error "Session [sessionId] not found or incomplete"
|
||||
- **No implementation**: Return error "No completed IMPL tasks found. Complete implementation first"
|
||||
|
||||
### Phase 2 Failures
|
||||
- **Analysis failed**: Return error "Implementation analysis failed. Check context package"
|
||||
- **No test strategy**: Return error "Could not determine test execution strategy"
|
||||
|
||||
### Phase 3 Failures
|
||||
- **Task generation failed**: Retry once, then return error with details
|
||||
- **Invalid task structure**: Return error with JSON validation details
|
||||
|
||||
### Phase 4 Failures
|
||||
- **Execution failed**: Return error "Could not start test-fix workflow. Check session state"
|
||||
|
||||
## Workflow Integration
|
||||
|
||||
### Complete Flow Example
|
||||
```
|
||||
1. Implementation Phase (prior to test-gen)
|
||||
/workflow:plan "Build auth system"
|
||||
→ @code-developer implements + writes tests
|
||||
→ Creates IMPL-001-summary.md
|
||||
|
||||
2. Test Generation Phase (test-gen)
|
||||
/workflow:test-gen WFS-auth
|
||||
Phase 1: context-gather → Creates context-package-test.json
|
||||
Phase 2: concept-enhanced → Creates ANALYSIS_RESULTS.md
|
||||
Phase 3: task-generate → Creates TEST-FIX-001.json
|
||||
Phase 4: execute → Triggers @test-fix-agent
|
||||
|
||||
3. Test-Fix Phase (automated)
|
||||
@test-fix-agent picks up TEST-FIX-001
|
||||
→ Runs test suite
|
||||
→ Diagnoses failures (if any)
|
||||
→ Fixes source code
|
||||
→ Re-runs tests
|
||||
→ All pass → Code approved ✅
|
||||
```
|
||||
|
||||
### Step 5: Load Session Context
|
||||
```bash
|
||||
cat .workflow/WFS-${SESSION_ID}/.summaries/IMPL-*-summary.md 2>/dev/null
|
||||
```
|
||||
### Output Files Created
|
||||
- `.workflow/[sessionId]/.process/context-package-test.json` - Test context package
|
||||
- `.workflow/[sessionId]/.process/ANALYSIS_RESULTS.md` - Test execution strategy
|
||||
- `.workflow/[sessionId]/.task/TEST-FIX-001.json` - Task definition
|
||||
- `.workflow/[sessionId]/IMPL_PLAN.md` - Updated with test-fix plan
|
||||
- `.workflow/[sessionId]/TODO_LIST.md` - Updated with TEST-FIX task
|
||||
- `.workflow/[sessionId]/.summaries/TEST-FIX-001-summary.md` - Created by test-fix-agent after completion
|
||||
|
||||
### Step 6: Extract Focus Paths
|
||||
```bash
|
||||
find .workflow/WFS-${SESSION_ID}/.task/ -name '*.json' -exec jq -r '.context.focus_paths[]?' {} \;
|
||||
```
|
||||
## Best Practices
|
||||
|
||||
### Step 7: Gemini Analysis and Planning Document Generation
|
||||
```bash
|
||||
cd project-root && ~/.claude/scripts/gemini-wrapper -p "
|
||||
PURPOSE: Analyze implementation and generate comprehensive test planning document
|
||||
TASK: Review changed files and implementation context to create detailed test planning document
|
||||
CONTEXT: Changed files: [changed_files], Implementation summaries: [impl_summaries], Focus paths: [focus_paths]
|
||||
EXPECTED: Complete test planning document including:
|
||||
- Test strategy analysis
|
||||
- Critical test scenarios identification
|
||||
- Edge cases and error conditions
|
||||
- Test priority matrix
|
||||
- Resource requirements
|
||||
- Implementation approach recommendations
|
||||
- Specific test cases with acceptance criteria
|
||||
RULES: Generate structured markdown document suitable for workflow planning. Focus on actionable test requirements based on actual implementation changes.
|
||||
" > .workflow/WFS-${SESSION_ID}/.process/GEMINI_TEST_PLAN.md
|
||||
```
|
||||
1. **Run after implementation complete**: Ensure all IMPL tasks are done before test-gen
|
||||
2. **Check git commits**: Make sure implementation changes are committed
|
||||
3. **Verify test files exist**: Code-developer should have created tests
|
||||
4. **Monitor execution**: Use `/workflow:status` to track test-fix progress
|
||||
5. **Review failures**: If tests fail repeatedly, check test-fix-agent summary for details
|
||||
|
||||
### Step 8: Generate Combined Test Requirements Document
|
||||
```bash
|
||||
mkdir -p .workflow/WFS-${SESSION_ID}/.process
|
||||
```
|
||||
## Coordinator Checklist
|
||||
|
||||
```bash
|
||||
cat > .workflow/WFS-${SESSION_ID}/.process/TEST_REQUIREMENTS.md << 'EOF'
|
||||
# Test Requirements Summary for WFS-${SESSION_ID}
|
||||
|
||||
## Analysis Data Sources
|
||||
- Git change analysis results
|
||||
- Implementation summaries and context
|
||||
- Gemini-generated test planning document
|
||||
|
||||
## Reference Documents
|
||||
- Detailed test plan: GEMINI_TEST_PLAN.md
|
||||
- Implementation context: IMPL-*-summary.md files
|
||||
|
||||
## Integration Note
|
||||
This document combines analysis data with Gemini-generated planning document for comprehensive test workflow generation.
|
||||
EOF
|
||||
```
|
||||
|
||||
### Step 9: Call Workflow Plan with Gemini Planning Document
|
||||
```bash
|
||||
/workflow:plan .workflow/WFS-${SESSION_ID}/.process/GEMINI_TEST_PLAN.md
|
||||
```
|
||||
|
||||
## Simple Bash Commands
|
||||
|
||||
### Basic Operations
|
||||
- **Find active session**: `find .workflow/ -name '.active-*'`
|
||||
- **Get git changes**: `git log --since='date' --name-only`
|
||||
- **Filter code files**: `grep -E '\.(js|ts|py)$'`
|
||||
- **Load summaries**: `cat .workflow/WFS-*/summaries/*.md`
|
||||
- **Extract JSON data**: `jq -r '.context.focus_paths[]'`
|
||||
- **Create directory**: `mkdir -p .workflow/session/.process`
|
||||
- **Write file**: `cat > file << 'EOF'`
|
||||
|
||||
### Gemini CLI Integration
|
||||
- **Planning command**: `~/.claude/scripts/gemini-wrapper -p "prompt" > GEMINI_TEST_PLAN.md`
|
||||
- **Context loading**: Include changed files and implementation context
|
||||
- **Document generation**: Creates comprehensive test planning document
|
||||
- **Direct handoff**: Pass Gemini planning document to workflow:plan
|
||||
|
||||
## No Complex Logic
|
||||
- No variables or functions
|
||||
- No conditional statements
|
||||
- No loops or complex pipes
|
||||
- Direct bash commands only
|
||||
- Gemini CLI for intelligent analysis
|
||||
✅ Initialize TodoWrite before any command
|
||||
✅ Execute Phase 1 immediately with session ID
|
||||
✅ Parse context package path from Phase 1 output
|
||||
✅ Pass session ID and context path to Phase 2 command
|
||||
✅ Verify ANALYSIS_RESULTS.md after Phase 2
|
||||
✅ Pass session ID to Phase 3 command
|
||||
✅ Verify all Phase 3 outputs (task JSON, IMPL_PLAN, TODO_LIST)
|
||||
✅ Pass session ID to Phase 4 command
|
||||
✅ Update TodoWrite after each phase
|
||||
✅ Return summary only after Phase 4 completes
|
||||
|
||||
## Related Commands
|
||||
- `/workflow:plan` - Called to generate test workflow
|
||||
- `/workflow:execute` - Executes generated test tasks
|
||||
- `/workflow:status` - Shows test workflow progress
|
||||
- `/workflow:plan` - Create implementation workflow (run before test-gen)
|
||||
- `/workflow:tools:context-gather` - Phase 1 tool for context collection
|
||||
- `/workflow:tools:concept-enhanced` - Phase 2 tool for analysis
|
||||
- `/workflow:tools:task-generate` - Phase 3 tool for task creation
|
||||
- `/workflow:execute` - Phase 4 workflow execution
|
||||
- `/workflow:status` - Check workflow progress
|
||||
- `@test-fix-agent` - Agent that executes and fixes tests
|
||||
|
||||
@@ -158,7 +158,7 @@ Task(
|
||||
"status": "pending",
|
||||
"meta": {
|
||||
"type": "feature|bugfix|refactor|test|docs",
|
||||
"agent": "@code-developer|@code-review-test-agent"
|
||||
"agent": "@code-developer|@test-fix-agent|@general-purpose"
|
||||
},
|
||||
"context": {
|
||||
"requirements": ["extracted from analysis"],
|
||||
|
||||
@@ -67,8 +67,8 @@ Generate task JSON files and IMPL_PLAN.md from analysis results with automatic a
|
||||
"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"
|
||||
"type": "feature|bugfix|refactor|test-gen|test-fix|docs",
|
||||
"agent": "@code-developer|@test-fix-agent|@general-purpose"
|
||||
},
|
||||
"context": {
|
||||
"requirements": ["Clear requirement from analysis"],
|
||||
|
||||
@@ -13,8 +13,8 @@ All task files use this simplified 5-field schema (aligned with workflow-archite
|
||||
"status": "pending|active|completed|blocked|container",
|
||||
|
||||
"meta": {
|
||||
"type": "feature|bugfix|refactor|test|docs",
|
||||
"agent": "@code-developer|@planning-agent|@code-review-test-agent"
|
||||
"type": "feature|bugfix|refactor|test-gen|test-fix|docs",
|
||||
"agent": "@code-developer|@action-planning-agent|@test-fix-agent|@general-purpose"
|
||||
},
|
||||
|
||||
"context": {
|
||||
@@ -145,17 +145,17 @@ Tasks inherit from:
|
||||
## Agent Mapping
|
||||
|
||||
### Automatic Agent Selection
|
||||
- **@code-developer**: Implementation tasks, coding
|
||||
- **@planning-agent**: Design, architecture planning
|
||||
- **@code-review-test-agent**: Testing, validation
|
||||
- **@review-agent**: Code review, quality checks
|
||||
- **@code-developer**: Implementation tasks, coding, test writing
|
||||
- **@action-planning-agent**: Design, architecture planning
|
||||
- **@test-fix-agent**: Test execution, failure diagnosis, code fixing
|
||||
- **@general-purpose**: Optional manual review (only when explicitly requested)
|
||||
|
||||
### Agent Context Filtering
|
||||
Each agent receives tailored context:
|
||||
- **@code-developer**: Complete implementation details
|
||||
- **@planning-agent**: High-level requirements, risks
|
||||
- **@test-agent**: Files to test, logic flows to validate
|
||||
- **@review-agent**: Quality standards, security considerations
|
||||
- **@code-developer**: Complete implementation details, test requirements
|
||||
- **@action-planning-agent**: High-level requirements, risks, architecture
|
||||
- **@test-fix-agent**: Test execution, failure diagnosis, code fixing
|
||||
- **@general-purpose**: Quality standards, security considerations (when requested)
|
||||
|
||||
## Deprecated Fields
|
||||
|
||||
|
||||
@@ -113,8 +113,8 @@ All task files use this unified 5-field schema with optional artifacts enhanceme
|
||||
"status": "pending|active|completed|blocked|container",
|
||||
|
||||
"meta": {
|
||||
"type": "feature|bugfix|refactor|test|docs",
|
||||
"agent": "code-developer|planning-agent|code-review-test-agent"
|
||||
"type": "feature|bugfix|refactor|test-gen|test-fix|docs",
|
||||
"agent": "@code-developer|@action-planning-agent|@test-fix-agent|@general-purpose"
|
||||
},
|
||||
|
||||
"context": {
|
||||
@@ -420,10 +420,10 @@ fi
|
||||
|
||||
### Agent Assignment
|
||||
Based on task type and title keywords:
|
||||
- **Planning tasks** → @planning-agent
|
||||
- **Implementation** → @code-developer
|
||||
- **Testing** → @code-review-test-agent
|
||||
- **Review** → @review-agent
|
||||
- **Planning tasks** → @action-planning-agent
|
||||
- **Implementation** → @code-developer (code + tests)
|
||||
- **Test execution/fixing** → @test-fix-agent
|
||||
- **Review** → @general-purpose (optional, only when explicitly requested)
|
||||
|
||||
### Execution Context
|
||||
Agents receive complete task JSON plus workflow context:
|
||||
|
||||
63
CHANGELOG.md
63
CHANGELOG.md
@@ -5,6 +5,69 @@ All notable changes to Claude Code Workflow (CCW) will be documented in this fil
|
||||
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
|
||||
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
|
||||
|
||||
## [3.2.0] - 2025-10-02
|
||||
|
||||
### 🔄 Test-Fix Workflow & Agent Architecture Simplification
|
||||
|
||||
This release simplifies the agent architecture and introduces an automated test-fix workflow based on the principle "Tests Are the Review".
|
||||
|
||||
#### Added
|
||||
|
||||
**New Agent: test-fix-agent**:
|
||||
- **Purpose**: Execute tests, diagnose failures, and fix code until all tests pass
|
||||
- **Philosophy**: When all tests pass, code is automatically approved (no separate review needed)
|
||||
- **Responsibilities**:
|
||||
- Execute complete test suite for implemented modules
|
||||
- Parse test output and identify failures
|
||||
- Diagnose root cause of test failures
|
||||
- Modify source code to fix issues
|
||||
- Re-run tests to verify fixes
|
||||
- Certify code approval when all tests pass
|
||||
|
||||
**Enhanced test-gen Command**:
|
||||
- Transforms from planning tool to workflow orchestrator
|
||||
- Auto-generates TEST-FIX tasks for test-fix-agent
|
||||
- Automatically executes test validation via `/workflow:execute`
|
||||
- Eliminates manual planning document generation
|
||||
|
||||
**New Task Types**:
|
||||
- `test-gen`: Test generation tasks (handled by @code-developer)
|
||||
- `test-fix`: Test execution and fixing tasks (handled by @test-fix-agent)
|
||||
|
||||
#### Changed
|
||||
|
||||
**Agent Architecture Simplification**:
|
||||
- **Removed**: `@code-review-agent` and `@code-review-test-agent`
|
||||
- Testing now serves as the quality gate
|
||||
- Passing tests = approved code
|
||||
- **Enhanced**: `@code-developer` now writes implementation + tests together
|
||||
- Unified generative work (code + tests)
|
||||
- Maintains context continuity
|
||||
- **Added**: `@general-purpose` for optional manual reviews
|
||||
- Used only when explicitly requested
|
||||
- Handles special cases and edge scenarios
|
||||
|
||||
**Task Type Updates**:
|
||||
- `"test"` → `"test-gen"` (clearer distinction from test-fix)
|
||||
- Agent mapping updated across all commands:
|
||||
- `feature|bugfix|refactor|test-gen` → `@code-developer`
|
||||
- `test-fix` → `@test-fix-agent`
|
||||
- `review` → `@general-purpose` (optional)
|
||||
|
||||
**Workflow Changes**:
|
||||
```
|
||||
Old: code-developer → test-agent → code-review-agent
|
||||
New: code-developer (code+tests) → test-fix-agent (execute+fix) → ✅ approved
|
||||
```
|
||||
|
||||
#### Removed
|
||||
|
||||
- `@code-review-agent` - Testing serves as quality gate
|
||||
- `@code-review-test-agent` - Functionality split between code-developer and test-fix-agent
|
||||
- Separate review step - Tests passing = code approved
|
||||
|
||||
---
|
||||
|
||||
## [3.1.0] - 2025-10-02
|
||||
|
||||
### 🧪 TDD Workflow Support
|
||||
|
||||
@@ -24,7 +24,7 @@
|
||||
## ✨ Key Features
|
||||
|
||||
- **🎯 Context-First Architecture**: Pre-defined context gathering eliminates execution uncertainty and error accumulation.
|
||||
- **🤖 Multi-Agent System**: Specialized agents (`@code-developer`, `@code-review-test-agent`) with tech-stack awareness.
|
||||
- **🤖 Multi-Agent System**: Specialized agents (`@code-developer`, `@test-fix-agent`) with tech-stack awareness and automated test validation.
|
||||
- **🔄 End-to-End Workflow Automation**: From brainstorming to deployment with multi-phase orchestration.
|
||||
- **📋 JSON-First Task Model**: Structured task definitions with `pre_analysis` steps for deterministic execution.
|
||||
- **🧪 TDD Workflow Support**: Complete Test-Driven Development with Red-Green-Refactor cycle enforcement.
|
||||
@@ -97,9 +97,6 @@ After installation, run the following command to ensure CCW is working:
|
||||
|
||||
# OR verify TDD compliance (TDD workflow)
|
||||
/workflow:tdd-verify
|
||||
|
||||
# Final quality review
|
||||
/workflow:review
|
||||
```
|
||||
|
||||
### Quick Start for Simple Tasks
|
||||
@@ -155,7 +152,7 @@ After installation, run the following command to ensure CCW is working:
|
||||
| `/workflow:status` | Display the current status of the workflow. |
|
||||
| `/workflow:test-gen` | Automatically generate a test plan from the implementation. |
|
||||
| `/workflow:tdd-verify` | Verify TDD compliance and generate quality report. |
|
||||
| `/workflow:review` | Initiate a quality assurance review of the completed work. |
|
||||
| `/workflow:review` | **Optional** manual review (only use when explicitly needed - passing tests = approved code). |
|
||||
|
||||
### **Task & Memory Commands**
|
||||
|
||||
|
||||
@@ -98,8 +98,8 @@ bash <(curl -fsSL https://raw.githubusercontent.com/catlog22/Claude-Code-Workflo
|
||||
# 或验证 TDD 合规性（TDD 工作流）
|
||||
/workflow:tdd-verify
|
||||
|
||||
# 最终质量审查
|
||||
/workflow:review
|
||||
# 可选：手动审查（仅在明确需要时使用）
|
||||
# /workflow:review # 测试通过 = 代码已批准
|
||||
```
|
||||
|
||||
### 简单任务快速入门
|
||||
@@ -155,7 +155,7 @@ bash <(curl -fsSL https://raw.githubusercontent.com/catlog22/Claude-Code-Workflo
|
||||
| `/workflow:status` | 显示工作流的当前状态。 |
|
||||
| `/workflow:test-gen` | 从实现中自动生成测试计划。 |
|
||||
| `/workflow:tdd-verify` | 验证 TDD 合规性并生成质量报告。 |
|
||||
| `/workflow:review` | 对已完成的工作启动质量保证审查。 |
|
||||
| `/workflow:review` | **可选** 手动审查（仅在明确需要时使用，测试通过即代表代码已批准）。 |
|
||||
|
||||
### **任务与内存命令**
|
||||
|
||||
|
||||
Reference in New Issue
Block a user