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: yard-documentation)
5. Documentation update task — Update README, diagrams (Mermaid, ADRs), domain docs; list concrete paths
6. Code review gate — Self-review via rails-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

Integration