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-seam, implementation or architecture, publication or access, and other blockers all prevent readiness. When access allows, publish a blocked spec without the label and identify every blocker and owner.
8. Hand the published spec to decompose-to-issues; do not turn the PRD into an issue breakdown.

If no tracker or publishing access can be detected, return the finished spec with that explicit blocker. Do not invent a destination, claim publication or readiness, or hand off to decomposition.