specify

Author a product specification for the resolved item: $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.

/specify is the PE-phase specification-authoring workflow — the specification step of the PM→PA→PE→Dev pipeline (/specify → specification.md; then /design → design.md). Given an Epic or PRD address, it reads the item from the specs tree, lightly scans code to ground feasibility, and authors an org-standard specification.md through a relentless one-question-at-a-time grill — resolving open questions live instead of stopping. It gates on the Opus spec-reviewer and offers to land the spec on the specs repo's main branch (via branch + PR) as Published: no.

Key distinction from /epics: /epics splits a PRD into Epic drafts; /specify authors one specification for a single item (typically an Epic). Run /epics first, then /specify per Epic.

Usage: /specify <ADDRESS> [--no-docs] [--docs <path>], where <ADDRESS> is a key or an @<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. On the BRD route the run is seeded from a reconciled BRD and the address is the PRD- slice key /brd-split carved; a BRD- container is refused (Phase 0 step 0). One address on every route: a second positional token is refused (Phase 0 step 1, SPECIFY_ONE_ADDRESS).

Phase 0 — Resolve input

1. The route is a property of the resolved folder, not of a flag.

   One resolution serves both routes now. A BRD key and a PRD key both name a folder under $SPECS_PATH/specifications/, and resolve-address resolves either — so this step no longer skips a front-end, it reads a different kind from the same resolution. What distinguishes the routes is what the resolved folder holds, not how it was addressed. The BRD route is a PRD- folder carrying a brd-link.md — the slice /brd-split carved — and nothing else.

   A BRD- container is refused, on either route. Take this on the folder step 1 resolves, the moment that resolution returns status: found and ahead of every read this command makes — and not as part of the BRD-route branch. The BRD route is detected from a brd-link.md, and a root BRD folder need not carry one: /brd-intake writes none, and only /prd-ground, /brd-split and /brd-package ever do. A refusal conditioned on the detected route would let /specify <ROOT-BRD-KEY> fall through to the keyed route and author a specification into the container. A BRD is a container: its requirements are built by the PRD- slices under it, one specification each, and a specification.md written into the container would sit beside brd/, grounding/, coverage-ledger.md and slices.md in a folder the design's §4.1 tree gives no specification. The test is the directory prefix, and never the folder's asserted kind: — /brd-split writes kind: brd into the brd-link.md inside a PRD- slice folder, so a slice asserts brd while being exactly the folder a specification belongs in, and a gate on the asserted kind would refuse every slice.

   Where the folder resolved through workflows-core:addressing §5's legacy fallback and carries no prefix, the question is answered by positive evidence that it is a BRD, never by the absence of a file — ${CLAUDE_PLUGIN_ROOT}/references/coverage-ledger-format.md §5.1, the shared authority /create-prd, /create-ard and /epics take this same test from. In short: a legacy folder carrying coverage-ledger.md or brd/brd-inventory.md, and no brd-link.md naming a parent:, is a root container; a legacy folder carrying neither of those two files is a legacy idea-route PRD folder, which holds prd.md and no brd-link.md either — this refusal does not fire on it, and refusing it would offer /product-workflows:brd-split on a folder with no coverage ledger to walk. Stop gracefully: SPECIFY_BRD_NOT_SLICED: <BRD-KEY> resolves to a BRD- container at <path>, and a BRD is never the folder a specification is authored in — its requirements are specified in the PRD- slices under it, one specification each (coverage-ledger-format.md §5). <the remedy, per the branch below>