to-prdlisted

# To PRD Use after `clarify-work` has resolved fuzzy terminology or scope, when the conversation still needs a durable product and engineering spec. Skip this for narrow, issue-shaped work. ## Workflow 1. Synthesize the current conversation; do not repeat a general requirements interview. 2. Inspect relevant code, the domain glossary, and applicable ADRs before drafting when they are available. Preserve established vocabulary and decisions. 3. Reuse the highest existing test seam that proves external behavior. Use nearby test prior art to identify the expected layer and observable assertions. 4. Ask at most one focused confirmation only when the highest existing test seam is genuinely unresolved after inspecting the conversation, repository, and project decisions. Wait for that answer before drafting or publishing. Otherwise continue directly to the spec. Do not use this confirmation for product, implementation or architecture, publication or access, or other blockers; record those in the spec instead. 5. Write a concise spec with these sections: Problem, Goal and solution, Prioritized user stories, Success criteria, Non-goals, Constraints, Open product decisions, Implementation decisions, and Testing decisions. 6. Detect the project issue tracker from repository configuration, remotes, or available integrations. Publish the spec to the detected project issue tracker. 7. Apply `ready-for-agent` only after every blocker is resolved and publication succeeds. Product, test-se