Generating Task Lists from User Requirements

Goal

To guide the creation of a detailed, step-by-step task list in Markdown format based on user requirements, feature requests, or existing documentation. The task list should guide a developer through implementation.

Output

• Format: Markdown (.md)
• Location: .specify/features/[feature-name]/
• Filename: tasks.md
• Full Path: .specify/features/[feature-name]/tasks.md
• Note: Use the same [feature-name] as the corresponding PRD file

Process

1. Receive Requirements: The user provides a feature request, task description, or points to existing documentation
2. Analyze Requirements: Analyze the functional requirements, user needs, and implementation scope from the provided information
3. Phase 1: Generate Parent Tasks: Based on the requirements analysis, create the file and generate the main, high-level tasks required to implement the feature. IMPORTANT: Always include task 0.0 "Create feature branch" as the first task, unless the user specifically requests not to create a branch. Use your judgement on how many additional high-level tasks to use. It's likely to be about 5. Present these tasks to the user in the specified format (without sub-tasks yet). Inform the user: "I have generated the high-level tasks based on your requirements. Ready to generate the sub-tasks? Respond with 'Go' to proceed."
4. Wait for Confirmation: Pause and wait for the user to respond with "Go".
5. Phase 2: Generate Sub-Tasks: Once the user confirms, break down each parent task into smaller, actionable sub-tasks necessary to complete the parent task. Ensure sub-tasks logically follow from the parent task and cover the implementation details implied by the requirements.
6. Identify Relevant Files: Based on the tasks and requirements, identify potential files that will need to be created or modified. List these under the Relevant Files section, including corresponding test files if applicable.
7. Generate Final Output: Combine the parent tasks, sub-tasks, relevant files, and notes into the final Markdown structure.
8. Save Task List: Save the generated document as tasks.md in .specify/features/[feature-name]/ directory, where [feature-name] matches the feature name used in the corresponding PRD. Create the feature directory if it doesn't exist. The full path will be .specify/features/[feature-name]/tasks.md.

Output Format

The generated task list must follow this structure:

markdown
1## Relevant Files
2
3- `path/to/potential/file1.ts` - Brief description of why this file is relevant (e.g., Contains the main component for
4  this feature).
5- `path/to/file1.test.ts` - Unit tests for `file1.ts`.
6- `path/to/another/file.tsx` - Brief description (e.g., API route handler for data submission).
7- `path/to/another/file.test.tsx` - Unit tests for `another/file.tsx`.
8- `lib/utils/helpers.ts` - Brief description (e.g., Utility functions needed for calculations).
9- `lib/utils/helpers.test.ts` - Unit tests for `helpers.ts`.
10
11### Notes
12
13- Unit tests should typically be placed alongside the code files they are testing (e.g., `MyComponent.tsx` and
14  `MyComponent.test.tsx` in the same directory).
15- Use `npx jest [optional/path/to/test/file]` to run tests. Running without a path executes all tests found by the Jest
16  configuration.
17
18## Instructions for Completing Tasks
19
20**IMPORTANT:** As you complete each task, you must check it off in this markdown file by changing `- [ ]` to `- [x]`.
21This helps track progress and ensures you don't skip any steps.
22
23Example:
24
25- `- [ ] 1.1 Read file` → `- [x] 1.1 Read file` (after completing)
26
27Update the file after completing each sub-task, not just after completing an entire parent task.
28
29## Tasks
30
31- [ ] 0.0 Create feature branch
32    - [ ] 0.1 Create and checkout a new branch for this feature (e.g., `git checkout -b feature/[feature-name]`)
33- [ ] 1.0 Parent Task Title
34    - [ ] 1.1 [Sub-task description 1.1]
35    - [ ] 1.2 [Sub-task description 1.2]
36- [ ] 2.0 Parent Task Title
37    - [ ] 2.1 [Sub-task description 2.1]
38- [ ] 3.0 Parent Task Title (may not require sub-tasks if purely structural or configuration)

Interaction Model

The process explicitly requires a pause after generating parent tasks to get user confirmation ("Go") before proceeding to generate the detailed sub-tasks. This ensures the high-level plan aligns with user expectations before diving into details.

Target Audience

Assume the primary reader of the task list is a junior developer who will implement the feature.