prd-writerlisted

# PRD Writer A PRD is the input contract for the planning phase. It must contain enough context, acceptance criteria, scope boundaries, and verification detail for a planning agent to produce a plan without re-eliciting requirements. This skill is platform-agnostic. It assumes a plan → review → verify → ship flow where a PRD is written first, a planner decomposes it into steps, and a verifier checks the result against the PRD's acceptance criteria. Adapt the storage and field mechanics below to whatever tracker you use. ## Storage Location Use the tracker issue body as the default PRD location: one document per work item, one location. Avoid local sidecar files unless the repo explicitly uses them as source truth. - **Create** a PRD by creating an issue whose body is clean PRD markdown. - **Edit** a PRD by editing that issue's body. - **Version history** is the tracker's edit history — no manual `updated` field. - **The planner reads the issue body verbatim.** What you write in the body is exactly what the planning agent sees, so it must stand alone. If there is no connected tracker, decide on the single canonical location for the PRD before writing — do not draft into a throwaway scratch file that nobody will find again. ## Native Tracker Metadata Do not put YAML frontmatter at the top of issue bodies. Trackers render issue-body frontmatter as visible noise and already have native fields for this metadata. Use native tracker / project-board fields instead: - **Is