prd-proposal

Author a customer-facing effort proposal for the resolved PRD folder: $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.

/prd-proposal is the effort-proposal step (PM phase) — it takes one PRD- folder, grades how much evidence stands behind it, and writes the document a vendor sends a customer: what the requirement set will take in human delivery hours, by work package and by role, as a range whose width is computed from per-package confidence and whose every cost driver resolves to a record on disk. The canonical shape of both artifacts — their section sets, the two identifier namespaces, the readiness tiers, the confidence grades and the closed evidence set — is ${CLAUDE_PLUGIN_ROOT}/references/proposal-format.md. This command executes that file; it never restates it.

Usage: /prd-proposal <ADDRESS> [--no-brief] [--profile] [--baseline <path>] [--redo]

<ADDRESS> resolves through workflows-core:addressing §3 resolve-address, taken after $SPECS_PATH is settled — a resolution taken before the variable is known returns absent for a folder that exists, which is the ordering /create-prd and /create-ard state for the same reason.

This command gates nothing on the build ladder and nothing on it waits. It gates its own input and nothing beyond it. No command of the build ladder reads proposal.md — /create-ard, /specify, /epics, /dev-workflows:design, /dev-workflows:implement and /dev-workflows:ready each resolve the same folder and neither know nor care whether it holds one — so nothing there is waiting on this run and no readiness tier withholds permission to build. The one command that reads another folder's proposal as a proposal is the sibling umbrella /product-workflows:brd-proposal, which is a second proposal rather than a phase of the build; every other targeted read is an own-folder one — a later run of this command, which opens the proposal.md it left in this same folder as §8's stability anchor (Phase 0's revision note, Phase 6 step 6), and proposal-reviewer inside the run that wrote it (Phase 9). /product-workflows:brd-reconcile's stale cross-reference sweep also reads any proposal under the parent BRD, as ordinary prose, and never edits one — a stale reference in it goes to what still needs a human, fixed by re-running this command. Running this is optional at every tier, in the same sense /prd-ground is optional and ungated on the idea route. A proposal is a document a vendor sends a customer — not a phase, not a prerequisite, and never a reason implementation cannot start.

/prd-proposal is not BRD-route-only. A PRD- folder is a PRD- folder. An idea-route PRD carrying no brd-link.md, no decisions.md and no grounding/ estimates fine — it grades at tier 1 (${CLAUDE_PLUGIN_ROOT}/references/proposal-format.md §5), and the document says outright that its drivers are unknown.

No money for human hours, at any tier, under any flag — no rate, no currency symbol, no monetary total, in either artifact or in the profile (${CLAUDE_PLUGIN_ROOT}/references/proposal-format.md §1). The USD figures this run emits at the end are model spend and are a different quantity.

Both artifacts are prose, and prose is never hard-wrapped — one unbroken line per paragraph, per workflows-core:prose-formatting, so a straight copy-paste into a review tool or a message needs no cleanup. This governs what the run writes; this command file itself stays wrapped like its neighbours.

There is no writer agent, and that is deliberate. The proposal is authored inline by this command, as prd.md, ard.md and specification.md are: the authoring is the command's purpose, and a handoff to a writer would only add a place for the resolved data set to be lost between derivation and rendering.