release-notes

Draft release notes for the resolved PRD: $ARGUMENTS

Core references. A citation of the form workflows-core:<name> names a shared reference in the workflows-core plugin. Load it with Skill(skill: "workflows-core:reference", args: "<name>") — never by path: ${CLAUDE_PLUGIN_ROOT} resolves to this plugin, which does not carry it.

/release-notes produces a customer-facing release-notes draft for a resolved Product Requirements Document (or any ticket) from the resolved PRD folder. It optionally grounds the prose in merged PR diffs, renders the example-docs authored release-notes body — a plain Category: label + ### title + prose for the feature-updates / breaking-changes destinations, or one bare past-tense sentence for fixes — with no {{#internal-note}}, no identifiers, no PR links (the docs automation adds the metadata wrapper), runs a light style gate, and writes the draft to a persistent destination for the user to paste wherever their release notes are published.

Usage: /release-notes <ADDRESS> [--version <v>] [--no-docs] [--docs <path>]. --docs <path> — points documentation grounding at that root for this run instead of ${DOCS_PATH:-/workspace/docs}; strip the flag and its value together before any remaining-argument classification, or the path is read as part of the address. Declared for every consumer by workflows-core:docs-grounding §1's Flags first rung, which resolves it; this command only has to recognise it and pass the invocation through. Here <ADDRESS> is a key or an @<path> naming a folder in the specs tree.

• --version <v> (optional) — the release this note belongs to. Absent, the grill asks once; declined, the draft omits it. Never invented.

For full feature documentation use /document; for Epic drafting use /epics.

This command makes zero external API calls and never writes into the docs repo.

---

Phase 0 — Load

1. Flags. Strip every recognised flag from $ARGUMENTS before step 1 reads a positional token — --version <v> and --docs <path>, each together with the token after it, and --no-docs (boolean). Unstripped, a flag is a token like any other: --docs is read as the address, or its path is. --docs and --no-docs are carried to the resolve-docs-grounding call; --version is consumed where the version is needed.

2. Resolve the address. Parse the single positional address from $ARGUMENTS — a <KEY>, or an @<path> naming a folder or a file inside one — and resolve it with resolve-address (Skill(skill: "workflows-core:reference", args: "addressing resolve-address"), §3). Carry the resolved path, kind and key forward; ambiguous → stop, naming every match. absent is a stop, not a folder to create — this command creates no folder in the specs tree. Surface the key dir not found rule in Skill(skill: "workflows-core:reference", args: "escalation-rules") (choices: ["Re-enter key", "Cancel"]) and name what does create one: a PRD- folder comes from /product-workflows:idea <KEY> or /product-workflows:create-prd <KEY> on the idea route and from /product-workflows:brd-split on its parent BRD on the BRD route; an EPIC- folder comes from /product-workflows:epics <PRD-ADDRESS> and from no other command.

   With no positional address, stop with RELEASE_NOTES_NEEDS_KEY: /release-notes needs a PRD or Epic address — a key, or an @<path> to its folder. — this command has no direct-prompt behavior.

Specs-repo preflight. Invoke Skill(skill: "workflows-core:reference", args: "specs-repo-git specs-preflight") and execute its specs-preflight entry point (§3) inline: flush any leftover session artifacts from an earlier run, retry an artifact commit that failed to push, and settle the branch. This runs against $SPECS_PATH only — git -C "$SPECS_PATH", never a cd, so the code/docs repo this run is working in is untouched (§1 rule 1). Prompt-free and silent when the specs repo is clean and on its default branch. If a guard fires, emit its §5 notice; if it returns specs_git: blocked (§3.3 G0), carry that flag for the whole run — the terminal commit-artifacts step skips on it.