brd-package

Turn the decided BRD into a package a customer can actually review: $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.

/brd-package is the BRD-to-PRD route's customer-packaging step (PM phase) — it takes the register /brd-interview wrote and the [C] questions it held, attacks the package before the customer does, and renders a bundle for a reviewer with a vanilla agent and nothing installed. Its whole discipline is one rule: everything this command emits is read by somebody outside the delivery organisation who cannot ask what a path means (${CLAUDE_PLUGIN_ROOT}/references/bundle-packaging.md §1, D12). This command exists to make that happen, not to restate it.

Usage: /brd-package <BRD-KEY> [--depends-on <BRD-KEY>…]

<BRD-KEY> still resolves through resolve-address, which searches every level workflows-core:addressing §3 bounds — three below specifications/ — and so returns a BRD that owns its source document, one of its slices, an idea-route PRD folder or an Epic folder alike, because a root must be resolved before Phase 0 step 5a can refuse it by name. Only a slice is packaged: a root BRD is refused, and packaging happens at the slice and nowhere else — a slice holds its own register, its own [C] question set and its own findings, and it is packaged from those and no others. The bundle this run builds is the bundle of the BRD it was given.

Standing rule, binding on every phase below. Nothing that names this plugin, this repository or this harness may appear in the rendered prompt, the delivery note, or any document inside the bundle. Not a path rooted at the plugin's install directory, not a references/… citation, not a slash command, not an agent or skill name, not a § section reference (${CLAUDE_PLUGIN_ROOT}/references/customer-review-schema.md §1). The section How nothing plugin-internal reaches the customer below states the ordering and the scan that make that structural rather than aspirational.

This command takes no --no-docs, and it does no documentation grounding at all. That is a decision, not an omission. /brd-intake and /prd-ground already ground this BRD against the shipped product documentation when $DOCS_PATH resolves (D22, workflows-core:docs-grounding), and /brd-interview deliberately does none for the same reason this command does none: it works on decisions already taken. This command goes one step further — it establishes no claim of its own at all. It renders what other commands recorded, and a documentation page cannot change a decision that is already in the register or a finding that is already verified; consulting one here could only introduce an ungrounded sentence into a bundle whose whole value is that every sentence in it is traceable. So there is no flag to turn off, no resolve-docs-grounding call, and no docs grounding: line in this command's report. The sentence is written here because leaving it unwritten is exactly how the gap it forecloses gets shipped.

No repository is opened, at any point. Every commit this package cites was pinned and proven clean by /prd-ground, and the repo→SHA table is read from that run's grounding/baselines.md. So there is no baseline gate here, no dirty-tree stop, and no $REPOS_PATH requirement. The three baseline-integrity commands are not re-run by this command — they are handed to the customer's reviewer, written out with the repository and the commit substituted, so the customer re-derives the pin against their own checkout rather than taking the package's word for it (workflows-core:grounding-format §4).

---

How nothing plugin-internal reaches the customer

Five properties, and every one of them is a property of the order and the inputs of the phases below, not an instruction to be careful. Together they are the guarantee; individually none of them is.