brd-intake

Intake the customer-supplied business requirements document: $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-intake is the entry point of the BRD-to-PRD flow (PM phase) — the first of the route's commands, which between them turn a long, often internally contradictory customer BRD into requirements a PRD can be built from. It copies the customer's source into the specs repo verbatim and immutably, extracts a [BR#n] requirement inventory via the brd-reader agent, classifies the document's defects with a human rather than on the agent's say-so alone, and writes a coverage ledger in which every requirement starts life unallocated — the state /brd-split, the route's allocation step, cannot complete past until each row has been given a fate.

Usage: /brd-intake <BRD-KEY> @<brd-file> [--sort-existing <dir>] [--no-docs] [--docs <path>]

Phase 0 — Resolve inputs

1. <BRD-KEY> (mandatory). Parse the first token that is neither a flag, nor a flag's value, nor the @<brd-file> argument — --sort-existing and --docs each consume the token after them (step 4), and a value skipped as "non-flag" would be read as the key; a token opening with @ is step 2's source wherever it stands, so an operator who types the path first is not told the key is missing; validate it with key-valid (workflows-core:addressing §1's key-valid — shape only, never checked against a tracker). If absent or invalid, stop gracefully: BRD_INTAKE_NEEDS_KEY: /brd-intake needs a BRD key (shape ^[A-Z][A-Z0-9_]*(-\d+)+$, e.g. ACME-001) — pick a short stable identifier for this business requirements document, then re-run '/product-workflows:brd-intake <KEY> @<brd-file>'.
2. @<brd-file> (mandatory). The customer's source file argument. If absent, stop: BRD_INTAKE_NEEDS_SOURCE: /brd-intake needs the customer's source as an @-argument — re-run '/product-workflows:brd-intake <KEY> @<path-to-brd>'.
3. Reject a PDF — do not convert it. If the resolved source does not end in .md/.markdown (a PDF, a Word document, a slide deck, any non-markdown source), stop: BRD_INTAKE_NEEDS_MARKDOWN: the source must be markdown — convert it first, and check the conversion. It becomes the immutable record every [BR#n] anchors into. The reason this is a hard stop rather than a best-effort conversion: once intaken, brd/source/ is never edited again (${CLAUDE_PLUGIN_ROOT}/references/brd-format.md §1), and every [BR#n] locates itself inside that text by source_anchor. An unchecked machine conversion — a dropped clause, a misplaced heading, a table read out of row order — would silently become the record of what the customer asked for, with no later step positioned to catch it. Converting is the operator's own step, done where they can eyeball the result against the original before handing it back to this command.
4. Optional flags. --sort-existing <dir> — if present, validate <dir> exists and carry it forward to Phase 6. --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 Procedure step 1 (Flags first), which resolves it; this command only has to recognise it and pass the invocation through. --no-docs — boolean; turns documentation grounding off for this run, carried to Phase 1's resolve-docs-grounding call. None of the three changes anything else about Phase 0: the BRD source is still required and still gated by step 3.
5. $SPECS_PATH (required). If unset, stop naming SPECS_PATH, per the Required path environment variable unset rule in workflows-core:escalation-rules:

   choices: ["Set SPECS_PATH (enter the path)", "Cancel"]
   

6. Specs-repo preflight. Invoke Skill(skill: "workflows-core:reference", args: "specs-repo-git specs-preflight") and execute its specs-preflight entry point (§3) inline. 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.
7. Resolve or derive the BRD folder via resolve-address <BRD-KEY> (Skill(skill: "workflows-core:reference", args: "addressing resolve-address"), §3). Found → an existing folder, and where it is a root BRD this invocation is a re-run over it; use it. Only a root is: the slice test below and the level test after it refuse every other folder. A slice is never a legitimate target here — it has no source document of its own to intake, and its inventory and ledger are created by the parent's /brd-split (${CLAUDE_PLUGIN_ROOT}/references/brd-format.md §2.1, ${CLAUDE_PLUGIN_ROOT}/references/coverage-ledger-format.md §3) — so a resolved folder whose brd-link.md carries a parent: field is a mis-keyed invocation, and the run stops on it. Take this refusal here, before the re-run confirmation below is composed, and note that it keys on parent: rather than on rows because neither of the two states a slice can be in is safe. A slice that claims any row holds an inventory with those rows in it, /brd-split having copied the parent's in, so there that confirmation would otherwise fire and be the only array the operator sees on this path — an array whose keeps-and-changes list and whose disposition warning are both written for a source-owning root, and whose Re-run over this folder answer sends Phase 2 on to write brd/source/ into a folder that holds none, Phase 3 to renumber rows §2.1 says are never re-extracted, and Phase 5 to replace every covered-here the allocate-only walk recorded with unallocated. Nothing short of git recovers that. And on a standing empty child — one kept with claims: [] against a recorded reason: (coverage-ledger-format.md §3), whose inventory holds its header and no row, which this step's own test reads as no prior inventory at all — that confirmation is skipped silently, so Phase 2 would write into the slice with no consent asked anywhere. Stop, on a slice: BRD_INTAKE_SLICE: <BRD-KEY> resolves to a slice of <the parent: field of its own brd-link.md>, and a slice has no source document to intake — the source and the records beside it under brd/ are the parent's, one hop, and the slice's own brd/brd-inventory.md and coverage-ledger.md are created by '/product-workflows:brd-split' on the parent. Re-intake the parent with '/product-workflows:brd-intake <PARENT-KEY> <the @<brd-file> this run was given>'; that run leaves every row of the parent's ledger unallocated, so re-take the dispositions with the root walk it offers you when it finishes, '/product-workflows:brd-split <PARENT-KEY> "<how to cut it>"', and only then re-allocate a slice the walk left a row unallocated in, with '/product-workflows:prd-ground <SLICE-KEY>' and then '/product-workflows:brd-split <SLICE-KEY>'. Four of the six slots are substituted and two stay literal, and the text says which. <PARENT-KEY>, and the slot naming the parent: field in the stop's first sentence, are both that parent: field as it reads, never a key parsed out of the folder's name (CLAUDE.md, Resolve an identifier against a known set); <BRD-KEY> is the address typed; and the source is the @<brd-file> this invocation was given, substituted exactly as typed — the run holds it, and it is telling the operator to re-type it against a different key. "<how to cut it>" stays literal, as Phase 8 prints its own copy, because the slicing instruction is the operator's to write; and <SLICE-KEY> stays literal because the root walk that would carve or confirm that slice has not run yet. The brd/ half is stated by what is the parent's rather than by the directory: a slice does hold a brd/ of its own, holding exactly brd/brd-inventory.md (brd-format.md §2.1) — which is why naming the whole directory the parent's would contradict the clause after it.