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 Procedure step 1 (Flags first), 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 prd_dir (step 1) holds, not how it was addressed. The BRD route is a PRD- folder carrying a brd-link.md — the slice /brd-split carved, or a legacy slice with no prefix, which step 1 places as a PRD- folder by that same brd-link.md — or an EPIC- folder inside one, which carries no brd-link.md of its own and is on the BRD route by the slice it sits in (step 3's Look one level up), 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 no command writes one into a root — /brd-split places one in each slice it carves, and every command that merges depends-on: into one refuses a root. 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/, 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.