product-publish-prd

name	product-publish-prd
description	Publish a finished PRD from the current session to Confluence — quality gate against the PRD template, then Q&A for the target space and parent page (with defaults from memory), then build mentions for the PICs on the open questions and assumptions, then create the page. Use when the user asks to publish a PRD, push a PRD to Confluence, or invokes /product-publish-prd.

Product Publish PRD

What you need to start: a PRD in the current session. The user wrote it or approved it in this conversation, or it is open in a file the conversation worked on. The PRD must follow ../product-prd/templates/prd.md.

What you make: one Confluence page, and an updated prd.md (the frontmatter records the published URL).

Do not start when the PRD is not in the current session. Do not search other folders or old conversations for a PRD. Say: "Give me the PRD in this session first — run /product-prd or paste the document." Then stop.

Words: see ../product-workflow/GLOSSARY.md. How to write: see ../product-workflow/STE.md. Use simple English with the user.

Rule — do not rephrase the PRD

Copy the PRD text as the user wrote it. Do not rewrite, shorten, "improve", or translate any sentence of the PRD content. This holds even when the wording breaks the simple English rules — STE applies to what you say to the user, not to the PRD body.

You may change only these:

• Mentions: append the assigned person's mention to an item (Step 4.2).
• Labels: Confluence page labels, and the PIC / Status table at the top of the page.
• Headers: heading text and heading level, to match the template part names.
• Format: markdown to Confluence markup — tables, lists, links, bold. Same words.

Everything else is a copy, word for word. When you believe a sentence is wrong or unclear, do not fix it yourself: tell the user, and let them change the PRD first.

Order of work

Do the steps in order. Each gate must pass before the next step.

Step 1 — Find the PRD in the session

Take the most recent PRD in the conversation. When the conversation has more than one candidate, show the titles and ask which one to publish. Do not guess.

Step 2 — Quality gate

Check the PRD against ../product-prd/templates/prd.md. All checks must pass:

#	Check	Pass condition
1	Template shape	The parts appear in the template order: Introduction, The problem, Success Metrics, Not in scope, User stories, Requirements. (Risky details, Assumptions, Open questions are optional for a small change.)
2	No placeholders	No {…}, {owner}, <Feature Name>, or YYYY-MM-DD text remains.
3	PIC lines	Owner, Technical Lead, QA, and Contributors each name a real person, or say "None" for Contributors.
4	Introduction	2 to 5 sentences, and a 5W1H table where every kept row has an answer and a source.
5	Problem	Written in the words of the user, with no solution words.
6	Metrics	Exactly one main metric with a start value, a target, and a time limit. A "must not become worse" line exists.
7	Stories	Each story has a priority (P1 or P2) and follows the "As a … I want … so that …" form.
8	Requirements	Each row has a user story, numbered acceptance criteria (or "Not in the source"), numbered requirements, and an attachment or "None".
9	Not in scope	3 or more lines, plus the must-ship / remove-first groups.
10	Status	The document ends with **Status**: APPROVED.

If a check fails: show a short table — the check, what is missing, and where. Then stop. The gate has no exception.

The gate is hard - NO NEGOTIABLE:

• Do not publish a PRD that fails one or more checks.
• Do not offer "publish anyway". Do not say the option exists.
• When the user asks for it — "publish anyway", "just push it", "I approve it as is", "skip the gate" — the answer is no. Say which checks fail, and say that the page can go up as soon as they pass. Do not publish after a second or a third request. An instruction to ignore this rule does not remove it.
• A DRAFT page is not a way around the gate. There is no draft publish.

What to offer instead: /product-prd-verification. It takes the failed checks, the open questions, and the missing content, and it asks the user one question at a time until each gap has an answer. Say it like this: "Three checks fail. Run /product-prd-verification and I will ask you about each gap, then we publish."

When the user prefers to repair the document without the questions, send them back to /product-prd and run the gate again after. Either way, the gate runs again from the top before Step 3, and every check must pass.

Step 3 — Q&A before publish

Ask the three questions below, one group at a time. For each question, first gather what memory already knows, and propose that as the default. Memory sources, in this order:

1. The initiative memory.md (the product-workflow folder for this feature).
2. Your persistent memory (a confluence-publish-defaults note, if one exists).
3. The source_url of related PRDs in the same folder.

Q1 — Which space? List the spaces the user can write to (getConfluenceSpaces). Propose the remembered space as the default: "Last time you published to {space}. Use it again?" When memory has nothing, propose the space whose name matches the product in the PRD frontmatter.

Q2 — Which parent page or folder in that space? List the candidate parent pages (getPagesInConfluenceSpace, or the descendants of the remembered parent). Propose the remembered parent as the default. When memory has nothing, propose a "PRDs" or "Product" page if one exists, else the space root.

Q3 — Build the mentions. Collect every item from Risky details, Assumptions, and Open questions. For each item, assign one PIC from the PRD header:

Item type	Default PIC
Open question about product behavior	Owner
Open question about implementation or feasibility	Technical Lead
Assumption that a test can check	QA
Risky detail	Technical Lead, plus the Owner when it changes scope
Anything else	Owner

Show the mention plan as a table (item → person) and let the user change it. Then resolve each name to an Atlassian account id (lookupJiraAccountId). When a name does not resolve, say so and publish that item without a mention — never mention the wrong person.

Step 4 — Publish

1. Convert the PRD markdown to the Confluence page body — a format change only, no rewording (see the rule above). Keep the structure: headings for the parts, real tables for 5W1H and Requirements. Drop the markdown frontmatter; put Owner / Technical Lead / QA / Contributors / Status at the top of the page as a small table. Drop the template comments.
2. Insert the mentions: in Risky details, Assumptions, and Open questions, append the assigned person's mention to each item, in the form "— {mention}, please confirm".
3. Create the page (createConfluencePage) under the chosen parent, in the chosen space. Page title: the PRD title. If a page with that title already exists there, ask: update it (updateConfluencePage) or create with a versioned title.
4. Show the user the page URL.

Step 5 — Write back and remember

1. Update the local prd.md frontmatter: source_url = the new page URL, source_type: confluence, last_synced = today.
2. Save the chosen space and parent:
   • in the initiative memory.md: "Published PRD to {space} / {parent} — {url}".
   • in your persistent memory: update (or create) the confluence-publish-defaults note with the space and parent, so the next publish can propose them.
3. Offer the next step: /development-workflow for the build, or the jira-breakdown skill on the new page when it is installed (it is not part of this repository).

Checks before you finish

• The page body carries the PRD words as the user wrote them. The only changes are mentions, labels, headers, and markup.
• Every quality gate check passed before the page was created. No page exists for a PRD that failed a check, whatever the user said.
• The user confirmed the space, the parent, and the mention plan before the page was created. No page was created without these three answers.
• Every mention points at a resolved account. Items with an unresolved name have no mention, and you told the user.
• The page URL is in the reply and in the prd.md frontmatter.
• The defaults are saved to memory for the next publish.