[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M72XM7G7WAPHS4ANN1ZXDZBW":3,"skill-same:01M72XM7G7WAPHS4ANN1ZXDZBW":46},{"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":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":29,"ownerHtmlUrl":30,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":31,"install":32,"resources":45},"01M72XM7G7WAPHS4ANN1ZXDZBW","track-management",null,"Use this skill when creating, managing, or working with Conductor tracks - the logical work units for features, bugs, and refactors. Applies to spec.md, plan.md, and track lifecycle operations.","steph-frtech\u002Fclaude-code-up","steph-frtech","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F198466323?v=4","01M72XD213FVQA2QXRGTJFKHE1","01M72XD227AANJ993SQTNZB1CK",1,"MIT","https:\u002F\u002Fgithub.com\u002Fsteph-frtech\u002Fclaude-code-up\u002Fblob\u002Fmain\u002F.claude\u002Fmarketplaces\u002Fwshobson\u002Fplugins\u002Fconductor\u002Fskills\u002Ftrack-management\u002FSKILL.md",[],[],"2026-11-10 22:39:42",false,"---\nname: track-management\ndescription: Use this skill when creating, managing, or working with Conductor tracks - the logical work units for features, bugs, and refactors. Applies to spec.md, plan.md, and track lifecycle operations.\nversion: 1.0.0\n---\n\n# Track Management\n\nGuide for creating, managing, and completing Conductor tracks - the logical work units that organize features, bugs, and refactors through specification, planning, and implementation phases.\n\n## When to Use This Skill\n\n- Creating new feature, bug, or refactor tracks\n- Writing or reviewing spec.md files\n- Creating or updating plan.md files\n- Managing track lifecycle from creation to completion\n- Understanding track status markers and conventions\n- Working with the tracks.md registry\n- Interpreting or updating track metadata\n\n## Track Concept\n\nA track is a logical work unit that encapsulates a complete piece of work. Each track has:\n\n- A unique identifier\n- A specification defining requirements\n- A phased plan breaking work into tasks\n- Metadata tracking status and progress\n\nTracks provide semantic organization for work, enabling:\n\n- Clear scope boundaries\n- Progress tracking\n- Git-aware operations (revert by track)\n- Team coordination\n\n## Track Types\n\n### feature\n\nNew functionality or capabilities. Use for:\n\n- New user-facing features\n- New API endpoints\n- New integrations\n- Significant enhancements\n\n### bug\n\nDefect fixes. Use for:\n\n- Incorrect behavior\n- Error conditions\n- Performance regressions\n- Security vulnerabilities\n\n### chore\n\nMaintenance and housekeeping. Use for:\n\n- Dependency updates\n- Configuration changes\n- Documentation updates\n- Cleanup tasks\n\n### refactor\n\nCode improvement without behavior change. Use for:\n\n- Code restructuring\n- Pattern adoption\n- Technical debt reduction\n- Performance optimization (same behavior, better performance)\n\n## Track ID Format\n\nTrack IDs follow the pattern: `{shortname}_{YYYYMMDD}`\n\n- **shortname**: 2-4 word kebab-case description (e.g., `user-auth`, `api-rate-limit`)\n- **YYYYMMDD**: Creation date in ISO format\n\nExamples:\n\n- `user-auth_20250115`\n- `fix-login-error_20250115`\n- `upgrade-deps_20250115`\n- `refactor-api-client_20250115`\n\n## Track Lifecycle\n\n### 1. Creation (newTrack)\n\n**Define Requirements**\n\n1. Gather requirements through interactive Q&A\n2. Identify acceptance criteria\n3. Determine scope boundaries\n4. Identify dependencies\n\n**Generate Specification**\n\n1. Create `spec.md` with structured requirements\n2. Document functional and non-functional requirements\n3. Define acceptance criteria\n4. List dependencies and constraints\n\n**Generate Plan**\n\n1. Create `plan.md` with phased task breakdown\n2. Organize tasks into logical phases\n3. Add verification tasks after phases\n4. Estimate effort and complexity\n\n**Register Track**\n\n1. Add entry to `tracks.md` registry\n2. Create track directory structure\n3. Generate `metadata.json`\n4. Create track `index.md`\n\n### 2. Implementation\n\n**Execute Tasks**\n\n1. Select next pending task from plan\n2. Mark task as in-progress\n3. Implement following workflow (TDD)\n4. Mark task complete with commit SHA\n\n**Update Status**\n\n1. Update task markers in plan.md\n2. Record commit SHAs for traceability\n3. Update phase progress\n4. Update track status in tracks.md\n\n**Verify Progress**\n\n1. Complete verification tasks\n2. Wait for checkpoint approval\n3. Record checkpoint commits\n\n### 3. Completion\n\n**Sync Documentation**\n\n1. Update product.md if features added\n2. Update tech-stack.md if dependencies changed\n3. Verify all acceptance criteria met\n\n**Archive or Delete**\n\n1. Mark track as completed in tracks.md\n2. Record completion date\n3. Archive or retain track directory\n\n## Specification (spec.md) Structure\n\n```markdown\n# {Track Title}\n\n## Overview\n\nBrief description of what this track accomplishes and why.\n\n## Functional Requirements\n\n### FR-1: {Requirement Name}\n\nDescription of the functional requirement.\n\n- Acceptance: How to verify this requirement is met\n\n### FR-2: {Requirement Name}\n\n...\n\n## Non-Functional Requirements\n\n### NFR-1: {Requirement Name}\n\nDescription of the non-functional requirement (performance, security, etc.)\n\n- Target: Specific measurable target\n- Verification: How to test\n\n## Acceptance Criteria\n\n- [ ] Criterion 1: Specific, testable condition\n- [ ] Criterion 2: Specific, testable condition\n- [ ] Criterion 3: Specific, testable condition\n\n## Scope\n\n### In Scope\n\n- Explicitly included items\n- Features to implement\n- Components to modify\n\n### Out of Scope\n\n- Explicitly excluded items\n- Future considerations\n- Related but separate work\n\n## Dependencies\n\n### Internal\n\n- Other tracks or components this depends on\n- Required context artifacts\n\n### External\n\n- Third-party services or APIs\n- External dependencies\n\n## Risks and Mitigations\n\n| Risk             | Impact          | Mitigation          |\n| ---------------- | --------------- | ------------------- |\n| Risk description | High\u002FMedium\u002FLow | Mitigation strategy |\n\n## Open Questions\n\n- [ ] Question that needs resolution\n- [x] Resolved question - Answer\n```\n\n## Plan (plan.md) Structure\n\n```markdown\n# Implementation Plan: {Track Title}\n\nTrack ID: `{track-id}`\nCreated: YYYY-MM-DD\nStatus: pending | in-progress | completed\n\n## Overview\n\nBrief description of implementation approach.\n\n## Phase 1: {Phase Name}\n\n### Tasks\n\n- [ ] **Task 1.1**: Task description\n  - Sub-task or detail\n  - Sub-task or detail\n- [ ] **Task 1.2**: Task description\n- [ ] **Task 1.3**: Task description\n\n### Verification\n\n- [ ] **Verify 1.1**: Verification step for phase\n\n## Phase 2: {Phase Name}\n\n### Tasks\n\n- [ ] **Task 2.1**: Task description\n- [ ] **Task 2.2**: Task description\n\n### Verification\n\n- [ ] **Verify 2.1**: Verification step for phase\n\n## Phase 3: Finalization\n\n### Tasks\n\n- [ ] **Task 3.1**: Update documentation\n- [ ] **Task 3.2**: Final integration test\n\n### Verification\n\n- [ ] **Verify 3.1**: All acceptance criteria met\n\n## Checkpoints\n\n| Phase   | Checkpoint SHA | Date | Status  |\n| ------- | -------------- | ---- | ------- |\n| Phase 1 |                |      | pending |\n| Phase 2 |                |      | pending |\n| Phase 3 |                |      | pending |\n```\n\n## Status Marker Conventions\n\nUse consistent markers in plan.md:\n\n| Marker | Meaning     | Usage                       |\n| ------ | ----------- | --------------------------- |\n| `[ ]`  | Pending     | Task not started            |\n| `[~]`  | In Progress | Currently being worked      |\n| `[x]`  | Complete    | Task finished (include SHA) |\n| `[-]`  | Skipped     | Intentionally not done      |\n| `[!]`  | Blocked     | Waiting on dependency       |\n\nExample:\n\n```markdown\n- [x] **Task 1.1**: Set up database schema `abc1234`\n- [~] **Task 1.2**: Implement user model\n- [ ] **Task 1.3**: Add validation logic\n- [!] **Task 1.4**: Integrate auth service (blocked: waiting for API key)\n- [-] **Task 1.5**: Legacy migration (skipped: not needed)\n```\n\n## Track Registry (tracks.md) Format\n\n```markdown\n# Track Registry\n\n## Active Tracks\n\n| Track ID                                         | Type    | Status      | Phase | Started    | Assignee   |\n| ------------------------------------------------ | ------- | ----------- | ----- | ---------- | ---------- |\n| [user-auth_20250115](tracks\u002Fuser-auth_20250115\u002F) | feature | in-progress | 2\u002F3   | 2025-01-15 | @developer |\n| [fix-login_20250114](tracks\u002Ffix-login_20250114\u002F) | bug     | pending     | 0\u002F2   | 2025-01-14 | -          |\n\n## Completed Tracks\n\n| Track ID                                       | Type  | Completed  | Duration |\n| ---------------------------------------------- | ----- | ---------- | -------- |\n| [setup-ci_20250110](tracks\u002Fsetup-ci_20250110\u002F) | chore | 2025-01-12 | 2 days   |\n\n## Archived Tracks\n\n| Track ID                                             | Reason     | Archived   |\n| ---------------------------------------------------- | ---------- | ---------- |\n| [old-feature_20241201](tracks\u002Fold-feature_20241201\u002F) | Superseded | 2025-01-05 |\n```\n\n## Metadata (metadata.json) Fields\n\n```json\n{\n  \"id\": \"user-auth_20250115\",\n  \"title\": \"User Authentication System\",\n  \"type\": \"feature\",\n  \"status\": \"in-progress\",\n  \"priority\": \"high\",\n  \"created\": \"2025-01-15T10:30:00Z\",\n  \"updated\": \"2025-01-15T14:45:00Z\",\n  \"started\": \"2025-01-15T11:00:00Z\",\n  \"completed\": null,\n  \"assignee\": \"@developer\",\n  \"phases\": {\n    \"total\": 3,\n    \"current\": 2,\n    \"completed\": 1\n  },\n  \"tasks\": {\n    \"total\": 12,\n    \"completed\": 5,\n    \"in_progress\": 1,\n    \"pending\": 6\n  },\n  \"checkpoints\": [\n    {\n      \"phase\": 1,\n      \"sha\": \"abc1234\",\n      \"date\": \"2025-01-15T13:00:00Z\"\n    }\n  ],\n  \"dependencies\": [],\n  \"tags\": [\"auth\", \"security\"]\n}\n```\n\n## Track Operations\n\n### Creating a Track\n\n1. Run `\u002Fconductor:new-track`\n2. Answer interactive questions\n3. Review generated spec.md\n4. Review generated plan.md\n5. Confirm track creation\n\n### Starting Implementation\n\n1. Read spec.md and plan.md\n2. Verify context artifacts are current\n3. Mark first task as `[~]`\n4. Begin TDD workflow\n\n### Completing a Phase\n\n1. Ensure all phase tasks are `[x]`\n2. Complete verification tasks\n3. Wait for checkpoint approval\n4. Record checkpoint SHA\n5. Proceed to next phase\n\n### Completing a Track\n\n1. Verify all phases complete\n2. Verify all acceptance criteria met\n3. Update product.md if needed\n4. Mark track completed in tracks.md\n5. Update metadata.json\n\n### Reverting a Track\n\n1. Run `\u002Fconductor:revert`\n2. Select track to revert\n3. Choose granularity (track\u002Fphase\u002Ftask)\n4. Confirm revert operation\n5. Update status markers\n\n## Handling Track Dependencies\n\n### Identifying Dependencies\n\nDuring track creation, identify:\n\n- **Hard dependencies**: Must complete before this track can start\n- **Soft dependencies**: Can proceed in parallel but may affect integration\n- **External dependencies**: Third-party services, APIs, or team decisions\n\n### Documenting Dependencies\n\nIn spec.md, list dependencies with:\n\n- Dependency type (hard\u002Fsoft\u002Fexternal)\n- Current status (available\u002Fpending\u002Fblocked)\n- Resolution path (what needs to happen)\n\n### Managing Blocked Tracks\n\nWhen a track is blocked:\n\n1. Mark blocked tasks with `[!]` and reason\n2. Update tracks.md status\n3. Document blocker in metadata.json\n4. Consider creating dependency track if needed\n\n## Track Sizing Guidelines\n\n### Right-Sized Tracks\n\nAim for tracks that:\n\n- Complete in 1-5 days of work\n- Have 2-4 phases\n- Contain 8-20 tasks total\n- Deliver a coherent, testable unit\n\n### Too Large\n\nSigns a track is too large:\n\n- More than 5 phases\n- More than 25 tasks\n- Multiple unrelated features\n- Estimated duration > 1 week\n\nSolution: Split into multiple tracks with clear boundaries.\n\n### Too Small\n\nSigns a track is too small:\n\n- Single phase with 1-2 tasks\n- No meaningful verification needed\n- Could be a sub-task of another track\n- Less than a few hours of work\n\nSolution: Combine with related work or handle as part of existing track.\n\n## Specification Quality Checklist\n\nBefore finalizing spec.md, verify:\n\n### Requirements Quality\n\n- [ ] Each requirement has clear acceptance criteria\n- [ ] Requirements are testable\n- [ ] Requirements are independent (can verify separately)\n- [ ] No ambiguous language (\"should be fast\" → \"response \u003C 200ms\")\n\n### Scope Clarity\n\n- [ ] In-scope items are specific\n- [ ] Out-of-scope items prevent scope creep\n- [ ] Boundaries are clear to implementer\n\n### Dependencies Identified\n\n- [ ] All internal dependencies listed\n- [ ] External dependencies have owners\u002Fcontacts\n- [ ] Dependency status is current\n\n### Risks Addressed\n\n- [ ] Major risks identified\n- [ ] Impact assessment realistic\n- [ ] Mitigations are actionable\n\n## Plan Quality Checklist\n\nBefore starting implementation, verify plan.md:\n\n### Task Quality\n\n- [ ] Tasks are atomic (one logical action)\n- [ ] Tasks are independently verifiable\n- [ ] Task descriptions are clear\n- [ ] Sub-tasks provide helpful detail\n\n### Phase Organization\n\n- [ ] Phases group related tasks\n- [ ] Each phase delivers something testable\n- [ ] Verification tasks after each phase\n- [ ] Phases build on each other logically\n\n### Completeness\n\n- [ ] All spec requirements have corresponding tasks\n- [ ] Documentation tasks included\n- [ ] Testing tasks included\n- [ ] Integration tasks included\n\n## Common Track Patterns\n\n### Feature Track Pattern\n\n```\nPhase 1: Foundation\n- Data models\n- Database migrations\n- Basic API structure\n\nPhase 2: Core Logic\n- Business logic implementation\n- Input validation\n- Error handling\n\nPhase 3: Integration\n- UI integration\n- API documentation\n- End-to-end tests\n```\n\n### Bug Fix Track Pattern\n\n```\nPhase 1: Reproduction\n- Write failing test capturing bug\n- Document reproduction steps\n\nPhase 2: Fix\n- Implement fix\n- Verify test passes\n- Check for regressions\n\nPhase 3: Verification\n- Manual verification\n- Update documentation if needed\n```\n\n### Refactor Track Pattern\n\n```\nPhase 1: Preparation\n- Add characterization tests\n- Document current behavior\n\nPhase 2: Refactoring\n- Apply changes incrementally\n- Maintain green tests throughout\n\nPhase 3: Cleanup\n- Remove dead code\n- Update documentation\n```\n\n## Best Practices\n\n1. **One track, one concern**: Keep tracks focused on a single logical change\n2. **Small phases**: Break work into phases of 3-5 tasks maximum\n3. **Verification after phases**: Always include verification tasks\n4. **Update markers immediately**: Mark task status as you work\n5. **Record SHAs**: Always note commit SHAs for completed tasks\n6. **Review specs before planning**: Ensure spec is complete before creating plan\n7. **Link dependencies**: Explicitly note track dependencies\n8. **Archive, don't delete**: Preserve completed tracks for reference\n9. **Size appropriately**: Keep tracks between 1-5 days of work\n10. **Clear acceptance criteria**: Every requirement must be testable\n","# Track Management\n\nGuide for creating, managing, and completing Conductor tracks - the logical work units that organize features, bugs, and refactors through specification, planning, and implementation phases.\n\n## When to Use This Skill\n\n- Creating new feature, bug, or refactor tracks\n- Writing or reviewing spec.md files\n- Creating or updating plan.md files\n- Managing track lifecycle from creation to completion\n- Understanding track status markers and conventions\n- Working with the tracks.md registry\n- Interpreting or updating track metadata\n\n## Track Concept\n\nA track is a logical work unit that encapsulates a complete piece of work. Each track has:\n\n- A unique identifier\n- A specification defining requirements\n- A phased plan breaking work into tasks\n- Metadata tracking status and progress\n\nTracks provide semantic organization for work, enabling:\n\n- Clear scope boundaries\n- Progress tracking\n- Git-aware operations (revert by track)\n- Team coordination\n\n## Track Types\n\n### feature\n\nNew functionality or capabilities. Use for:\n\n- New user-facing features\n- New API endpoints\n- New integrations\n- Significant enhancements\n\n### bug\n\nDefect fixes. Use for:\n\n- Incorrect behavior\n- Error conditions\n- Performance regressions\n- Security vulnerabilities\n\n### chore\n\nMaintenance and housekeeping. Use for:\n\n- Dependency updates\n- Configuration changes\n- Documentation updates\n- Cleanup tasks\n\n### refactor\n\nCode improvement without behavior change. Use for:\n\n- Code restructuring\n- Pattern adoption\n- Technical debt reduction\n- Performance optimization (same behavior, better performance)\n\n## Track ID Format\n\nTrack IDs follow the pattern: `{shortname}_{YYYYMMDD}`\n\n- **shortname**: 2-4 word kebab-case description (e.g., `user-auth`, `api-rate-limit`)\n- **YYYYMMDD**: Creation date in ISO format\n\nExamples:\n\n- `user-auth_20250115`\n- `fix-login-error_20250115`\n- `upgrade-deps_20250115`\n- `refactor-api-client_20250115`\n\n## Track Lifecycle\n\n### 1. Creation (newTrack)\n\n**Define Requirements**\n\n1. Gather requirements through interactive Q&A\n2. Identify acceptance criteria\n3. Determine scope boundaries\n4. Identify dependencies\n\n**Generate Specification**\n\n1. Create `spec.md` with structured requirements\n2. Document functional and non-functional requirements\n3. Define acceptance criteria\n4. List dependencies and constraints\n\n**Generate Plan**\n\n1. Create `plan.md` with phased task breakdown\n2. Organize tasks into logical phases\n3. Add verification tasks after phases\n4. Estimate effort and complexity\n\n**Register Track**\n\n1. Add entry to `tracks.md` registry\n2. Create track directory structure\n3. Generate `metadata.json`\n4. Create track `index.md`\n\n### 2. Implementation\n\n**Execute Tasks**\n\n1. Select next pending task from plan\n2. Mark task as in-progress\n3. Implement following workflow (TDD)\n4. Mark task complete with commit SHA\n\n**Update Status**\n\n1. Update task markers in plan.md\n2. Record commit SHAs for traceability\n3. Update phase progress\n4. Update track status in tracks.md\n\n**Verify Progress**\n\n1. Complete verification tasks\n2. Wait for checkpoint approval\n3. Record checkpoint commits\n\n### 3. Completion\n\n**Sync Documentation**\n\n1. Update product.md if features added\n2. Update tech-stack.md if dependencies changed\n3. Verify all acceptance criteria met\n\n**Archive or Delete**\n\n1. Mark track as completed in tracks.md\n2. Record completion date\n3. Archive or retain track directory\n\n## Specification (spec.md) Structure\n\n```markdown\n# {Track Title}\n\n## Overview\n\nBrief description of what this track accomplishes and why.\n\n## Functional Requirements\n\n### FR-1: {Requirement Name}\n\nDescription of the functional requirement.\n\n- Acceptance: How to verify this requirement is met\n\n### FR-2: {Requirement Name}\n\n...\n\n## Non-Functional Requirements\n\n### NFR-1: {Requirement Name}\n\nDescription of the non-functional requirement (performance, security, etc.)\n\n- Target: Specific measurable target\n- Verification: How to test\n\n## Acceptance Criteria\n\n- [ ] Criterion 1: Specific, testable condition\n- [ ] Criterion 2: Specific, testable condition\n- [ ] Criterion 3: Specific, testable condition\n\n## Scope\n\n### In Scope\n\n- Explicitly included items\n- Features to implement\n- Components to modify\n\n### Out of Scope\n\n- Explicitly excluded items\n- Future considerations\n- Related but separate work\n\n## Dependencies\n\n### Internal\n\n- Other tracks or components this depends on\n- Required context artifacts\n\n### External\n\n- Third-party services or APIs\n- External dependencies\n\n## Risks and Mitigations\n\n| Risk             | Impact          | Mitigation          |\n| ---------------- | --------------- | ------------------- |\n| Risk description | High\u002FMedium\u002FLow | Mitigation strategy |\n\n## Open Questions\n\n- [ ] Question that needs resolution\n- [x] Resolved question - Answer\n```\n\n## Plan (plan.md) Structure\n\n```markdown\n# Implementation Plan: {Track Title}\n\nTrack ID: `{track-id}`\nCreated: YYYY-MM-DD\nStatus: pending | in-progress | completed\n\n## Overview\n\nBrief description of implementation approach.\n\n## Phase 1: {Phase Name}\n\n### Tasks\n\n- [ ] **Task 1.1**: Task description\n  - Sub-task or detail\n  - Sub-task or detail\n- [ ] **Task 1.2**: Task description\n- [ ] **Task 1.3**: Task description\n\n### Verification\n\n- [ ] **Verify 1.1**: Verification step for phase\n\n## Phase 2: {Phase Name}\n\n### Tasks\n\n- [ ] **Task 2.1**: Task description\n- [ ] **Task 2.2**: Task description\n\n### Verification\n\n- [ ] **Verify 2.1**: Verification step for phase\n\n## Phase 3: Finalization\n\n### Tasks\n\n- [ ] **Task 3.1**: Update documentation\n- [ ] **Task 3.2**: Final integration test\n\n### Verification\n\n- [ ] **Verify 3.1**: All acceptance criteria met\n\n## Checkpoints\n\n| Phase   | Checkpoint SHA | Date | Status  |\n| ------- | -------------- | ---- | ------- |\n| Phase 1 |                |      | pending |\n| Phase 2 |                |      | pending |\n| Phase 3 |                |      | pending |\n```\n\n## Status Marker Conventions\n\nUse consistent markers in plan.md:\n\n| Marker | Meaning     | Usage                       |\n| ------ | ----------- | --------------------------- |\n| `[ ]`  | Pending     | Task not started            |\n| `[~]`  | In Progress | Currently being worked      |\n| `[x]`  | Complete    | Task finished (include SHA) |\n| `[-]`  | Skipped     | Intentionally not done      |\n| `[!]`  | Blocked     | Waiting on dependency       |\n\nExample:\n\n```markdown\n- [x] **Task 1.1**: Set up database schema `abc1234`\n- [~] **Task 1.2**: Implement user model\n- [ ] **Task 1.3**: Add validation logic\n- [!] **Task 1.4**: Integrate auth service (blocked: waiting for API key)\n- [-] **Task 1.5**: Legacy migration (skipped: not needed)\n```\n\n## Track Registry (tracks.md) Format\n\n```markdown\n# Track Registry\n\n## Active Tracks\n\n| Track ID                                         | Type    | Status      | Phase | Started    | Assignee   |\n| ------------------------------------------------ | ------- | ----------- | ----- | ---------- | ---------- |\n| [user-auth_20250115](tracks\u002Fuser-auth_20250115\u002F) | feature | in-progress | 2\u002F3   | 2025-01-15 | @developer |\n| [fix-login_20250114](tracks\u002Ffix-login_20250114\u002F) | bug     | pending     | 0\u002F2   | 2025-01-14 | -          |\n\n## Completed Tracks\n\n| Track ID                                       | Type  | Completed  | Duration |\n| ---------------------------------------------- | ----- | ---------- | -------- |\n| [setup-ci_20250110](tracks\u002Fsetup-ci_20250110\u002F) | chore | 2025-01-12 | 2 days   |\n\n## Archived Tracks\n\n| Track ID                                             | Reason     | Archived   |\n| ---------------------------------------------------- | ---------- | ---------- |\n| [old-feature_20241201](tracks\u002Fold-feature_20241201\u002F) | Superseded | 2025-01-05 |\n```\n\n## Metadata (metadata.json) Fields\n\n```json\n{\n  \"id\": \"user-auth_20250115\",\n  \"title\": \"User Authentication System\",\n  \"type\": \"feature\",\n  \"status\": \"in-progress\",\n  \"priority\": \"high\",\n  \"created\": \"2025-01-15T10:30:00Z\",\n  \"updated\": \"2025-01-15T14:45:00Z\",\n  \"started\": \"2025-01-15T11:00:00Z\",\n  \"completed\": null,\n  \"assignee\": \"@developer\",\n  \"phases\": {\n    \"total\": 3,\n    \"current\": 2,\n    \"completed\": 1\n  },\n  \"tasks\": {\n    \"total\": 12,\n    \"completed\": 5,\n    \"in_progress\": 1,\n    \"pending\": 6\n  },\n  \"checkpoints\": [\n    {\n      \"phase\": 1,\n      \"sha\": \"abc1234\",\n      \"date\": \"2025-01-15T13:00:00Z\"\n    }\n  ],\n  \"dependencies\": [],\n  \"tags\": [\"auth\", \"security\"]\n}\n```\n\n## Track Operations\n\n### Creating a Track\n\n1. Run `\u002Fconductor:new-track`\n2. Answer interactive questions\n3. Review generated spec.md\n4. Review generated plan.md\n5. Confirm track creation\n\n### Starting Implementation\n\n1. Read spec.md and plan.md\n2. Verify context artifacts are current\n3. Mark first task as `[~]`\n4. Begin TDD workflow\n\n### Completing a Phase\n\n1. Ensure all phase tasks are `[x]`\n2. Complete verification tasks\n3. Wait for checkpoint approval\n4. Record checkpoint SHA\n5. Proceed to next phase\n\n### Completing a Track\n\n1. Verify all phases complete\n2. Verify all acceptance criteria met\n3. Update product.md if needed\n4. Mark track completed in tracks.md\n5. Update metadata.json\n\n### Reverting a Track\n\n1. Run `\u002Fconductor:revert`\n2. Select track to revert\n3. Choose granularity (track\u002Fphase\u002Ftask)\n4. Confirm revert operation\n5. Update status markers\n\n## Handling Track Dependencies\n\n### Identifying Dependencies\n\nDuring track creation, identify:\n\n- **Hard dependencies**: Must complete before this track can start\n- **Soft dependencies**: Can proceed in parallel but may affect integration\n- **External dependencies**: Third-party services, APIs, or team decisions\n\n### Documenting Dependencies\n\nIn spec.md, list dependencies with:\n\n- Dependency type (hard\u002Fsoft\u002Fexternal)\n- Current status (available\u002Fpending\u002Fblocked)\n- Resolution path (what needs to happen)\n\n### Managing Blocked Tracks\n\nWhen a track is blocked:\n\n1. Mark blocked tasks with `[!]` and reason\n2. Update tracks.md status\n3. Document blocker in metadata.json\n4. Consider creating dependency track if needed\n\n## Track Sizing Guidelines\n\n### Right-Sized Tracks\n\nAim for tracks that:\n\n- Complete in 1-5 days of work\n- Have 2-4 phases\n- Contain 8-20 tasks total\n- Deliver a coherent, testable unit\n\n### Too Large\n\nSigns a track is too large:\n\n- More than 5 phases\n- More than 25 tasks\n- Multiple unrelated features\n- Estimated duration > 1 week\n\nSolution: Split into multiple tracks with clear boundaries.\n\n### Too Small\n\nSigns a track is too small:\n\n- Single phase with 1-2 tasks\n- No meaningful verification needed\n- Could be a sub-task of another track\n- Less than a few hours of work\n\nSolution: Combine with related work or handle as part of existing track.\n\n## Specification Quality Checklist\n\nBefore finalizing spec.md, verify:\n\n### Requirements Quality\n\n- [ ] Each requirement has clear acceptance criteria\n- [ ] Requirements are testable\n- [ ] Requirements are independent (can verify separately)\n- [ ] No ambiguous language (\"should be fast\" → \"response \u003C 200ms\")\n\n### Scope Clarity\n\n- [ ] In-scope items are specific\n- [ ] Out-of-scope items prevent scope creep\n- [ ] Boundaries are clear to implementer\n\n### Dependencies Identified\n\n- [ ] All internal dependencies listed\n- [ ] External dependencies have owners\u002Fcontacts\n- [ ] Dependency status is current\n\n### Risks Addressed\n\n- [ ] Major risks identified\n- [ ] Impact assessment realistic\n- [ ] Mitigations are actionable\n\n## Plan Quality Checklist\n\nBefore starting implementation, verify plan.md:\n\n### Task Quality\n\n- [ ] Tasks are atomic (one logical action)\n- [ ] Tasks are independently verifiable\n- [ ] Task descriptions are clear\n- [ ] Sub-tasks provide helpful detail\n\n### Phase Organization\n\n- [ ] Phases group related tasks\n- [ ] Each phase delivers something testable\n- [ ] Verification tasks after each phase\n- [ ] Phases build on each other logically\n\n### Completeness\n\n- [ ] All spec requirements have corresponding tasks\n- [ ] Documentation tasks included\n- [ ] Testing tasks included\n- [ ] Integration tasks included\n\n## Common Track Patterns\n\n### Feature Track Pattern\n\n```\nPhase 1: Foundation\n- Data models\n- Database migrations\n- Basic API structure\n\nPhase 2: Core Logic\n- Business logic implementation\n- Input validation\n- Error handling\n\nPhase 3: Integration\n- UI integration\n- API documentation\n- End-to-end tests\n```\n\n### Bug Fix Track Pattern\n\n```\nPhase 1: Reproduction\n- Write failing test capturing bug\n- Document reproduction steps\n\nPhase 2: Fix\n- Implement fix\n- Verify test passes\n- Check for regressions\n\nPhase 3: Verification\n- Manual verification\n- Update documentation if needed\n```\n\n### Refactor Track Pattern\n\n```\nPhase 1: Preparation\n- Add characterization tests\n- Document current behavior\n\nPhase 2: Refactoring\n- Apply changes incrementally\n- Maintain green tests throughout\n\nPhase 3: Cleanup\n- Remove dead code\n- Update documentation\n```\n\n## Best Practices\n\n1. **One track, one concern**: Keep tracks focused on a single logical change\n2. **Small phases**: Break work into phases of 3-5 tasks maximum\n3. **Verification after phases**: Always include verification tasks\n4. **Update markers immediately**: Mark task status as you work\n5. **Record SHAs**: Always note commit SHAs for completed tasks\n6. **Review specs before planning**: Ensure spec is complete before creating plan\n7. **Link dependencies**: Explicitly note track dependencies\n8. **Archive, don't delete**: Preserve completed tracks for reference\n9. **Size appropriately**: Keep tracks between 1-5 days of work\n10. **Clear acceptance criteria**: Every requirement must be testable\n",{"name":5,"version":23,"description":7},"1.0.0","main","900bb95bbe72cdb94af6f5a620aa5081264b7b6d",".claude\u002Fmarketplaces\u002Fwshobson\u002Fplugins\u002Fconductor\u002Fskills\u002Ftrack-management",0,"https:\u002F\u002Fgithub.com\u002Fsteph-frtech\u002Fclaude-code-up","https:\u002F\u002Fgithub.com\u002Fsteph-frtech\u002Fclaude-code-up#readme","https:\u002F\u002Fgithub.com\u002Fsteph-frtech","2026-05-16 00:03:30",{"source":8,"skillName":5,"commands":33,"prompt":43,"zipAvailable":44},[34,37,40],{"tool":35,"command":36},"npx","npx skills add steph-frtech\u002Fclaude-code-up --skill track-management",{"tool":38,"command":39},"bunx","bunx skills add steph-frtech\u002Fclaude-code-up --skill track-management",{"tool":41,"command":42},"pnpm","pnpm dlx skills add steph-frtech\u002Fclaude-code-up --skill track-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsteph-frtech\u002Fclaude-code-up\u002Fblob\u002Fmain\u002F.claude\u002Fmarketplaces\u002Fwshobson\u002Fplugins\u002Fconductor\u002Fskills\u002Ftrack-management\u002FSKILL.md",true,[],[47,54,61,68,75,82],{"skillNo":48,"name":49,"nameZh":6,"description":50,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":51,"categories":52,"keywords":53,"publishedAt":18},"01M72Y1BY6X8TX3DS19Y04NEBQ","example","One-line summary of what this skill does","https:\u002F\u002Fgithub.com\u002Fsteph-frtech\u002Fclaude-code-up\u002Fblob\u002Fmain\u002Fskills\u002Fexample\u002FSKILL.md",[],[],{"skillNo":55,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":58,"categories":59,"keywords":60,"publishedAt":18},"01M72Y1A38EYR8S9P1MBYDAQTW","writing-plans","Use when you have a spec or requirements for a multi-step task, before touching code","https:\u002F\u002Fgithub.com\u002Fsteph-frtech\u002Fclaude-code-up\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsuperpowers__writing-plans\u002FSKILL.md",[],[],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":67,"publishedAt":18},"01M72Y174QSV1B5NV1E4KWHQBR","using-git-worktrees","Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback","https:\u002F\u002Fgithub.com\u002Fsteph-frtech\u002Fclaude-code-up\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsuperpowers__using-git-worktrees\u002FSKILL.md",[],[],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":18},"01M72Y14SQRHHMKG316HGB2CGK","test-driven-development","Use when implementing any feature or bugfix, before writing implementation code","https:\u002F\u002Fgithub.com\u002Fsteph-frtech\u002Fclaude-code-up\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsuperpowers__test-driven-development\u002FSKILL.md",[],[],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":18},"01M72Y127BCPRH3BRKPJC3Q3G2","systematic-debugging","Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes","https:\u002F\u002Fgithub.com\u002Fsteph-frtech\u002Fclaude-code-up\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsuperpowers__systematic-debugging\u002FSKILL.md",[],[],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":18},"01M72Y1090GJA6B67KPD60WPHH","subagent-driven-development","Use when executing implementation plans with independent tasks in the current session","https:\u002F\u002Fgithub.com\u002Fsteph-frtech\u002Fclaude-code-up\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsuperpowers__subagent-driven-development\u002FSKILL.md",[],[]]