Create Tasks

Task List Generation from PRD Guide

<overview> This guide helps Claude generate detailed, step-by-step task lists in Markdown format based on existing Product Requirements Documents (PRDs). Task lists must guide developers through complete vertical implementation where each feature includes code, tests, observability, and documentation. </overview> <vertical-planning-principle> <core-philosophy> **Always Plan Features Vertically** - Each feature component must include: - Implementation code - End-to-end tests - Observability/logging - Code documentation

Critical: Do NOT bundle all testing and documentation at the end. Each task should be shippable with its complete vertical slice. </core-philosophy> </vertical-planning-principle>

<process-flow> <phase-1-input> - User provides reference to specific PRD file - Read the PRD thoroughly: introduction, goals, user stories, functional requirements, non-goals, success metrics, and open questions. If you are operating from a bug brief instead of a PRD, analyze the bug sections (summary, repro steps, scope, hypotheses, evidence) the same way. - Scan the repository (within the current context) to identify existing components, utilities, or patterns relevant to the feature. - Note any reusable code paths or conventions the implementation should respect. </phase-1-input> <phase-2-parent-tasks> - Create 4–6 high-level parent tasks that map directly to the PRD goals and functional requirements. - Each parent task should represent a complete vertical slice - Present them to the user in Markdown without sub-tasks yet and include them verbatim in your reply. - Include implementation + tests + observability + docs in each parent task scope - Inform user: "I have generated the high-level tasks based on the PRD. Ready to generate the sub-tasks? Respond with 'Go' to proceed." </phase-2-parent-tasks> <phase-3-confirmation> - MUST wait for user to respond with "Go" - Do not proceed to sub-tasks without explicit confirmation </phase-3-confirmation> <phase-4-detailed-breakdown> - Break down each parent task into actionable sub-tasks - Ensure each parent task includes its complete vertical implementation - Sub-tasks must logically follow from parent and cover all PRD requirements - Identify potential files (new or existing) that need to be created or updated, including corresponding tests. </phase-4-detailed-breakdown> <phase-5-output> - Save as `tasks-[prd-file-name].md` in `/docs/tasks/` directory - Use specified Markdown structure exactly </phase-5-output> </process-flow> <task-structure-requirements> <vertical-slice-breakdown> Each parent task should be a complete vertical slice containing: - Core implementation sub-tasks - Testing sub-tasks (integrated, not bundled at end) - Observability/logging sub-tasks - Documentation sub-tasks - Each parent task should be independently shippable </vertical-slice-breakdown> <sub-task-guidelines> - Break down parent tasks into specific, actionable items - Include file creation/modification steps - Specify testing requirements per component - Include logging/observability integration - Add documentation requirements - Ensure logical sequence within each parent task </sub-task-guidelines> </task-structure-requirements> <file-identification> <relevant-files-section> Must identify potential files needing creation/modification: - Implementation files with brief descriptions - Corresponding test files for each implementation file - Utility/helper files if needed - Configuration files if applicable - Documentation files <testing-file-conventions> - Unit tests alongside code files they test - Use project's testing framework conventions - Include test file paths in relevant files section - Reference appropriate test running commands </testing-file-conventions> </file-identification> <output-format> <required-structure> The generated task list MUST follow this exact structure: </required-structure> <filename-convention> - Format: `tasks-[prd-file-name].md` - Location: `/docs/tasks/` directory - Example: PRD `prd-user-profile-editing.md` → Task list `tasks-prd-user-profile-editing.md` </filename-convention> </output-format> <interaction-model> <two-phase-approach> 1. **Phase 1**: Generate and present parent tasks only 2. **Pause**: Wait for user confirmation with "Go" 3. **Phase 2**: Generate detailed sub-tasks after confirmation <confirmation-requirements> - Must explicitly wait for "Go" response - Do not proceed to sub-task generation without confirmation - Present parent tasks clearly before pausing </confirmation-requirements> </interaction-model> <target-audience> <primary-reader> - Junior developer implementing the feature - Needs clear, step-by-step guidance - Should understand each task's purpose and context - Must be able to ship incremental value with each parent task </primary-reader> <writing-guidelines> - Use actionable language for sub-tasks - Be specific about file operations needed - Include context for why each step is necessary - Ensure tasks build logically on each other - Make each parent task independently valuable </writing-guidelines> </target-audience> <critical-reminders> <vertical-planning> - Never bundle testing/documentation at the end - Each parent task must be a complete, shippable vertical slice - Include implementation, testing, observability, and docs in each slice - Tasks should be independently valuable and deployable </vertical-planning> <process-adherence> - Must read and analyze PRD before generating tasks - Must wait for "Go" confirmation between phases - Must use exact output format specified - Must save in correct location with correct filename </process-adherence> </critical-reminders>