[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CHWJ3B7S3HP4DPTM02BDZQ":3,"skill-same:01M6CHWJ3B7S3HP4DPTM02BDZQ":70},{"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":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":53,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6CHWJ3B7S3HP4DPTM02BDZQ","plan",null,"[ADD v0.11.0] Create implementation plan from a feature spec","MountainUnicorn\u002Fadd","MountainUnicorn","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F199411549?v=4","01M6CHRAWFWD275ANP1S2A0HXC","01M6CHRB0QE1678D913B438SAR",11,"MIT","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fplugins\u002Fadd\u002Fskills\u002Fplan\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,23,24,25,26,27,28,29,30,31,32,33],"spec","telemetry","create","create implementation plan","Bash","Rules","grep","read","write","v0","implementation","2026-11-10 10:12:30",false,"---\ndescription: \"[ADD v0.11.0] Create implementation plan from a feature spec\"\nargument-hint: \"specs\u002F{feature}.md\"\nallowed-tools: [Read, Write, Glob, Grep, Bash]\nreferences: [\"skill-epilogue.md\", \"rules\u002Ftelemetry.md\"]\n---\n\n# ADD Plan Skill v0.11.0\n\nCreate a detailed implementation plan from a feature specification. This skill analyzes acceptance criteria, breaks down work into manageable tasks, identifies parallelizable work, and estimates effort.\n\n## Overview\n\nThe Plan skill transforms a specification into an actionable implementation roadmap. It produces a plan document (docs\u002Fplans\u002F{feature}-plan.md) that guides development work and enables:\n- Task breakdown and prioritization\n- Effort estimation\n- Dependency identification\n- Parallelization opportunities\n- Risk assessment\n- Resource allocation\n\nThe plan bridges the gap between \"what to build\" (spec) and \"how to build it\" (implementation).\n\n## Pre-Flight Checks\n\n1. **Verify spec exists and is complete**\n   - Read spec file from argument\n   - Verify YAML frontmatter is valid\n   - Extract feature name, version, status\n   - Verify acceptance criteria are defined\n   - Verify user test cases are defined (if applicable)\n\n2. **Load project configuration**\n   - Read .add\u002Fconfig.json\n   - Load team size (solo, small, large)\n   - Load tech stack\n   - Load constraints (timeline, budget, etc.)\n   - Load parallelization preferences\n\n3. **Analyze dependencies**\n   - Identify upstream work needed\n   - Check for blockers\n   - Identify integration points\n\n4. **Check for existing plan**\n   - Look for docs\u002Fplans\u002F{feature}-plan.md\n   - If exists, ask user: overwrite or update?\n   - Preserve previous efforts if updating\n\n5. **Check for session handoff** — per the Session-Handoff Preflight in `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md`\n\n## Execution Steps\n\n### Step 1: Analyze Acceptance Criteria\n\nFor each acceptance criterion:\n1. **Understand the requirement**\n   - Read AC text carefully\n   - Identify what \"done\" means\n   - Note any explicit constraints\n\n2. **Decompose into tasks**\n   - What code needs to be written?\n   - What tests need to be written?\n   - What configuration changes?\n   - What documentation?\n   - What other work (DB migrations, etc.)?\n\n3. **Categorize by type**\n   - Core feature code\n   - Test code\n   - Configuration\n   - Documentation\n   - Infrastructure\n\n4. **Estimate complexity**\n   - Simple: straightforward, no unknowns\n   - Medium: some complexity, minor unknowns\n   - Complex: significant work, unknowns\n\nExample analysis:\n```\nAC-001: User can submit form with valid data\n\nTasks:\n1. Design form component API (complexity: simple)\n2. Write form component HTML\u002Fmarkup (complexity: simple)\n3. Add form validation logic (complexity: medium)\n4. Connect to API endpoint (complexity: medium)\n5. Handle submission success\u002Ferror (complexity: simple)\n6. Write tests for validation (complexity: simple)\n7. Write tests for API integration (complexity: medium)\n8. Write tests for error handling (complexity: simple)\n9. Document form API in README (complexity: simple)\n\nDependencies:\n- Depends on API endpoint being ready\n- Depends on design approval\n\nRisks:\n- API contract may change\n- Validation rules may evolve\n```\n\n### Step 2: Create Task List\n\nOrganize tasks in logical sequence:\n\n1. **Group by phase**\n   - Phase 0: Preparation (setup, planning)\n   - Phase 1: Core implementation (main code)\n   - Phase 2: Testing (test code)\n   - Phase 3: Integration (wire-up)\n   - Phase 4: Polish (documentation, refactoring)\n\n2. **Order by dependencies**\n   - Tasks with no dependencies first\n   - Tasks that depend on outputs of previous tasks\n   - Identify blocking dependencies\n\n3. **Assign IDs**\n   - Use format: TASK-NNN\n   - Link to ACs: TASK-001 (AC-001)\n   - Track in plan\n\n4. **Estimate effort**\n   - Time estimate: 30min, 1h, 2h, 4h, 1d, etc.\n   - Add contingency (10-20% for unknowns)\n   - Total per phase\n\nExample task breakdown:\n```\nPhase 1: Core Implementation\n- TASK-001 (AC-001): Design form component API - 30min\n  Dependencies: Design review\n\n- TASK-002 (AC-001): Build form HTML\u002Fmarkup - 1h\n  Dependencies: TASK-001\n\n- TASK-003 (AC-001): Add validation logic - 2h\n  Dependencies: TASK-001, specifications defined\n\n- TASK-004 (AC-001): Integration with API - 2h\n  Dependencies: TASK-001, API endpoint exists\n\nPhase 2: Testing\n- TASK-005 (AC-001): Tests for validation - 1h\n  Dependencies: TASK-003\n\n- TASK-006 (AC-001): Tests for API integration - 2h\n  Dependencies: TASK-004, test infrastructure\n\n- TASK-007 (AC-001): Tests for error handling - 1h\n  Dependencies: TASK-004\n\nPhase 3: Documentation\n- TASK-008 (AC-001): Document form API - 30min\n  Dependencies: TASK-001, TASK-004\n```\n\n### Step 3: Identify Parallelizable Work\n\nAnalyze which tasks can run in parallel:\n\n1. **Find independent task chains**\n   - Which tasks have no common dependencies?\n   - Which can start while others are in progress?\n\n2. **Group by parallelization**\n   ```\n   Sequential (must run in order):\n   - TASK-001 → TASK-002 → TASK-003 → TASK-004\n\n   Can parallelize:\n   - TASK-005 (tests) can start after TASK-003\n   - TASK-006 (API tests) can start after TASK-004\n   - TASK-008 (docs) can start after TASK-001\n\n   Optimal schedule for 2 developers:\n   Dev 1: TASK-001 → TASK-002 → TASK-003 → TASK-005\n   Dev 2: [wait] → [wait] → TASK-004 → TASK-006 → TASK-008\n   ```\n\n3. **Note team size constraints**\n   - Solo: Sequential only\n   - 2-3 people: Some parallelization\n   - Larger team: More parallelization\n\n### Step 4: Risk Assessment\n\nIdentify potential risks:\n\n1. **Technical risks**\n   - Unknown technologies\n   - Complex integrations\n   - Performance concerns\n   - Browser\u002Fplatform compatibility\n\n2. **Dependency risks**\n   - External system dependencies\n   - Third-party API changes\n   - Resource constraints\n\n3. **Scope risks**\n   - Requirements clarity\n   - Feature creep potential\n   - Scope boundary issues\n\n4. **Timeline risks**\n   - Optimistic estimates\n   - Unknown unknowns\n   - Rework potential\n\nExample:\n```\nRisk: Form validation may have complex edge cases\n- Probability: Medium (forms often have edge cases)\n- Impact: High (affects user experience)\n- Mitigation: Plan extra time for edge case testing, get spec clarity early\n\nRisk: API endpoint not ready when form code is done\n- Probability: Medium (API may slip)\n- Impact: Medium (can mock API for testing)\n- Mitigation: Start with mocked API, parallelize API development\n\nRisk: Browser compatibility issues\n- Probability: Low (using standard web APIs)\n- Impact: Medium (affects supported browsers)\n- Mitigation: Test on target browsers early\n```\n\n### Step 5: Create Plan Document\n\nWrite comprehensive plan to docs\u002Fplans\u002F{feature}-plan.md:\n\n```markdown\n# Implementation Plan: {Feature Name}\n\n**Spec Version**: {version}\n**Created**: {date}\n**Team Size**: Solo \u002F 2-3 \u002F {N}\n**Estimated Duration**: {X days\u002Fweeks}\n\n## Overview\n\n{1-2 sentence summary of what will be built}\n\n## Objectives\n\n- [Objective 1]\n- [Objective 2]\n- [Objective 3]\n\n## Success Criteria\n\n- All acceptance criteria implemented and tested\n- Code coverage >= 80%\n- All quality gates passing\n- Zero high-priority bugs\n- Documentation complete\n\n## Acceptance Criteria Analysis\n\n### AC-001: {description}\n- **Complexity**: Medium\n- **Effort Estimate**: 5 hours\n- **Tasks**:\n  - TASK-001: Subtask A\n  - TASK-002: Subtask B\n  - TASK-003: Subtask C\n- **Dependencies**: Design approval, API contract\n- **Risks**: [any specific risks]\n- **Testing Strategy**: Unit + integration tests\n\n### AC-002: {description}\n[... similar analysis]\n\n## Implementation Phases\n\n### Phase 0: Preparation (1 day)\nPreparation work before main development starts.\n\n| Task ID | Description | Effort | Dependencies | Owner |\n|---------|-------------|--------|--------------|-------|\n| TASK-001 | Review spec and get clarification | 2h | Spec complete | Dev 1 |\n| TASK-002 | Set up development environment | 2h | - | Dev 1 |\n| TASK-003 | Create test fixtures and mocks | 3h | TASK-001 | Dev 2 |\n\n**Phase Duration**: 1 day\n**Blockers**: None identified\n\n### Phase 1: Core Implementation (2-3 days)\nMain feature development.\n\n| Task ID | Description | Effort | Dependencies | Owner |\n|---------|-------------|--------|--------------|-------|\n| TASK-004 | Form component structure | 2h | TASK-001 | Dev 1 |\n| TASK-005 | Form validation logic | 4h | TASK-004 | Dev 1 |\n| TASK-006 | API integration | 3h | TASK-001, API contract | Dev 2 |\n| TASK-007 | Error handling | 2h | TASK-005, TASK-006 | Dev 2 |\n\n**Phase Duration**: 3 days (with Dev 1 and Dev 2 parallelization)\n**Blockers**: API contract must be finalized\n\n### Phase 2: Testing (1-2 days)\nComprehensive test coverage.\n\n| Task ID | Description | Effort | Dependencies | Owner |\n|---------|-------------|--------|--------------|-------|\n| TASK-008 | Unit tests for validation | 3h | TASK-005 | Dev 1 |\n| TASK-009 | Unit tests for API integration | 3h | TASK-006 | Dev 2 |\n| TASK-010 | Integration tests | 4h | TASK-005, TASK-006 | Dev 1 & 2 |\n| TASK-011 | Edge case testing | 2h | TASK-010 | Dev 2 |\n\n**Phase Duration**: 2 days\n**Blockers**: Implementation must be complete\n\n### Phase 3: Integration & Polish (1 day)\nFinal touches before merge.\n\n| Task ID | Description | Effort | Dependencies | Owner |\n|---------|-------------|--------|--------------|-------|\n| TASK-012 | Code review & refactoring | 3h | Phase 2 complete | Dev 1 & 2 |\n| TASK-013 | Documentation | 2h | Phase 1 complete | Dev 1 |\n| TASK-014 | Final QA | 2h | Phase 3 in progress | Dev 2 |\n\n**Phase Duration**: 1 day\n\n## Effort Summary\n\n| Phase | Estimated Hours | Days (1 dev) | Days (2 devs) |\n|-------|-----------------|--------------|---------------|\n| Phase 0 | 7 | 1 | 0.5 |\n| Phase 1 | 11 | 2 | 1.5 |\n| Phase 2 | 12 | 2 | 1.5 |\n| Phase 3 | 7 | 1 | 0.5 |\n| **Total** | **37** | **6** | **4** |\n\n## Dependencies\n\n### External Dependencies\n- API endpoint must be ready by Phase 1\n- Design approval by Phase 0\n\n### Internal Dependencies\n- No upstream work required\n- No blocking existing issues\n\n## Parallelization Strategy\n\nWith 2 developers:\n```\nDay 1:\n  Dev 1: TASK-001, TASK-004\n  Dev 2: TASK-002, TASK-003\n\nDay 2:\n  Dev 1: TASK-005, TASK-008\n  Dev 2: TASK-006, TASK-007\n\nDay 3:\n  Dev 1: TASK-010 (collaborative)\n  Dev 2: TASK-009, TASK-011\n\nDay 4:\n  Dev 1 & 2: TASK-012 (collaborative), TASK-013, TASK-014\n```\n\nTotal estimated time with 2 devs: **4 days**\n\n## Risk Assessment\n\n| Risk | Probability | Impact | Mitigation |\n|------|-------------|--------|-----------|\n| API contract changes | Medium | Medium | Mock API first, plan for changes |\n| Edge case bugs | Medium | Medium | Allocate time for edge case testing |\n| Rework due to requirements | Low | High | Get spec clarity upfront (TASK-001) |\n| Team member unavailable | Low | High | Document decisions, pair program |\n\n## Testing Strategy\n\n1. **Unit Tests** (Phase 2)\n   - Validation logic: 100% coverage target\n   - API integration: 90% coverage target\n   - Error handling: 100% coverage target\n\n2. **Integration Tests** (Phase 2)\n   - Form submission flow\n   - API error handling\n   - Success\u002Ferror messaging\n\n3. **Manual Testing** (Phase 3)\n   - Cross-browser testing (Chrome, Firefox, Safari, Edge)\n   - Mobile responsiveness\n   - Accessibility checks\n\n4. **Quality Gates** (Phase 3)\n   - Coverage >= 80%\n   - All tests passing\n   - Lint\u002Ftype checks passing\n   - Spec compliance verified\n\n## Deliverables\n\n### Code\n- Form component (src\u002Fcomponents\u002FForm.tsx)\n- Validation module (src\u002Fvalidation.ts)\n- API integration (src\u002Fapi\u002Fsubmit.ts)\n\n### Tests\n- Unit tests (tests\u002Fvalidation.test.ts, tests\u002Fapi.test.ts)\n- Integration tests (tests\u002Fintegration\u002Fform-submission.test.ts)\n\n### Documentation\n- Component API docs (README.md)\n- Test coverage report\n- Implementation notes\n\n## Success Metrics\n\n- [ ] All 5 acceptance criteria implemented\n- [ ] 32+ tests written and passing\n- [ ] Code coverage >= 80%\n- [ ] Zero outstanding bugs\n- [ ] All quality gates passing\n- [ ] Deployment to staging successful\n- [ ] All team members understand the code\n\n## Next Steps\n\n1. Get stakeholder approval of this plan\n2. Brief team on schedule and dependencies\n3. Begin Phase 0: Preparation\n4. Track actual time against estimates\n5. Adjust plan if blockers arise\n6. Daily standup on progress and blockers\n\n## Plan History\n\n- 2025-02-07: Initial plan created\n```\n\n## Output Format\n\nUpon completion, output:\n\n```\n# Plan Created Successfully ✓\n\n## Feature\n{feature-name} v{spec-version}\n\n## Plan Summary\n- Total Effort: {hours} hours\n- Timeline: {days} days (1 dev) \u002F {days} days (2 devs)\n- Phases: 4\n- Tasks: {count}\n- Parallelizable Tasks: {count}\n\n## Key Metrics\n- Average Task Size: {hours}h\n- Longest Critical Path: {hours}h\n- Estimated Completion: {date}\n\n## Risks Identified\n- {risk-count} risks assessed\n- Highest: {risk-name}\n- Mitigation: [brief summary]\n\n## Plan Location\ndocs\u002Fplans\u002F{feature}-plan.md\n\n## Next Steps\n1. Review and approve plan\n2. Assign team members to phases\n3. Begin Phase 0: Preparation\n4. Schedule daily standup\n5. Run \u002Fadd:tdd-cycle to execute plan\n```\n\n## Progress Tracking\n\n**Tasks to create** (mechanics per `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md`):\n\n| Phase | Subject | activeForm |\n|-------|---------|------------|\n| Read spec | Reading feature spec | Reading feature spec... |\n| Architecture | Analyzing architecture | Analyzing architecture... |\n| Tasks | Identifying and breaking down tasks | Identifying tasks... |\n| Estimation | Estimating effort and timeline | Estimating effort... |\n| Write plan | Writing plan document | Writing plan document... |\n\n## Error Handling\n\n**Spec is incomplete**\n- Halt planning\n- Report missing information\n- Ask user to complete spec before planning\n\n**Cannot parse acceptance criteria**\n- Report which AC is unparseable\n- Show the problematic text\n- Ask user to reformat AC\n\n**No configuration available**\n- Use sensible defaults (team size: solo)\n- Report defaults used\n- Continue planning\n\n## Integration with Other Skills\n\n- Spec (input) comes from specs\u002F{feature}.md\n- Plan (output) guides \u002Fadd:tdd-cycle execution\n- Effort estimates inform scheduling\n- Risk assessment informs quality gate thresholds\n- Task breakdown guides parallel work dispatch\n\n## Configuration in .add\u002Fconfig.json\n\n```json\n{\n  \"plan\": {\n    \"effortMultiplier\": 1.2,\n    \"contingency\": 0.15,\n    \"teamSize\": \"solo\",\n    \"phasesEnabled\": [\"prep\", \"impl\", \"test\", \"polish\"]\n  }\n}\n```\n\n## Plan Review Checklist\n\nBefore finalizing plan, verify:\n- [ ] All ACs are addressed by tasks\n- [ ] All tasks have effort estimates\n- [ ] Dependencies are clearly marked\n- [ ] Parallelization is identified\n- [ ] Risks are documented\n- [ ] Testing strategy is clear\n- [ ] Deliverables are listed\n- [ ] Success criteria are measurable\n\nEnd-of-skill epilogue: follow `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md` (observation + learning checkpoint + progress tracking).\n","# ADD Plan Skill v0.11.0\n\nCreate a detailed implementation plan from a feature specification. This skill analyzes acceptance criteria, breaks down work into manageable tasks, identifies parallelizable work, and estimates effort.\n\n## Overview\n\nThe Plan skill transforms a specification into an actionable implementation roadmap. It produces a plan document (docs\u002Fplans\u002F{feature}-plan.md) that guides development work and enables:\n- Task breakdown and prioritization\n- Effort estimation\n- Dependency identification\n- Parallelization opportunities\n- Risk assessment\n- Resource allocation\n\nThe plan bridges the gap between \"what to build\" (spec) and \"how to build it\" (implementation).\n\n## Pre-Flight Checks\n\n1. **Verify spec exists and is complete**\n   - Read spec file from argument\n   - Verify YAML frontmatter is valid\n   - Extract feature name, version, status\n   - Verify acceptance criteria are defined\n   - Verify user test cases are defined (if applicable)\n\n2. **Load project configuration**\n   - Read .add\u002Fconfig.json\n   - Load team size (solo, small, large)\n   - Load tech stack\n   - Load constraints (timeline, budget, etc.)\n   - Load parallelization preferences\n\n3. **Analyze dependencies**\n   - Identify upstream work needed\n   - Check for blockers\n   - Identify integration points\n\n4. **Check for existing plan**\n   - Look for docs\u002Fplans\u002F{feature}-plan.md\n   - If exists, ask user: overwrite or update?\n   - Preserve previous efforts if updating\n\n5. **Check for session handoff** — per the Session-Handoff Preflight in `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md`\n\n## Execution Steps\n\n### Step 1: Analyze Acceptance Criteria\n\nFor each acceptance criterion:\n1. **Understand the requirement**\n   - Read AC text carefully\n   - Identify what \"done\" means\n   - Note any explicit constraints\n\n2. **Decompose into tasks**\n   - What code needs to be written?\n   - What tests need to be written?\n   - What configuration changes?\n   - What documentation?\n   - What other work (DB migrations, etc.)?\n\n3. **Categorize by type**\n   - Core feature code\n   - Test code\n   - Configuration\n   - Documentation\n   - Infrastructure\n\n4. **Estimate complexity**\n   - Simple: straightforward, no unknowns\n   - Medium: some complexity, minor unknowns\n   - Complex: significant work, unknowns\n\nExample analysis:\n```\nAC-001: User can submit form with valid data\n\nTasks:\n1. Design form component API (complexity: simple)\n2. Write form component HTML\u002Fmarkup (complexity: simple)\n3. Add form validation logic (complexity: medium)\n4. Connect to API endpoint (complexity: medium)\n5. Handle submission success\u002Ferror (complexity: simple)\n6. Write tests for validation (complexity: simple)\n7. Write tests for API integration (complexity: medium)\n8. Write tests for error handling (complexity: simple)\n9. Document form API in README (complexity: simple)\n\nDependencies:\n- Depends on API endpoint being ready\n- Depends on design approval\n\nRisks:\n- API contract may change\n- Validation rules may evolve\n```\n\n### Step 2: Create Task List\n\nOrganize tasks in logical sequence:\n\n1. **Group by phase**\n   - Phase 0: Preparation (setup, planning)\n   - Phase 1: Core implementation (main code)\n   - Phase 2: Testing (test code)\n   - Phase 3: Integration (wire-up)\n   - Phase 4: Polish (documentation, refactoring)\n\n2. **Order by dependencies**\n   - Tasks with no dependencies first\n   - Tasks that depend on outputs of previous tasks\n   - Identify blocking dependencies\n\n3. **Assign IDs**\n   - Use format: TASK-NNN\n   - Link to ACs: TASK-001 (AC-001)\n   - Track in plan\n\n4. **Estimate effort**\n   - Time estimate: 30min, 1h, 2h, 4h, 1d, etc.\n   - Add contingency (10-20% for unknowns)\n   - Total per phase\n\nExample task breakdown:\n```\nPhase 1: Core Implementation\n- TASK-001 (AC-001): Design form component API - 30min\n  Dependencies: Design review\n\n- TASK-002 (AC-001): Build form HTML\u002Fmarkup - 1h\n  Dependencies: TASK-001\n\n- TASK-003 (AC-001): Add validation logic - 2h\n  Dependencies: TASK-001, specifications defined\n\n- TASK-004 (AC-001): Integration with API - 2h\n  Dependencies: TASK-001, API endpoint exists\n\nPhase 2: Testing\n- TASK-005 (AC-001): Tests for validation - 1h\n  Dependencies: TASK-003\n\n- TASK-006 (AC-001): Tests for API integration - 2h\n  Dependencies: TASK-004, test infrastructure\n\n- TASK-007 (AC-001): Tests for error handling - 1h\n  Dependencies: TASK-004\n\nPhase 3: Documentation\n- TASK-008 (AC-001): Document form API - 30min\n  Dependencies: TASK-001, TASK-004\n```\n\n### Step 3: Identify Parallelizable Work\n\nAnalyze which tasks can run in parallel:\n\n1. **Find independent task chains**\n   - Which tasks have no common dependencies?\n   - Which can start while others are in progress?\n\n2. **Group by parallelization**\n   ```\n   Sequential (must run in order):\n   - TASK-001 → TASK-002 → TASK-003 → TASK-004\n\n   Can parallelize:\n   - TASK-005 (tests) can start after TASK-003\n   - TASK-006 (API tests) can start after TASK-004\n   - TASK-008 (docs) can start after TASK-001\n\n   Optimal schedule for 2 developers:\n   Dev 1: TASK-001 → TASK-002 → TASK-003 → TASK-005\n   Dev 2: [wait] → [wait] → TASK-004 → TASK-006 → TASK-008\n   ```\n\n3. **Note team size constraints**\n   - Solo: Sequential only\n   - 2-3 people: Some parallelization\n   - Larger team: More parallelization\n\n### Step 4: Risk Assessment\n\nIdentify potential risks:\n\n1. **Technical risks**\n   - Unknown technologies\n   - Complex integrations\n   - Performance concerns\n   - Browser\u002Fplatform compatibility\n\n2. **Dependency risks**\n   - External system dependencies\n   - Third-party API changes\n   - Resource constraints\n\n3. **Scope risks**\n   - Requirements clarity\n   - Feature creep potential\n   - Scope boundary issues\n\n4. **Timeline risks**\n   - Optimistic estimates\n   - Unknown unknowns\n   - Rework potential\n\nExample:\n```\nRisk: Form validation may have complex edge cases\n- Probability: Medium (forms often have edge cases)\n- Impact: High (affects user experience)\n- Mitigation: Plan extra time for edge case testing, get spec clarity early\n\nRisk: API endpoint not ready when form code is done\n- Probability: Medium (API may slip)\n- Impact: Medium (can mock API for testing)\n- Mitigation: Start with mocked API, parallelize API development\n\nRisk: Browser compatibility issues\n- Probability: Low (using standard web APIs)\n- Impact: Medium (affects supported browsers)\n- Mitigation: Test on target browsers early\n```\n\n### Step 5: Create Plan Document\n\nWrite comprehensive plan to docs\u002Fplans\u002F{feature}-plan.md:\n\n```markdown\n# Implementation Plan: {Feature Name}\n\n**Spec Version**: {version}\n**Created**: {date}\n**Team Size**: Solo \u002F 2-3 \u002F {N}\n**Estimated Duration**: {X days\u002Fweeks}\n\n## Overview\n\n{1-2 sentence summary of what will be built}\n\n## Objectives\n\n- [Objective 1]\n- [Objective 2]\n- [Objective 3]\n\n## Success Criteria\n\n- All acceptance criteria implemented and tested\n- Code coverage >= 80%\n- All quality gates passing\n- Zero high-priority bugs\n- Documentation complete\n\n## Acceptance Criteria Analysis\n\n### AC-001: {description}\n- **Complexity**: Medium\n- **Effort Estimate**: 5 hours\n- **Tasks**:\n  - TASK-001: Subtask A\n  - TASK-002: Subtask B\n  - TASK-003: Subtask C\n- **Dependencies**: Design approval, API contract\n- **Risks**: [any specific risks]\n- **Testing Strategy**: Unit + integration tests\n\n### AC-002: {description}\n[... similar analysis]\n\n## Implementation Phases\n\n### Phase 0: Preparation (1 day)\nPreparation work before main development starts.\n\n| Task ID | Description | Effort | Dependencies | Owner |\n|---------|-------------|--------|--------------|-------|\n| TASK-001 | Review spec and get clarification | 2h | Spec complete | Dev 1 |\n| TASK-002 | Set up development environment | 2h | - | Dev 1 |\n| TASK-003 | Create test fixtures and mocks | 3h | TASK-001 | Dev 2 |\n\n**Phase Duration**: 1 day\n**Blockers**: None identified\n\n### Phase 1: Core Implementation (2-3 days)\nMain feature development.\n\n| Task ID | Description | Effort | Dependencies | Owner |\n|---------|-------------|--------|--------------|-------|\n| TASK-004 | Form component structure | 2h | TASK-001 | Dev 1 |\n| TASK-005 | Form validation logic | 4h | TASK-004 | Dev 1 |\n| TASK-006 | API integration | 3h | TASK-001, API contract | Dev 2 |\n| TASK-007 | Error handling | 2h | TASK-005, TASK-006 | Dev 2 |\n\n**Phase Duration**: 3 days (with Dev 1 and Dev 2 parallelization)\n**Blockers**: API contract must be finalized\n\n### Phase 2: Testing (1-2 days)\nComprehensive test coverage.\n\n| Task ID | Description | Effort | Dependencies | Owner |\n|---------|-------------|--------|--------------|-------|\n| TASK-008 | Unit tests for validation | 3h | TASK-005 | Dev 1 |\n| TASK-009 | Unit tests for API integration | 3h | TASK-006 | Dev 2 |\n| TASK-010 | Integration tests | 4h | TASK-005, TASK-006 | Dev 1 & 2 |\n| TASK-011 | Edge case testing | 2h | TASK-010 | Dev 2 |\n\n**Phase Duration**: 2 days\n**Blockers**: Implementation must be complete\n\n### Phase 3: Integration & Polish (1 day)\nFinal touches before merge.\n\n| Task ID | Description | Effort | Dependencies | Owner |\n|---------|-------------|--------|--------------|-------|\n| TASK-012 | Code review & refactoring | 3h | Phase 2 complete | Dev 1 & 2 |\n| TASK-013 | Documentation | 2h | Phase 1 complete | Dev 1 |\n| TASK-014 | Final QA | 2h | Phase 3 in progress | Dev 2 |\n\n**Phase Duration**: 1 day\n\n## Effort Summary\n\n| Phase | Estimated Hours | Days (1 dev) | Days (2 devs) |\n|-------|-----------------|--------------|---------------|\n| Phase 0 | 7 | 1 | 0.5 |\n| Phase 1 | 11 | 2 | 1.5 |\n| Phase 2 | 12 | 2 | 1.5 |\n| Phase 3 | 7 | 1 | 0.5 |\n| **Total** | **37** | **6** | **4** |\n\n## Dependencies\n\n### External Dependencies\n- API endpoint must be ready by Phase 1\n- Design approval by Phase 0\n\n### Internal Dependencies\n- No upstream work required\n- No blocking existing issues\n\n## Parallelization Strategy\n\nWith 2 developers:\n```\nDay 1:\n  Dev 1: TASK-001, TASK-004\n  Dev 2: TASK-002, TASK-003\n\nDay 2:\n  Dev 1: TASK-005, TASK-008\n  Dev 2: TASK-006, TASK-007\n\nDay 3:\n  Dev 1: TASK-010 (collaborative)\n  Dev 2: TASK-009, TASK-011\n\nDay 4:\n  Dev 1 & 2: TASK-012 (collaborative), TASK-013, TASK-014\n```\n\nTotal estimated time with 2 devs: **4 days**\n\n## Risk Assessment\n\n| Risk | Probability | Impact | Mitigation |\n|------|-------------|--------|-----------|\n| API contract changes | Medium | Medium | Mock API first, plan for changes |\n| Edge case bugs | Medium | Medium | Allocate time for edge case testing |\n| Rework due to requirements | Low | High | Get spec clarity upfront (TASK-001) |\n| Team member unavailable | Low | High | Document decisions, pair program |\n\n## Testing Strategy\n\n1. **Unit Tests** (Phase 2)\n   - Validation logic: 100% coverage target\n   - API integration: 90% coverage target\n   - Error handling: 100% coverage target\n\n2. **Integration Tests** (Phase 2)\n   - Form submission flow\n   - API error handling\n   - Success\u002Ferror messaging\n\n3. **Manual Testing** (Phase 3)\n   - Cross-browser testing (Chrome, Firefox, Safari, Edge)\n   - Mobile responsiveness\n   - Accessibility checks\n\n4. **Quality Gates** (Phase 3)\n   - Coverage >= 80%\n   - All tests passing\n   - Lint\u002Ftype checks passing\n   - Spec compliance verified\n\n## Deliverables\n\n### Code\n- Form component (src\u002Fcomponents\u002FForm.tsx)\n- Validation module (src\u002Fvalidation.ts)\n- API integration (src\u002Fapi\u002Fsubmit.ts)\n\n### Tests\n- Unit tests (tests\u002Fvalidation.test.ts, tests\u002Fapi.test.ts)\n- Integration tests (tests\u002Fintegration\u002Fform-submission.test.ts)\n\n### Documentation\n- Component API docs (README.md)\n- Test coverage report\n- Implementation notes\n\n## Success Metrics\n\n- [ ] All 5 acceptance criteria implemented\n- [ ] 32+ tests written and passing\n- [ ] Code coverage >= 80%\n- [ ] Zero outstanding bugs\n- [ ] All quality gates passing\n- [ ] Deployment to staging successful\n- [ ] All team members understand the code\n\n## Next Steps\n\n1. Get stakeholder approval of this plan\n2. Brief team on schedule and dependencies\n3. Begin Phase 0: Preparation\n4. Track actual time against estimates\n5. Adjust plan if blockers arise\n6. Daily standup on progress and blockers\n\n## Plan History\n\n- 2025-02-07: Initial plan created\n```\n\n## Output Format\n\nUpon completion, output:\n\n```\n# Plan Created Successfully ✓\n\n## Feature\n{feature-name} v{spec-version}\n\n## Plan Summary\n- Total Effort: {hours} hours\n- Timeline: {days} days (1 dev) \u002F {days} days (2 devs)\n- Phases: 4\n- Tasks: {count}\n- Parallelizable Tasks: {count}\n\n## Key Metrics\n- Average Task Size: {hours}h\n- Longest Critical Path: {hours}h\n- Estimated Completion: {date}\n\n## Risks Identified\n- {risk-count} risks assessed\n- Highest: {risk-name}\n- Mitigation: [brief summary]\n\n## Plan Location\ndocs\u002Fplans\u002F{feature}-plan.md\n\n## Next Steps\n1. Review and approve plan\n2. Assign team members to phases\n3. Begin Phase 0: Preparation\n4. Schedule daily standup\n5. Run \u002Fadd:tdd-cycle to execute plan\n```\n\n## Progress Tracking\n\n**Tasks to create** (mechanics per `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md`):\n\n| Phase | Subject | activeForm |\n|-------|---------|------------|\n| Read spec | Reading feature spec | Reading feature spec... |\n| Architecture | Analyzing architecture | Analyzing architecture... |\n| Tasks | Identifying and breaking down tasks | Identifying tasks... |\n| Estimation | Estimating effort and timeline | Estimating effort... |\n| Write plan | Writing plan document | Writing plan document... |\n\n## Error Handling\n\n**Spec is incomplete**\n- Halt planning\n- Report missing information\n- Ask user to complete spec before planning\n\n**Cannot parse acceptance criteria**\n- Report which AC is unparseable\n- Show the problematic text\n- Ask user to reformat AC\n\n**No configuration available**\n- Use sensible defaults (team size: solo)\n- Report defaults used\n- Continue planning\n\n## Integration with Other Skills\n\n- Spec (input) comes from specs\u002F{feature}.md\n- Plan (output) guides \u002Fadd:tdd-cycle execution\n- Effort estimates inform scheduling\n- Risk assessment informs quality gate thresholds\n- Task breakdown guides parallel work dispatch\n\n## Configuration in .add\u002Fconfig.json\n\n```json\n{\n  \"plan\": {\n    \"effortMultiplier\": 1.2,\n    \"contingency\": 0.15,\n    \"teamSize\": \"solo\",\n    \"phasesEnabled\": [\"prep\", \"impl\", \"test\", \"polish\"]\n  }\n}\n```\n\n## Plan Review Checklist\n\nBefore finalizing plan, verify:\n- [ ] All ACs are addressed by tasks\n- [ ] All tasks have effort estimates\n- [ ] Dependencies are clearly marked\n- [ ] Parallelization is identified\n- [ ] Risks are documented\n- [ ] Testing strategy is clear\n- [ ] Deliverables are listed\n- [ ] Success criteria are measurable\n\nEnd-of-skill epilogue: follow `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md` (observation + learning checkpoint + progress tracking).\n",{"references":39,"description":7,"allowed-tools":42,"argument-hint":47},[40,41],"skill-epilogue.md","rules\u002Ftelemetry.md",[43,44,45,46,27],"Read","Write","Glob","Grep","specs\u002F{feature}.md","main","e335248c85d50f73919320bc138766eb413c5ee3","plugins\u002Fadd\u002Fskills\u002Fplan",6,"https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd","https:\u002F\u002Fgetadd.dev","https:\u002F\u002Fgithub.com\u002FMountainUnicorn","2026-10-31 22:03:50",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add MountainUnicorn\u002Fadd --skill plan",{"tool":62,"command":63},"bunx","bunx skills add MountainUnicorn\u002Fadd --skill plan",{"tool":65,"command":66},"pnpm","pnpm dlx skills add MountainUnicorn\u002Fadd --skill plan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fplugins\u002Fadd\u002Fskills\u002Fplan\u002FSKILL.md",true,[],[71,79,84,89,99,126],{"skillNo":72,"name":73,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":34},"01M6CHXN68ZCGNXE9Q0K2T2RKX","add-verify","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Ftests\u002Fhooks\u002Ffixtures\u002Fdoctor\u002Fmanifest-modified\u002Fskills\u002Fadd-verify\u002FSKILL.md",[],[77,78],"add verify","verify",{"skillNo":80,"name":73,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":34},"01M6CHXJY4ZXKTNP0235A9KTNH","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Ftests\u002Fhooks\u002Ffixtures\u002Fdoctor\u002Fmanifest-missing\u002Fskills\u002Fadd-verify\u002FSKILL.md",[],[77,78],{"skillNo":85,"name":73,"nameZh":6,"description":6,"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":34},"01M6CHXG6NV1DBMWT2N6XE5555","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Ftests\u002Fhooks\u002Ffixtures\u002Fdoctor\u002Fhealthy\u002Fskills\u002Fadd-verify\u002FSKILL.md",[],[77,78],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":34},"01M6CHXDZFPEFBZ79GHP48S1BB","version","[ADD v0.11.0] Show installed version, project version, and upgrade status","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fplugins\u002Fadd\u002Fskills\u002Fversion\u002FSKILL.md",[],[91,29,96,24,27,28,97,30,32,98],"status","check","show",{"skillNo":100,"name":78,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":113,"publishedAt":34},"01M6CHXB5XG415PP88E0GACHP8","[ADD v0.11.0] Run quality gates — lint, types, tests, coverage, spec compliance","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fplugins\u002Fadd\u002Fskills\u002Fverify\u002FSKILL.md",[104,107,108],{"categoryNo":105,"categoryName":106,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":109,"categoryName":110,"taxonomyType":111,"taxonomyTypeDesc":112},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[78,29,30,114,115,32,116,117,28,24,23,118,119,120,121,122,123,27,124,125],"coverage","fix","smoke","gate","quality gates","run","lint","ci","compliance","secrets","learning","quality",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":139,"publishedAt":34},"01M6CHX8JF3M3J8BKTBW604D37","ux","[ADD v0.11.0] Iterate on UI\u002FUX design before implementation — wireframes, flow validation, and design sign-off","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fplugins\u002Fadd\u002Fskills\u002Fux\u002FSKILL.md",[132,135,136],{"categoryNo":133,"categoryName":134,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":137,"categoryName":138,"taxonomyType":111,"taxonomyTypeDesc":112},"01JBSEEDCAT000000000000032","设计师",[128,140,141,142,143,24,23,27,144,28,29,30,31,145,32,146,33,147,148],"ui","file","figma","validation","system","edit","design-system","flow","design"]