Task Management
This skill covers two workflows: generating task lists from requirements, and processing task lists one sub-task at a time.
Workflows
- •Generate Tasks - Create a detailed task list from user requirements. See
references/generate-tasks.md. - •Process Task List - Work through tasks one at a time with completion tracking. See
references/process-task-list.md.
Generate Tasks
Goal
Create 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:
/tasks/ - •Filename:
tasks-[feature-name].md
Process
- •Receive requirements: The user provides a feature request, task description, or points to existing documentation.
- •Analyze requirements: Analyze the functional requirements, user needs, and implementation scope.
- •Phase 1: Generate parent tasks: Create the main high-level tasks. Always include task 0.0 "Create feature branch" as the first task unless the user says otherwise. Present these to the user and say: "I have generated the high-level tasks based on your requirements. Ready to generate the sub-tasks? Respond with 'Go' to proceed."
- •Wait for confirmation: Pause and wait for the user to respond with "Go".
- •Phase 2: Generate sub-tasks: Break down each parent task into smaller, actionable sub-tasks.
- •Identify relevant files: List potential files that will need to be created or modified.
- •Generate final output: Combine parent tasks, sub-tasks, relevant files, and notes into the final Markdown structure.
- •Save task list: Save as
tasks-[feature-name].mdin the/tasks/directory.
For full output format details, see references/generate-tasks.md.
Target audience
Assume the primary reader is a junior developer. Requirements should be explicit and unambiguous.
Process Task List
Goal
Manage task lists in markdown files to track progress on completing a PRD.
Task implementation rules
- •One sub-task at a time: Do NOT start the next sub-task until you ask the user for permission and they say "yes" or "y".
- •Completion protocol:
- •When you finish a sub-task, immediately mark it as completed by changing
[ ]to[x]. - •If all subtasks underneath a parent task are now
[x], follow this sequence:- •Run the full test suite
- •Only if all tests pass: stage changes
- •Clean up any temporary files and temporary code before committing
- •Commit with a descriptive message using conventional commit format (
feat:,fix:,refactor:, etc.) that summarizes what was accomplished, lists key changes, and references the task number and PRD context
- •Once all subtasks are marked completed and changes have been committed, mark the parent task as completed.
- •When you finish a sub-task, immediately mark it as completed by changing
- •Stop after each sub-task and wait for the user's go-ahead.
Task list maintenance
- •
Update the task list as you work:
- •Mark tasks and subtasks as completed (
[x]) per the protocol above. - •Add new tasks as they emerge.
- •Mark tasks and subtasks as completed (
- •
Maintain the "Relevant Files" section:
- •List every file created or modified.
- •Give each file a one-line description of its purpose.
Agent instructions
When working with task lists, the agent must:
- •Regularly update the task list file after finishing any significant work.
- •Follow the completion protocol.
- •Add newly discovered tasks.
- •Keep "Relevant Files" accurate and up to date.
- •Before starting work, check which sub-task is next.
- •After completing a sub-task, update the file and then pause for user approval.
Follow the writing standards in _shared/writing-standards.md for all outputs.