[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6J6P7TY4G7X29D0ZH2RC1S2":3,"skill-same:01M6J6P7TY4G7X29D0ZH2RC1S2":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M6J6P7TY4G7X29D0ZH2RC1S2","workflow-patterns",null,"Use this skill when implementing tasks according to Conductor's TDD workflow, handling phase checkpoints, managing git commits for tasks, or understanding the verification protocol.","caobingsheng\u002Fskills","caobingsheng","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F18641728?v=4","01M6J6H1N0RR38WEA1KVM9V4GB","01M6J6H1SB287CPJQARKE9FXS0",1,"MIT","https:\u002F\u002Fgithub.com\u002Fcaobingsheng\u002Fskills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fworkflow-patterns\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"workflow","patterns","workflow patterns","for","tdd","implementing","checkpoints","verification protocol","managing git","conductor","use","commits","tdd workflow","verification","protocol","git","tasks","2026-11-10 10:12:30",false,"---\nname: workflow-patterns\ndescription: Use this skill when implementing tasks according to Conductor's TDD workflow, handling phase checkpoints, managing git commits for tasks, or understanding the verification protocol.\nversion: 1.0.0\n---\n\n# Workflow Patterns\n\nGuide for implementing tasks using Conductor's TDD workflow, managing phase checkpoints, handling git commits, and executing the verification protocol that ensures quality throughout implementation.\n\n## When to Use This Skill\n\n- Implementing tasks from a track's plan.md\n- Following TDD red-green-refactor cycle\n- Completing phase checkpoints\n- Managing git commits and notes\n- Understanding quality assurance gates\n- Handling verification protocols\n- Recording progress in plan files\n\n## TDD Task Lifecycle\n\nFollow these 11 steps for each task:\n\n### Step 1: Select Next Task\n\nRead plan.md and identify the next pending `[ ]` task. Select tasks in order within the current phase. Do not skip ahead to later phases.\n\n### Step 2: Mark as In Progress\n\nUpdate plan.md to mark the task as `[~]`:\n\n```markdown\n- [~] **Task 2.1**: Implement user validation\n```\n\nCommit this status change separately from implementation.\n\n### Step 3: RED - Write Failing Tests\n\nWrite tests that define the expected behavior before writing implementation:\n\n- Create test file if needed\n- Write test cases covering happy path\n- Write test cases covering edge cases\n- Write test cases covering error conditions\n- Run tests - they should FAIL\n\nExample:\n\n```python\ndef test_validate_user_email_valid():\n    user = User(email=\"test@example.com\")\n    assert user.validate_email() is True\n\ndef test_validate_user_email_invalid():\n    user = User(email=\"invalid\")\n    assert user.validate_email() is False\n```\n\n### Step 4: GREEN - Implement Minimum Code\n\nWrite the minimum code necessary to make tests pass:\n\n- Focus on making tests green, not perfection\n- Avoid premature optimization\n- Keep implementation simple\n- Run tests - they should PASS\n\n### Step 5: REFACTOR - Improve Clarity\n\nWith green tests, improve the code:\n\n- Extract common patterns\n- Improve naming\n- Remove duplication\n- Simplify logic\n- Run tests after each change - they should remain GREEN\n\n### Step 6: Verify Coverage\n\nCheck test coverage meets the 80% target:\n\n```bash\npytest --cov=module --cov-report=term-missing\n```\n\nIf coverage is below 80%:\n\n- Identify uncovered lines\n- Add tests for missing paths\n- Re-run coverage check\n\n### Step 7: Document Deviations\n\nIf implementation deviated from plan or introduced new dependencies:\n\n- Update tech-stack.md with new dependencies\n- Note deviations in plan.md task comments\n- Update spec.md if requirements changed\n\n### Step 8: Commit Implementation\n\nCreate a focused commit for the task:\n\n```bash\ngit add -A\ngit commit -m \"feat(user): implement email validation\n\n- Add validate_email method to User class\n- Handle empty and malformed emails\n- Add comprehensive test coverage\n\nTask: 2.1\nTrack: user-auth_20250115\"\n```\n\nCommit message format:\n\n- Type: feat, fix, refactor, test, docs, chore\n- Scope: affected module or component\n- Summary: imperative, present tense\n- Body: bullet points of changes\n- Footer: task and track references\n\n### Step 9: Attach Git Notes\n\nAdd rich task summary as git note:\n\n```bash\ngit notes add -m \"Task 2.1: Implement user validation\n\nSummary:\n- Added email validation using regex pattern\n- Handles edge cases: empty, no @, no domain\n- Coverage: 94% on validation module\n\nFiles changed:\n- src\u002Fmodels\u002Fuser.py (modified)\n- tests\u002Ftest_user.py (modified)\n\nDecisions:\n- Used simple regex over email-validator library\n- Reason: No external dependency for basic validation\"\n```\n\n### Step 10: Update Plan with SHA\n\nUpdate plan.md to mark task complete with commit SHA:\n\n```markdown\n- [x] **Task 2.1**: Implement user validation `abc1234`\n```\n\n### Step 11: Commit Plan Update\n\nCommit the plan status update:\n\n```bash\ngit add conductor\u002Ftracks\u002F*\u002Fplan.md\ngit commit -m \"docs: update plan - task 2.1 complete\n\nTrack: user-auth_20250115\"\n```\n\n## Phase Completion Protocol\n\nWhen all tasks in a phase are complete, execute the verification protocol:\n\n### Identify Changed Files\n\nList all files modified since the last checkpoint:\n\n```bash\ngit diff --name-only \u003Clast-checkpoint-sha>..HEAD\n```\n\n### Ensure Test Coverage\n\nFor each modified file:\n\n1. Identify corresponding test file\n2. Verify tests exist for new\u002Fchanged code\n3. Run coverage for modified modules\n4. Add tests if coverage \u003C 80%\n\n### Run Full Test Suite\n\nExecute complete test suite:\n\n```bash\npytest -v --tb=short\n```\n\nAll tests must pass before proceeding.\n\n### Generate Manual Verification Steps\n\nCreate checklist of manual verifications:\n\n```markdown\n## Phase 1 Verification Checklist\n\n- [ ] User can register with valid email\n- [ ] Invalid email shows appropriate error\n- [ ] Database stores user correctly\n- [ ] API returns expected response codes\n```\n\n### WAIT for User Approval\n\nPresent verification checklist to user:\n\n```\nPhase 1 complete. Please verify:\n1. [ ] Test suite passes (automated)\n2. [ ] Coverage meets target (automated)\n3. [ ] Manual verification items (requires human)\n\nRespond with 'approved' to continue, or note issues.\n```\n\nDo NOT proceed without explicit approval.\n\n### Create Checkpoint Commit\n\nAfter approval, create checkpoint commit:\n\n```bash\ngit add -A\ngit commit -m \"checkpoint: phase 1 complete - user-auth_20250115\n\nVerified:\n- All tests passing\n- Coverage: 87%\n- Manual verification approved\n\nPhase 1 tasks:\n- [x] Task 1.1: Setup database schema\n- [x] Task 1.2: Implement user model\n- [x] Task 1.3: Add validation logic\"\n```\n\n### Record Checkpoint SHA\n\nUpdate plan.md checkpoints table:\n\n```markdown\n## Checkpoints\n\n| Phase   | Checkpoint SHA | Date       | Status   |\n| ------- | -------------- | ---------- | -------- |\n| Phase 1 | def5678        | 2025-01-15 | verified |\n| Phase 2 |                |            | pending  |\n```\n\n## Quality Assurance Gates\n\nBefore marking any task complete, verify these gates:\n\n### Passing Tests\n\n- All existing tests pass\n- New tests pass\n- No test regressions\n\n### Coverage >= 80%\n\n- New code has 80%+ coverage\n- Overall project coverage maintained\n- Critical paths fully covered\n\n### Style Compliance\n\n- Code follows style guides\n- Linting passes\n- Formatting correct\n\n### Documentation\n\n- Public APIs documented\n- Complex logic explained\n- README updated if needed\n\n### Type Safety\n\n- Type hints present (if applicable)\n- Type checker passes\n- No type: ignore without reason\n\n### No Linting Errors\n\n- Zero linter errors\n- Warnings addressed or justified\n- Static analysis clean\n\n### Mobile Compatibility\n\nIf applicable:\n\n- Responsive design verified\n- Touch interactions work\n- Performance acceptable\n\n### Security Audit\n\n- No secrets in code\n- Input validation present\n- Authentication\u002Fauthorization correct\n- Dependencies vulnerability-free\n\n## Git Integration\n\n### Commit Message Format\n\n```\n\u003Ctype>(\u003Cscope>): \u003Csubject>\n\n\u003Cbody>\n\n\u003Cfooter>\n```\n\nTypes:\n\n- `feat`: New feature\n- `fix`: Bug fix\n- `refactor`: Code change without feature\u002Ffix\n- `test`: Adding tests\n- `docs`: Documentation\n- `chore`: Maintenance\n\n### Git Notes for Rich Summaries\n\nAttach detailed notes to commits:\n\n```bash\ngit notes add -m \"\u003Cdetailed summary>\"\n```\n\nView notes:\n\n```bash\ngit log --show-notes\n```\n\nBenefits:\n\n- Preserves context without cluttering commit message\n- Enables semantic queries across commits\n- Supports track-based operations\n\n### SHA Recording in plan.md\n\nAlways record the commit SHA when completing tasks:\n\n```markdown\n- [x] **Task 1.1**: Setup schema `abc1234`\n- [x] **Task 1.2**: Add model `def5678`\n```\n\nThis enables:\n\n- Traceability from plan to code\n- Semantic revert operations\n- Progress auditing\n\n## Verification Checkpoints\n\n### Why Checkpoints Matter\n\nCheckpoints create restore points for semantic reversion:\n\n- Revert to end of any phase\n- Maintain logical code state\n- Enable safe experimentation\n\n### When to Create Checkpoints\n\nCreate checkpoint after:\n\n- All phase tasks complete\n- All phase verifications pass\n- User approval received\n\n### Checkpoint Commit Content\n\nInclude in checkpoint commit:\n\n- All uncommitted changes\n- Updated plan.md\n- Updated metadata.json\n- Any documentation updates\n\n### How to Use Checkpoints\n\nFor reverting:\n\n```bash\n# Revert to end of Phase 1\ngit revert --no-commit \u003Cphase-2-commits>...\ngit commit -m \"revert: rollback to phase 1 checkpoint\"\n```\n\nFor review:\n\n```bash\n# See what changed in Phase 2\ngit diff \u003Cphase-1-sha>..\u003Cphase-2-sha>\n```\n\n## Handling Deviations\n\nDuring implementation, deviations from the plan may occur. Handle them systematically:\n\n### Types of Deviations\n\n**Scope Addition**\nDiscovered requirement not in original spec.\n\n- Document in spec.md as new requirement\n- Add tasks to plan.md\n- Note addition in task comments\n\n**Scope Reduction**\nFeature deemed unnecessary during implementation.\n\n- Mark tasks as `[-]` (skipped) with reason\n- Update spec.md scope section\n- Document decision rationale\n\n**Technical Deviation**\nDifferent implementation approach than planned.\n\n- Note deviation in task completion comment\n- Update tech-stack.md if dependencies changed\n- Document why original approach was unsuitable\n\n**Requirement Change**\nUnderstanding of requirement changes during work.\n\n- Update spec.md with corrected requirement\n- Adjust plan.md tasks if needed\n- Re-verify acceptance criteria\n\n### Deviation Documentation Format\n\nWhen completing a task with deviation:\n\n```markdown\n- [x] **Task 2.1**: Implement validation `abc1234`\n  - DEVIATION: Used library instead of custom code\n  - Reason: Better edge case handling\n  - Impact: Added email-validator to dependencies\n```\n\n## Error Recovery\n\n### Failed Tests After GREEN\n\nIf tests fail after reaching GREEN:\n\n1. Do NOT proceed to REFACTOR\n2. Identify which test started failing\n3. Check if refactoring broke something\n4. Revert to last known GREEN state\n5. Re-approach the implementation\n\n### Checkpoint Rejection\n\nIf user rejects a checkpoint:\n\n1. Note rejection reason in plan.md\n2. Create tasks to address issues\n3. Complete remediation tasks\n4. Request checkpoint approval again\n\n### Blocked by Dependency\n\nIf task cannot proceed:\n\n1. Mark task as `[!]` with blocker description\n2. Check if other tasks can proceed\n3. Document expected resolution timeline\n4. Consider creating dependency resolution track\n\n## TDD Variations by Task Type\n\n### Data Model Tasks\n\n```\nRED: Write test for model creation and validation\nGREEN: Implement model class with fields\nREFACTOR: Add computed properties, improve types\n```\n\n### API Endpoint Tasks\n\n```\nRED: Write test for request\u002Fresponse contract\nGREEN: Implement endpoint handler\nREFACTOR: Extract validation, improve error handling\n```\n\n### Integration Tasks\n\n```\nRED: Write test for component interaction\nGREEN: Wire components together\nREFACTOR: Improve error propagation, add logging\n```\n\n### Refactoring Tasks\n\n```\nRED: Add characterization tests for current behavior\nGREEN: Apply refactoring (tests should stay green)\nREFACTOR: Clean up any introduced complexity\n```\n\n## Working with Existing Tests\n\nWhen modifying code with existing tests:\n\n### Extend, Don't Replace\n\n- Keep existing tests passing\n- Add new tests for new behavior\n- Update tests only when requirements change\n\n### Test Migration\n\nWhen refactoring changes test structure:\n\n1. Run existing tests (should pass)\n2. Add new tests for refactored code\n3. Migrate test cases to new structure\n4. Remove old tests only after new tests pass\n\n### Regression Prevention\n\nAfter any change:\n\n1. Run full test suite\n2. Check for unexpected failures\n3. Investigate any new failures\n4. Fix regressions before proceeding\n\n## Checkpoint Verification Details\n\n### Automated Verification\n\nRun before requesting approval:\n\n```bash\n# Test suite\npytest -v --tb=short\n\n# Coverage\npytest --cov=src --cov-report=term-missing\n\n# Linting\nruff check src\u002F tests\u002F\n\n# Type checking (if applicable)\nmypy src\u002F\n```\n\n### Manual Verification Guidance\n\nFor manual items, provide specific instructions:\n\n```markdown\n## Manual Verification Steps\n\n### User Registration\n\n1. Navigate to \u002Fregister\n2. Enter valid email: test@example.com\n3. Enter password meeting requirements\n4. Click Submit\n5. Verify success message appears\n6. Verify user appears in database\n\n### Error Handling\n\n1. Enter invalid email: \"notanemail\"\n2. Verify error message shows\n3. Verify form retains other entered data\n```\n\n## Performance Considerations\n\n### Test Suite Performance\n\nKeep test suite fast:\n\n- Use fixtures to avoid redundant setup\n- Mock slow external calls\n- Run subset during development, full suite at checkpoints\n\n### Commit Performance\n\nKeep commits atomic:\n\n- One logical change per commit\n- Complete thought, not work-in-progress\n- Tests should pass after every commit\n\n## Best Practices\n\n1. **Never skip RED**: Always write failing tests first\n2. **Small commits**: One logical change per commit\n3. **Immediate updates**: Update plan.md right after task completion\n4. **Wait for approval**: Never skip checkpoint verification\n5. **Rich git notes**: Include context that helps future understanding\n6. **Coverage discipline**: Don't accept coverage below target\n7. **Quality gates**: Check all gates before marking complete\n8. **Sequential phases**: Complete phases in order\n9. **Document deviations**: Note any changes from original plan\n10. **Clean state**: Each commit should leave code in working state\n11. **Fast feedback**: Run relevant tests frequently during development\n12. **Clear blockers**: Address blockers promptly, don't work around them\n","# Workflow Patterns\n\nGuide for implementing tasks using Conductor's TDD workflow, managing phase checkpoints, handling git commits, and executing the verification protocol that ensures quality throughout implementation.\n\n## When to Use This Skill\n\n- Implementing tasks from a track's plan.md\n- Following TDD red-green-refactor cycle\n- Completing phase checkpoints\n- Managing git commits and notes\n- Understanding quality assurance gates\n- Handling verification protocols\n- Recording progress in plan files\n\n## TDD Task Lifecycle\n\nFollow these 11 steps for each task:\n\n### Step 1: Select Next Task\n\nRead plan.md and identify the next pending `[ ]` task. Select tasks in order within the current phase. Do not skip ahead to later phases.\n\n### Step 2: Mark as In Progress\n\nUpdate plan.md to mark the task as `[~]`:\n\n```markdown\n- [~] **Task 2.1**: Implement user validation\n```\n\nCommit this status change separately from implementation.\n\n### Step 3: RED - Write Failing Tests\n\nWrite tests that define the expected behavior before writing implementation:\n\n- Create test file if needed\n- Write test cases covering happy path\n- Write test cases covering edge cases\n- Write test cases covering error conditions\n- Run tests - they should FAIL\n\nExample:\n\n```python\ndef test_validate_user_email_valid():\n    user = User(email=\"test@example.com\")\n    assert user.validate_email() is True\n\ndef test_validate_user_email_invalid():\n    user = User(email=\"invalid\")\n    assert user.validate_email() is False\n```\n\n### Step 4: GREEN - Implement Minimum Code\n\nWrite the minimum code necessary to make tests pass:\n\n- Focus on making tests green, not perfection\n- Avoid premature optimization\n- Keep implementation simple\n- Run tests - they should PASS\n\n### Step 5: REFACTOR - Improve Clarity\n\nWith green tests, improve the code:\n\n- Extract common patterns\n- Improve naming\n- Remove duplication\n- Simplify logic\n- Run tests after each change - they should remain GREEN\n\n### Step 6: Verify Coverage\n\nCheck test coverage meets the 80% target:\n\n```bash\npytest --cov=module --cov-report=term-missing\n```\n\nIf coverage is below 80%:\n\n- Identify uncovered lines\n- Add tests for missing paths\n- Re-run coverage check\n\n### Step 7: Document Deviations\n\nIf implementation deviated from plan or introduced new dependencies:\n\n- Update tech-stack.md with new dependencies\n- Note deviations in plan.md task comments\n- Update spec.md if requirements changed\n\n### Step 8: Commit Implementation\n\nCreate a focused commit for the task:\n\n```bash\ngit add -A\ngit commit -m \"feat(user): implement email validation\n\n- Add validate_email method to User class\n- Handle empty and malformed emails\n- Add comprehensive test coverage\n\nTask: 2.1\nTrack: user-auth_20250115\"\n```\n\nCommit message format:\n\n- Type: feat, fix, refactor, test, docs, chore\n- Scope: affected module or component\n- Summary: imperative, present tense\n- Body: bullet points of changes\n- Footer: task and track references\n\n### Step 9: Attach Git Notes\n\nAdd rich task summary as git note:\n\n```bash\ngit notes add -m \"Task 2.1: Implement user validation\n\nSummary:\n- Added email validation using regex pattern\n- Handles edge cases: empty, no @, no domain\n- Coverage: 94% on validation module\n\nFiles changed:\n- src\u002Fmodels\u002Fuser.py (modified)\n- tests\u002Ftest_user.py (modified)\n\nDecisions:\n- Used simple regex over email-validator library\n- Reason: No external dependency for basic validation\"\n```\n\n### Step 10: Update Plan with SHA\n\nUpdate plan.md to mark task complete with commit SHA:\n\n```markdown\n- [x] **Task 2.1**: Implement user validation `abc1234`\n```\n\n### Step 11: Commit Plan Update\n\nCommit the plan status update:\n\n```bash\ngit add conductor\u002Ftracks\u002F*\u002Fplan.md\ngit commit -m \"docs: update plan - task 2.1 complete\n\nTrack: user-auth_20250115\"\n```\n\n## Phase Completion Protocol\n\nWhen all tasks in a phase are complete, execute the verification protocol:\n\n### Identify Changed Files\n\nList all files modified since the last checkpoint:\n\n```bash\ngit diff --name-only \u003Clast-checkpoint-sha>..HEAD\n```\n\n### Ensure Test Coverage\n\nFor each modified file:\n\n1. Identify corresponding test file\n2. Verify tests exist for new\u002Fchanged code\n3. Run coverage for modified modules\n4. Add tests if coverage \u003C 80%\n\n### Run Full Test Suite\n\nExecute complete test suite:\n\n```bash\npytest -v --tb=short\n```\n\nAll tests must pass before proceeding.\n\n### Generate Manual Verification Steps\n\nCreate checklist of manual verifications:\n\n```markdown\n## Phase 1 Verification Checklist\n\n- [ ] User can register with valid email\n- [ ] Invalid email shows appropriate error\n- [ ] Database stores user correctly\n- [ ] API returns expected response codes\n```\n\n### WAIT for User Approval\n\nPresent verification checklist to user:\n\n```\nPhase 1 complete. Please verify:\n1. [ ] Test suite passes (automated)\n2. [ ] Coverage meets target (automated)\n3. [ ] Manual verification items (requires human)\n\nRespond with 'approved' to continue, or note issues.\n```\n\nDo NOT proceed without explicit approval.\n\n### Create Checkpoint Commit\n\nAfter approval, create checkpoint commit:\n\n```bash\ngit add -A\ngit commit -m \"checkpoint: phase 1 complete - user-auth_20250115\n\nVerified:\n- All tests passing\n- Coverage: 87%\n- Manual verification approved\n\nPhase 1 tasks:\n- [x] Task 1.1: Setup database schema\n- [x] Task 1.2: Implement user model\n- [x] Task 1.3: Add validation logic\"\n```\n\n### Record Checkpoint SHA\n\nUpdate plan.md checkpoints table:\n\n```markdown\n## Checkpoints\n\n| Phase   | Checkpoint SHA | Date       | Status   |\n| ------- | -------------- | ---------- | -------- |\n| Phase 1 | def5678        | 2025-01-15 | verified |\n| Phase 2 |                |            | pending  |\n```\n\n## Quality Assurance Gates\n\nBefore marking any task complete, verify these gates:\n\n### Passing Tests\n\n- All existing tests pass\n- New tests pass\n- No test regressions\n\n### Coverage >= 80%\n\n- New code has 80%+ coverage\n- Overall project coverage maintained\n- Critical paths fully covered\n\n### Style Compliance\n\n- Code follows style guides\n- Linting passes\n- Formatting correct\n\n### Documentation\n\n- Public APIs documented\n- Complex logic explained\n- README updated if needed\n\n### Type Safety\n\n- Type hints present (if applicable)\n- Type checker passes\n- No type: ignore without reason\n\n### No Linting Errors\n\n- Zero linter errors\n- Warnings addressed or justified\n- Static analysis clean\n\n### Mobile Compatibility\n\nIf applicable:\n\n- Responsive design verified\n- Touch interactions work\n- Performance acceptable\n\n### Security Audit\n\n- No secrets in code\n- Input validation present\n- Authentication\u002Fauthorization correct\n- Dependencies vulnerability-free\n\n## Git Integration\n\n### Commit Message Format\n\n```\n\u003Ctype>(\u003Cscope>): \u003Csubject>\n\n\u003Cbody>\n\n\u003Cfooter>\n```\n\nTypes:\n\n- `feat`: New feature\n- `fix`: Bug fix\n- `refactor`: Code change without feature\u002Ffix\n- `test`: Adding tests\n- `docs`: Documentation\n- `chore`: Maintenance\n\n### Git Notes for Rich Summaries\n\nAttach detailed notes to commits:\n\n```bash\ngit notes add -m \"\u003Cdetailed summary>\"\n```\n\nView notes:\n\n```bash\ngit log --show-notes\n```\n\nBenefits:\n\n- Preserves context without cluttering commit message\n- Enables semantic queries across commits\n- Supports track-based operations\n\n### SHA Recording in plan.md\n\nAlways record the commit SHA when completing tasks:\n\n```markdown\n- [x] **Task 1.1**: Setup schema `abc1234`\n- [x] **Task 1.2**: Add model `def5678`\n```\n\nThis enables:\n\n- Traceability from plan to code\n- Semantic revert operations\n- Progress auditing\n\n## Verification Checkpoints\n\n### Why Checkpoints Matter\n\nCheckpoints create restore points for semantic reversion:\n\n- Revert to end of any phase\n- Maintain logical code state\n- Enable safe experimentation\n\n### When to Create Checkpoints\n\nCreate checkpoint after:\n\n- All phase tasks complete\n- All phase verifications pass\n- User approval received\n\n### Checkpoint Commit Content\n\nInclude in checkpoint commit:\n\n- All uncommitted changes\n- Updated plan.md\n- Updated metadata.json\n- Any documentation updates\n\n### How to Use Checkpoints\n\nFor reverting:\n\n```bash\n# Revert to end of Phase 1\ngit revert --no-commit \u003Cphase-2-commits>...\ngit commit -m \"revert: rollback to phase 1 checkpoint\"\n```\n\nFor review:\n\n```bash\n# See what changed in Phase 2\ngit diff \u003Cphase-1-sha>..\u003Cphase-2-sha>\n```\n\n## Handling Deviations\n\nDuring implementation, deviations from the plan may occur. Handle them systematically:\n\n### Types of Deviations\n\n**Scope Addition**\nDiscovered requirement not in original spec.\n\n- Document in spec.md as new requirement\n- Add tasks to plan.md\n- Note addition in task comments\n\n**Scope Reduction**\nFeature deemed unnecessary during implementation.\n\n- Mark tasks as `[-]` (skipped) with reason\n- Update spec.md scope section\n- Document decision rationale\n\n**Technical Deviation**\nDifferent implementation approach than planned.\n\n- Note deviation in task completion comment\n- Update tech-stack.md if dependencies changed\n- Document why original approach was unsuitable\n\n**Requirement Change**\nUnderstanding of requirement changes during work.\n\n- Update spec.md with corrected requirement\n- Adjust plan.md tasks if needed\n- Re-verify acceptance criteria\n\n### Deviation Documentation Format\n\nWhen completing a task with deviation:\n\n```markdown\n- [x] **Task 2.1**: Implement validation `abc1234`\n  - DEVIATION: Used library instead of custom code\n  - Reason: Better edge case handling\n  - Impact: Added email-validator to dependencies\n```\n\n## Error Recovery\n\n### Failed Tests After GREEN\n\nIf tests fail after reaching GREEN:\n\n1. Do NOT proceed to REFACTOR\n2. Identify which test started failing\n3. Check if refactoring broke something\n4. Revert to last known GREEN state\n5. Re-approach the implementation\n\n### Checkpoint Rejection\n\nIf user rejects a checkpoint:\n\n1. Note rejection reason in plan.md\n2. Create tasks to address issues\n3. Complete remediation tasks\n4. Request checkpoint approval again\n\n### Blocked by Dependency\n\nIf task cannot proceed:\n\n1. Mark task as `[!]` with blocker description\n2. Check if other tasks can proceed\n3. Document expected resolution timeline\n4. Consider creating dependency resolution track\n\n## TDD Variations by Task Type\n\n### Data Model Tasks\n\n```\nRED: Write test for model creation and validation\nGREEN: Implement model class with fields\nREFACTOR: Add computed properties, improve types\n```\n\n### API Endpoint Tasks\n\n```\nRED: Write test for request\u002Fresponse contract\nGREEN: Implement endpoint handler\nREFACTOR: Extract validation, improve error handling\n```\n\n### Integration Tasks\n\n```\nRED: Write test for component interaction\nGREEN: Wire components together\nREFACTOR: Improve error propagation, add logging\n```\n\n### Refactoring Tasks\n\n```\nRED: Add characterization tests for current behavior\nGREEN: Apply refactoring (tests should stay green)\nREFACTOR: Clean up any introduced complexity\n```\n\n## Working with Existing Tests\n\nWhen modifying code with existing tests:\n\n### Extend, Don't Replace\n\n- Keep existing tests passing\n- Add new tests for new behavior\n- Update tests only when requirements change\n\n### Test Migration\n\nWhen refactoring changes test structure:\n\n1. Run existing tests (should pass)\n2. Add new tests for refactored code\n3. Migrate test cases to new structure\n4. Remove old tests only after new tests pass\n\n### Regression Prevention\n\nAfter any change:\n\n1. Run full test suite\n2. Check for unexpected failures\n3. Investigate any new failures\n4. Fix regressions before proceeding\n\n## Checkpoint Verification Details\n\n### Automated Verification\n\nRun before requesting approval:\n\n```bash\n# Test suite\npytest -v --tb=short\n\n# Coverage\npytest --cov=src --cov-report=term-missing\n\n# Linting\nruff check src\u002F tests\u002F\n\n# Type checking (if applicable)\nmypy src\u002F\n```\n\n### Manual Verification Guidance\n\nFor manual items, provide specific instructions:\n\n```markdown\n## Manual Verification Steps\n\n### User Registration\n\n1. Navigate to \u002Fregister\n2. Enter valid email: test@example.com\n3. Enter password meeting requirements\n4. Click Submit\n5. Verify success message appears\n6. Verify user appears in database\n\n### Error Handling\n\n1. Enter invalid email: \"notanemail\"\n2. Verify error message shows\n3. Verify form retains other entered data\n```\n\n## Performance Considerations\n\n### Test Suite Performance\n\nKeep test suite fast:\n\n- Use fixtures to avoid redundant setup\n- Mock slow external calls\n- Run subset during development, full suite at checkpoints\n\n### Commit Performance\n\nKeep commits atomic:\n\n- One logical change per commit\n- Complete thought, not work-in-progress\n- Tests should pass after every commit\n\n## Best Practices\n\n1. **Never skip RED**: Always write failing tests first\n2. **Small commits**: One logical change per commit\n3. **Immediate updates**: Update plan.md right after task completion\n4. **Wait for approval**: Never skip checkpoint verification\n5. **Rich git notes**: Include context that helps future understanding\n6. **Coverage discipline**: Don't accept coverage below target\n7. **Quality gates**: Check all gates before marking complete\n8. **Sequential phases**: Complete phases in order\n9. **Document deviations**: Note any changes from original plan\n10. **Clean state**: Each commit should leave code in working state\n11. **Fast feedback**: Run relevant tests frequently during development\n12. **Clear blockers**: Address blockers promptly, don't work around them\n",{"name":5,"version":45,"description":7},"1.0.0","main","309495d95536f4a5e4db1a251f246589229e13e8",".claude\u002Fskills\u002Fworkflow-patterns",0,"https:\u002F\u002Fgithub.com\u002Fcaobingsheng\u002Fskills","https:\u002F\u002Fgithub.com\u002Fcaobingsheng","2026-04-11 12:21:07",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add caobingsheng\u002Fskills --skill workflow-patterns",{"tool":59,"command":60},"bunx","bunx skills add caobingsheng\u002Fskills --skill workflow-patterns",{"tool":62,"command":63},"pnpm","pnpm dlx skills add caobingsheng\u002Fskills --skill workflow-patterns","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcaobingsheng\u002Fskills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fworkflow-patterns\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},".openskills.json","REFERENCE","参考文档",214,"https:\u002F\u002Fgithub.com\u002Fcaobingsheng\u002Fskills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fworkflow-patterns\u002F.openskills.json",[74,91,106,119,130,158],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":83,"publishedAt":40},"01M6J72F9FX5W05JHBQQW9EHS5","tdd-workflows-tdd-refactor","Use when working with tdd workflows tdd refactor","https:\u002F\u002Fgithub.com\u002Fcaobingsheng\u002Fskills\u002Fblob\u002Fmain\u002Ftdd\u002Ftdd-workflows-tdd-refactor\u002FSKILL.md",[80],{"categoryNo":81,"categoryName":82,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",[27,84,85,86,87,33,88,89,90],"workflows","refactor","tdd workflows","tdd workflows tdd refactor","community","with","unknown",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":40},"01M6J72BQ4NV5HEX94RQJ8B4J2","tdd-workflows-tdd-red","Generate failing tests for the TDD red phase to define expected behavior and edge cases.","https:\u002F\u002Fgithub.com\u002Fcaobingsheng\u002Fskills\u002Fblob\u002Fmain\u002Ftdd\u002Ftdd-workflows-tdd-red\u002FSKILL.md",[],[98,27,84,99,86,100,101,102,88,103,104,26,105,90],"red","tdd workflows tdd red","edge","generate","behavior","define","tests","expected",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":40},"01M6J727C8Q52EG3RTQWMC2X61","tdd-workflows-tdd-green","Implement the minimal code needed to make failing tests pass in the TDD green phase.","https:\u002F\u002Fgithub.com\u002Fcaobingsheng\u002Fskills\u002Fblob\u002Fmain\u002Ftdd\u002Ftdd-workflows-tdd-green\u002FSKILL.md",[],[113,86,114,84,27,115,88,116,117,104,118,90],"green","tdd workflows tdd green","implement","minimal","code","make",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":126,"publishedAt":40},"01M6J723JYFES8D9PHGY81QBHZ","tdd-workflows-tdd-cycle","Use when working with tdd workflows tdd cycle","https:\u002F\u002Fgithub.com\u002Fcaobingsheng\u002Fskills\u002Fblob\u002Fmain\u002Ftdd\u002Ftdd-workflows-tdd-cycle\u002FSKILL.md",[125],{"categoryNo":81,"categoryName":82,"taxonomyType":20,"taxonomyTypeDesc":21},[27,84,127,128,129,86,88,89,33,90],"cycle","tdd cycle","tdd workflows tdd cycle",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":145,"publishedAt":40},"01M6J71ZC3W0FE9CKQGYRCSRCA","tdd-workflow","Use this skill when writing new features, fixing bugs, or refactoring code. Enforces test-driven development with 80%+ coverage including unit, integration, and E2E tests.","https:\u002F\u002Fgithub.com\u002Fcaobingsheng\u002Fskills\u002Fblob\u002Fmain\u002Ftdd\u002Ftdd-workflow\u002FSKILL.md",[136,139,140],{"categoryNo":137,"categoryName":138,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":141,"categoryName":142,"taxonomyType":143,"taxonomyTypeDesc":144},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[35,23,27,146,147,33,148,149,89,150,151,104,152,153,154,155,117,156,157],"writing","test","features","bugs","unit","driven","coverage","refactoring","e2e","integration","development","e2e tests",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":166,"publishedAt":40},"01M6J71VTWV5GP7AQ08G4CDWFG","tdd-orchestrator","Master TDD orchestrator specializing in red-green-refactor discipline, multi-agent workflow coordination, and comprehensive test-driven development practices.","https:\u002F\u002Fgithub.com\u002Fcaobingsheng\u002Fskills\u002Fblob\u002Fmain\u002Ftdd\u002Ftdd-orchestrator\u002FSKILL.md",[164,165],{"categoryNo":137,"categoryName":138,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[27,167,168,169,90,170,98,151,113,171,88,172,173,174,175,85,156,147,23],"orchestrator","tdd orchestrator","master","multi","agent workflow","red-green-refactor","discipline","multi-agent","coordination"]