prd-alchemist

name

prd-alchemist

description

Write and update a structured Product Requirements Document (PRD) from gathered product material. Use when a product manager wants to turn discovery notes, meeting summaries, strategy input, or a rough product document into a Confluence-compatible PRD covering needs, actors, JTBD, goals, metrics, guardrails, dependencies, constraints, feasibility red flags, design discovery, open questions, and support readiness. Preserve stable English IDs, manage explicit draft-to-review readiness, and offer optional Confluence publication only after writing.

PRD Alchemist

Turn gathered product material into a structured, outcome-oriented Product Requirements Document (PRD).

The PRD explains the need, intended outcomes, constraints, and early feasibility signals. It is outcome-oriented and does not replace downstream use cases, technical specifications, acceptance criteria, QA checklists, or implementation plans.

Product managers use the PRD to align sponsors, engineers, designers, Legal/Compliance, Support/Operations, and other stakeholders before downstream solution design and delivery planning.

When to Use This Skill

Use this skill when the user wants to:

• turn gathered product material into a structured PRD;
• rewrite or update an existing PRD using the canonical hierarchy;
• fill gaps in a product document through a guided interview;
• prepare a PRD that can later be published to Confluence.

The preferred input is the output of a gathering phase plus any strategic documents, notes, links, or decisions available. If the user starts with less, ask for the missing information rather than inventing it.

Output Contract

Produce one PRD using templates/prd.md. Write it to the path requested by the user, or to prd.md in the current working directory when no path is given. Never overwrite the bundled template.

• Include the visible Metadata section from the template and set metadata.status to draft when creating or updating the PRD.
• Preserve every stable ID exactly as written. IDs are always English and are never translated, including in a translated Confluence page.
• Include every template section. For conditional sections, use Not applicable — <confirmed reason> when the user confirms they do not apply; never silently remove a section.
• Keep concrete facts traceable to source inputs.
• Do not advance the status without the explicit confirmation described below or create downstream use cases, backlog items, or implementation specifications.

PRD Writing Style

Write narrative PRD prose with an explicit subject so readers can identify who experiences a need, performs an action, owns a decision, measures an outcome, or enforces a constraint.

• Prefer active constructions that name the relevant user group, actor, team, owner, stakeholder, or system.
• Replace impersonal or subjectless phrases such as “it is necessary,” “it was decided,” “should be monitored,” or standalone infinitive instructions with a sentence that names the confirmed subject.
• When the source does not identify the subject, preserve the gap as a targeted open question. Do not invent an actor merely to complete the sentence.
• Apply this rule to narrative sentences in the PRD. Headings, stable IDs, metadata values, and intentionally compact table cells may remain fragments.

Workflow

1. Collect the writing inputs. Read the gathered material, strategic input, existing product documents, linked artifacts, and confirmed decisions. Ask for referenced material that has not been provided.
2. Map evidence to the template. Organize the input under Metadata, Need definition, Actors, Objectives, Success metrics, Strategic dependencies, Context and constraints, Initial feasibility red flags, Design discovery, Open questions, and Support readiness. Distinguish confirmed facts, proposals, assumptions, and unresolved questions.
3. Clarify selectively. Ask targeted questions for contradictions, missing ownership, unclear problem statements, unsupported metrics, or decisions that affect scope, priority, outcomes, or feasibility. Do not block creation of a draft solely because a conditional field is unknown; record the unknown as an open question or justified Not applicable value.
4. Write or update the PRD. Rewrite confirmed material into clear, outcome-oriented language whose narrative sentences identify explicit subjects. Every JTBD row must include persona, canonical job statement, expected outcome, success metric, quality guardrail, priority, and notes. Keep detailed use cases and implementation content out of the PRD.
5. Validate the document. Confirm that every stable section and field ID is present, status is valid, confirmed values are traceable, conditional sections are populated or explicitly marked not applicable, and authoring guidance is removed.
6. Handle explicit review readiness. If the user says the PRD is complete, good enough, or ready for review, verify that context, sponsor, owner, and problem are clear enough to request stakeholder feedback. Non-blocking open questions may remain. If the criterion is met, change only metadata.status from draft to review; otherwise keep draft and ask targeted questions. Never infer this transition.
7. Offer Confluence publication. After writing a new PRD, ask: "Do you want me to create a Confluence page for this PRD?" Do not publish without an affirmative answer. When handling a status-only completion request, do not offer publication unless the user separately asks for it.
8. Hand off publication. If the user confirms, invoke or hand off to the confluence-librarian skill with the PRD path, title, and any known destination details. The librarian owns publication mechanics, translation, stable-ID preservation, destination confirmation, and the final page URL.

Clarification Rules

• Ask, never infer. Do not turn a suggestion into a decision, create metrics, choose scope, assign ownership, or resolve contradictions yourself.
• Drafts may be incomplete. Missing information belongs in open questions, assumptions, or a justified Not applicable value. Do not invent a value to make the document look complete.
• Change status only on explicit confirmation. Keep metadata.status as draft unless the user explicitly confirms that the PRD is complete, good enough, or ready for review. If blockers remain, keep draft and ask about them instead.
• Keep review blockers distinct. Only missing context, sponsor, owner, or a sufficiently clear problem blocks draft → review; other open questions can remain visible in the PRD.
• Preserve competing positions. When sources disagree, state the contradiction in the clarification question and ask the decision owner to resolve it.

Stable IDs and Human Readability

The document is prose-first for people and structurally reliable for agents:

• HTML comments before headings are stable section IDs.
• The ID column in tables contains stable field or row IDs, including metadata fields such as metadata.status.
• IDs never change between revisions, even if visible headings are translated or reworded.
• Keep metadata visible in the Markdown section; do not move it to YAML frontmatter or another hidden representation.

Treat IDs as a contract. Add a new ID only for a genuinely new field; never reuse an existing ID for a different meaning.

Boundaries

• Do not perform gathering-only aggregation when the user asks for a structured PRD.
• Do not manage statuses beyond draft and review.
• Do not publish or change lifecycle state without explicit user confirmation.
• Do not include detailed use cases, technical specifications, QA, rollout, backlog, or implementation content inside the PRD; keep those details in downstream artifacts instead.