ccmanager: Command for Claude Code

Implementation Tasks

Generate detailed implementation tasks for feature: $1

Task: Generate Implementation Tasks

Prerequisites & Context Loading

• If invoked with -y flag ($2 == "-y"): Auto-approve requirements and design in spec.json
• Otherwise: Stop if requirements/design missing or unapproved with message: "Run /kiro:spec-requirements and /kiro:spec-design first, or use -y flag to auto-approve"
• If tasks.md exists: Prompt [o]verwrite/[m]erge/[c]ancel

Context Loading (Full Paths):

1. .kiro/specs/$1/requirements.md - Feature requirements (EARS format)
2. .kiro/specs/$1/design.md - Technical design document
3. .kiro/steering/ - Project-wide guidelines and constraints:
   • Core files (always load):
     • @.kiro/steering/product.md - Business context, product vision, user needs
     • @.kiro/steering/tech.md - Technology stack, frameworks, libraries
     • @.kiro/steering/structure.md - File organization, naming conventions, code patterns
   • Custom steering files (load all EXCEPT "Manual" mode in AGENTS.md):
     • Any additional *.md files in .kiro/steering/ directory
     • Examples: api.md, testing.md, security.md, etc.
   • (Task planning benefits from comprehensive context)
4. .kiro/specs/$1/tasks.md - Existing tasks (only if merge mode)

CRITICAL Task Numbering Rules (MUST FOLLOW)

⚠️ MANDATORY: Sequential major task numbering & hierarchy limits

• Major tasks: 1, 2, 3, 4, 5... (MUST increment sequentially)
• Sub-tasks: 1.1, 1.2, 2.1, 2.2... (reset per major task)
• Maximum 2 levels of hierarchy (no 1.1.1 or deeper)
• Format exactly as:

- [ ] 1. Major task description
- [ ] 1.1 Sub-task description
  - Detail item 1
  - Detail item 2
  - _Requirements: X.X, Y.Y_

- [ ] 1.2 Sub-task description
  - Detail items...
  - _Requirements: X.X_

- [ ] 2. Next major task (NOT 1 again!)
- [ ] 2.1 Sub-task...

Task Generation Rules

1. Natural language descriptions: Focus on capabilities and outcomes, not code structure
   • Describe what functionality to achieve, not file locations or code organization
   • Specify business logic and behavior, not method signatures or type definitions
   • Reference features and capabilities, not class names or API contracts
   • Use domain language, not programming constructs
   • Avoid: File paths, function/method names, type signatures, class/interface names, specific data structures
   • Include: User-facing functionality, business rules, system behaviors, data relationships
   • Implementation details (files, methods, types) come from design.md
2. Task integration & progression:
   • Each task must build on previous outputs (no orphaned code)
   • End with integration tasks to wire everything together
   • No hanging features - every component must connect to the system
   • Incremental complexity - no big jumps between tasks
   • Validate core functionality early in the sequence
3. Flexible task sizing:
   • Major tasks: As many sub-tasks as logically needed
   • Sub-tasks: 1-3 hours each, 3-10 details per sub
   • Group by cohesion, not arbitrary numbers
   • Balance between too granular and too broad
4. Requirements mapping: End details with _Requirements: X.X, Y.Y_ or _Requirements: [description]_
5. Code-only focus: Include ONLY coding/testing tasks, exclude deployment/docs/user testing