To Spec

Synthesize the current conversation and codebase understanding into a PRD, then publish it. Do NOT interview the user — work from what you already know. This PRD is the autonomy contract: it is the last artifact written while the human is in the room, so every decision the downstream autonomous phases (to-tasks → implement-and-review) would otherwise have to ask about must be captured here.

Process

1. Explore the repo to understand the current state, if you haven't already. Use the project's domain glossary vocabulary (CONCEPTS.md) throughout the PRD, and respect ADRs in docs/adr/ for the area you're touching. If CONCEPTS.md / docs/adr/ don't exist, synthesize from the code and note the gap — don't block on it.

2. Sketch the seams at which you'll test the feature, applying the test-lens rule: test observable external behavior at the highest seam possible, never implementation detail. Prefer existing seams to new ones; propose any new seam at the highest point you can. The fewer seams, the better — the ideal is one. Each seam you name here becomes a testable behavior to-tasks lifts into a slice's acceptance contract, so name the observable behavior at each seam, not just its location.

   Check with the user that these seams match their expectations.

3. Settle the security-gate threat-model-lite so the spec answers what the autonomous phases can't ask later. Synthesize first: if the conversation already covered the security surface (e.g. an interview run already worked the checklist), just distill those answers — don't re-ask. Only the rows the feature exposes that are still unanswered get asked now, while the human is here; security is the one area you may break the no-interview rule for, because a missing answer becomes an unanswerable gap in an autonomous phase. Record the result in the Security Decisions section below — this is the security_decisions artifact security-gate expects, and it pre-marks which surfaces are security-sensitive so to-tasks can set each slice's security: deep|standard flag as a lift, not a re-derivation.

4. Write the PRD using the template below, then publish it to the project issue tracker. Apply the ready-for-agent triage label — no need for additional triage. If no tracker is configured, write the PRD to a file at the repo root and tell the user where.

Problem Statement