Feature Prd Writer

Feature PRD Writer

Workflow

1. Confirm requirements are complete. If requirements are missing, ask follow-up questions before creating the doc.
2. Determine the feature name and file name.
   • Use the feature name for the H1 title.
   • Convert the feature name to lower_snake_case for the file name unless the user provides a specific file name.
   • Save the file to PRD/features/<feature_name>.md.
   • Create PRD/features if it does not exist.
   • If the file already exists, update it instead of overwriting. Ask if there is a conflict.
3. Draft the document using the template below.
4. When implementing a feature, open the existing PRD/features/<feature_name>.md and treat it as the source of truth.
   • If the doc does not exist, create it before coding.
   • If requirements or tasks are missing or unclear, ask before coding.
   • Only work on tasks listed in the doc; add new tasks to the doc first if needed.
5. Before starting a task, check its Depends field and verify each dependency task is marked complete [x] AND its TDD test has been run and passed.
   • If a dependency is not complete or its test has not passed, stop and complete/fix it first or ask to reorder the plan.
6. For each task and subtask, include a TDD line describing the test requirement.
   • When implementing a task, start by writing the test requirement first, then implement the change to make it pass (TDD).
7. As tasks are completed in later work, update the same doc by checking the task box and proceeding to the next dependent task.
8. Number tasks with a major number, and use subnumbers for any subtasks.

Template

# <Feature Name>

## Reason
<Why the feature is needed. 1-3 sentences.>

## Requirements
- <Requirement 1>
- <Requirement 2>
- <Requirement 3>

## Tasks
1. [ ] **<Task Name>**
   - Change: <What needs to change>
   - Depends on: <Task name(s) or "none">
   - TDD: <Test(s) to prove the task is done>
   1.1 [ ] **<Subtask Name>**
       - Change: <What needs to change>
       - Depends on: <Task name(s) or "none">
       - TDD: <Test(s) to prove the task is done>
   1.2 [ ] **<Subtask Name>**
       - Change: <What needs to change>
       - Depends on: <Task name(s) or "none">
       - TDD: <Test(s) to prove the task is done>
2. [ ] **<Task Name>**
   - Change: <What needs to change>
   - Depends on: <Task name(s) or "none">
   - TDD: <Test(s) to prove the task is done>

Task updates

• Mark completed tasks with [x] and leave incomplete tasks as [ ].
• Keep task order stable unless requirements change.
• When requirements change, update the Requirements section and adjust tasks and dependencies accordingly.
• When finishing a task or subtask, update the doc immediately before moving on.
• Ensure every task and subtask includes a TDD line describing the verification test(s).
• Run the TDD test(s) for a task before marking it complete.
• If a test fails, investigate, fix the issue, and rerun until it passes; only then mark the task complete.
• Write the test first (or update an existing test) before implementing the task changes.

Implementation reminders

• Start by summarizing the current task list in your response so the user can confirm scope.
• Mention which task or subtask you are starting and which ones were marked done when you finish.

When to add subtasks

• Add subtasks when a task spans multiple components, has distinct steps that can be done independently, or requires explicit sequencing.
• Skip subtasks for small, single-change tasks that are easy to describe with one Change line.
• Use 1.1, 1.2, etc. for subtasks under task 1; 2.1, 2.2 under task 2; keep numbering consistent.