generate-tasks

name	generate-tasks
license	MIT
description	Use when breaking down a feature or generating an implementation task list from a PRD. Output MUST follow this exact structure: (1) Task 0.0: Create feature branch with git checkout command, (2) Relevant Files section listing all files with concrete paths, (3) At least 3 TDD task groups with four sub-tasks each: X.Xa Write spec, X.Xb Run spec and verify it FAILS, X.Xc Implement, X.Xd Run spec and verify it PASSES, (4) YARD documentation task, (5) Documentation update task for README/diagrams, (6) Code review gate, (7) Save as tasks-[name].md in /tasks/ folder. Trigger words: task list, implementation plan, feature breakdown, todo list, project tasks, work plan, break down this PRD, generate tasks, feature branch, TDD, write spec, run spec fail, run spec pass.
metadata	{"version":"1.0.0","user-invocable":"true"}

Generating a Task List from Requirements

Output Requirements (MUST Follow)

Task 0.0 is ALWAYS "Create feature branch" unless user explicitly says otherwise.
Each sub-task MUST be a single, clear action completable in 2-5 minutes.
Sub-tasks MUST include exact file paths, not vague references.

OUTPUT MODE:
  If the user asks for strategy, sequencing, phases, or approach, produce a phased plan first.
  If the user asks for implementation tasks, checklist, or exact steps, produce the detailed mode.

Every generated task list MUST contain the following elements (see TASK_TEMPLATES.md for full template structures):

1. Task 0.0 — "Create feature branch" with checkout command (e.g., git checkout -b feature/name)
2. Relevant Files section — All files to create/modify with concrete paths, listed before Tasks
3. TDD quadruplets — At least 3 implementation groups with four sub-tasks each:
   • X.Xa Write spec at spec/...
   • X.Xb Run spec — verify it fails
   • X.Xc Implement at app/...
   • X.Xd Run spec — verify it passes
4. YARD parent task — Add YARD docs to new/changed public API; name each file (skill: write-yard-docs)
5. Documentation update task — Update README, diagrams (Mermaid, ADRs), domain docs; list concrete paths
6. Code review gate — Self-review via code-review; fix blockers before opening PR
7. Save location — tasks-[feature-name].md in /tasks/ folder

Extended Resources (Load When Needed)

Load these files only when their specific guidance is required:

• HEURISTICS.md — Use when deciding the first spec to write for a given change type (endpoint, service, job, engine, bug fix)
• TASK_TEMPLATES.md — Use when you need the full template structure for phased plans or detailed checklists

Process

1. Analyze: Extract Functional Requirements and Goals from the PRD, or use the feature description. Identify scope and main work areas.
2. Detect work type: Rails monolith, engine, API-only, background job, or external integration — affects spec paths and follow-up skills.
3. Relevant Files: List files to create or modify including tests, docs, and diagrams. Infer test command (bundle exec rspec or npm test).
4. Save: Save as tasks-[feature-name].md in /tasks/. Use the same [feature-name] as the PRD if one was provided.
5. Verify: Re-read the saved file and confirm all of the following:
   • Task 0.0 creates the feature branch
   • Relevant Files section is present
   • At least 3 implementation task groups use the full TDD sequence: write spec -> run fail -> implement -> run pass
   • YARD, documentation, and code-review parent tasks appear after implementation work

Pitfalls

Problem	Correct approach
Dependencies out of order	A task must never reference something created in a later task
No README/diagram/doc paths when integrators need updates	List concrete doc paths in Relevant Files

Integration

Skill	When to chain
create-prd	Generate PRD first, then derive tasks from it
plan-tests	When planning the best first failing spec for a Rails change
plan-tickets	When the same initiative also needs ticket drafts
triage-bug	When the request starts from a bug report