brd-interview

Turn the grounded BRD into a decided one, one round at a time: $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-interview is the BRD-to-PRD route's decision step (PM phase) — it takes the verified findings /prd-ground produced and the fully-allocated ledger /brd-split left behind, and works the BRD's open questions to recorded decisions. Its whole discipline is one rule: every question is tagged before it is asked, and the tag decides who may answer it (${CLAUDE_PLUGIN_ROOT}/references/interview-tagging.md §1). This command exists to make that happen, not to restate it.

Usage: /brd-interview <BRD-KEY> [--round N]

<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 interviewed: a root BRD is refused, and deciding happens at the slice and nowhere else — a slice holds its own findings, its own ledger, and its own register, and it reaches its decisions exactly as its parent does. The register this run writes is the register of the BRD it was given, and no other.

Standing rule, binding on every phase below. A [G] is answered from the grounding findings and is never put to a human — not the customer, not the delivery team, not the operator watching the run (interview-tagging.md §1, D8). A [V] is put to the operator with recorded argumentation and is never routed to the customer as a business question (§1, D9). A [C] is held. The section How no [G] reaches a human below states the ordering that makes the first of those 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 their run is the one that had the requirement text and the code in front of it. This command operates on decisions — on findings that have already been verified and on choices the delivery team and the customer own — and a documentation page settles none of those: it is a claim about behaviour, not the behaviour, which is why /prd-ground already forbids one as evidence for a [CG#n]. 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 file:line this command reads has already been pinned and verified by /prd-ground, so there is no baseline gate here, no dirty-tree stop, and no $REPOS_PATH requirement. A question that would need a repository opened to answer it is a question this command cannot settle, and the Answer every [G] from the findings phase says what happens to it — which is never "ask somebody instead".

---

How no [G] reaches a human

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.

1. Tagging precedes asking, for the whole set at once. The Tag every question phase runs to completion over the entire round before the Put each [V] to the operator phase opens. A question with no tag, or with more than one, does not reach an asking phase at all — it is split or rewritten where it stands.
2. The phase that answers [G] questions raises no prompt of any kind. It reads findings and writes answers. It has no AskUserQuestion call, no free-text prompt, and no "just to confirm" path, and it runs to completion before any operator prompt is opened.
3. The operator queue is whatever the tagging phase has fixed, and nothing else ever reaches it. The Put each [V] to the operator phase takes the [V] set that phase produced — including anything the [G] phase re-tagged into [V], which re-enters at tagging and is re-tested there before it joins the set (property 4). What the queue is never appended to is a question that has not been through the tagging phase: no phase adds to it directly, and once this phase opens, nothing is added to it at all. Stating it as "the [V] list alone, never appended to from another tag" would be false — a re-tagged [G] is a question from another tag, and it is supposed to arrive — and a guarantee that is false in its own ordinary case is one nobody can check the interesting case against.
4. A [G] leaves the [G] set only by re-tagging, and re-tagging re-enters at the tagging phase. It never enters the operator queue directly. And a re-tag is admissible only against a named NOT-PROVABLE finding or an unprovable verifier outcome (interview-tagging.md §3): a re-tag with no finding to name is not a re-tag, so "the code did not tell us, so let us ask someone" has no route through this command.
5. Every prompt this command raises is enumerated, and only one of them carries a question from the question set. They are: the SPECS_PATH escalation in Resolve inputs and gate the grounded BRD; the round re-open cause prompt in Resolve the round; the [V] queue and the argumentation prompt that follows each of its answers; the code-defect offer that follows it; the will-change resolution picker; the handoff choice; and the next-step offer. Only the third carries a question from the set — and the argumentation prompt inside it asks why the answer just given was given, never a question of its own.