To Prd

To PRD

Turn the current conversation and codebase understanding into a product requirements document. Do not restart the interview. Synthesize what is already known and call out only genuine unresolved constraints.

The project's issue tracker and triage label vocabulary must already be known. If they are not configured, tell the user what configuration is missing before publishing.

Process

1. Explore the repository and read its domain glossary, agent instructions, architecture decisions, and relevant existing tests.
2. Sketch the highest practical external seam through which the work will be tested. Prefer one existing seam over several new seams.
3. Check that the proposed seam matches the user's expectations.
4. Write the PRD using the template below.
5. Publish it to the configured issue tracker with the ready-for-agent label.

PRD template

## Problem Statement

Describe the user's problem from the user's perspective.

## Solution

Describe the outcome from the user's perspective.

## User Stories

1. As an <actor>, I want <capability>, so that <benefit>.

## Implementation Decisions

- Capture modules and interfaces affected.
- Record architectural, schema, API, and interaction decisions.
- Avoid file paths and working code that will quickly become stale.

## Testing Decisions

- Define good tests as external behavior checks.
- Name the modules and highest seams to test.
- Point to relevant testing precedent in the codebase.

## Out of Scope

State what this PRD intentionally does not cover.

## Further Notes

Capture provenance, constraints, risks, and unresolved follow-up work.

The user story list should be extensive enough to cover happy paths, failure paths, permissions, accessibility, operations, and maintenance where relevant.