implement

Implement the following: $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.

Phase 0 — Load and classify inputs

Strip --no-commit first, before any other parsing: it is the only flag this command takes, and an unstripped flag is read as free-text prose and lands in the task description. When present, Phase 4.6 is skipped entirely and the changes are left in the working tree. It is the one opt-out from a commit that is otherwise prompt-free (${CLAUDE_PLUGIN_ROOT}/references/code-handoff.md §1 rule 5) — typed rather than clicked, which is the difference — and a run under it says once what it costs: the work is recoverable only on this machine, and /document and /release-notes will not find it later.

$ARGUMENTS may contain free-text prose plus zero or more @path tokens (today's single-@file form is a subset). Resolve each @path relative to the current working directory. Classify each @path — and the current working directory — by inspection, not by matching the path string:

Address resolution. Before the per-@path classification above, look for a single positional address in $ARGUMENTS — a <KEY>, or an @<path> naming a folder in the specs tree. Present → resolve it with resolve-address (Skill(skill: "workflows-core:reference", args: "addressing resolve-address"), §3) and the run is keyed; absent → the run is direct (free-text / @file, this command's existing flow). That is the whole mode test, and it unifies the input grammar with /document. On a <KEY>, $SPECS_PATH comes first: if it is unset, stop naming it before resolving anything (choices: ["Set SPECS_PATH (enter the path)", "Cancel"], workflows-core:escalation-rules Required path environment variable unset) — a key is found only by searching the specs tree, so with no tree the absent stop below would name the wrong cause and offer a re-enter that cannot succeed. An @<path> address needs no specs tree: it is resolved without the variable and runs on, its record written into the folder it names, and a direct run is unaffected. ambiguous is §3's hard stop, naming every match. status: absent is a stop, never a fall-through to direct mode — the key dir not found rule in workflows-core:escalation-rules (["Re-enter key", "Cancel"]), naming what creates a folder this command reads: a PRD- folder comes from /product-workflows:idea <KEY> or /product-workflows:create-prd <KEY> on the idea route and from /product-workflows:brd-split on its parent BRD on the BRD route; an EPIC- folder from /product-workflows:epics <PRD-ADDRESS>. A keyed run with no folder has nowhere for Phase 4.7's record to go.

The classification table above still applies to every other @path token: a spec folder contributes to specs, a code repo is an /implement-only scan target. Carry mode (keyed | direct), the resolved path, kind and key, and specs forward.

Epic-unit resolution (keyed runs). /implement implements one Epic at a time. When mode: keyed, place the resolved folder as workflows-core:addressing §4.1 does — by its prefix, never by the kind it asserts, which on a BRD-route slice is brd — taking its container test first. A BRD container — a BRD- folder, or a folder with no prefix holding coverage-ledger.md or brd/brd-inventory.md and no brd-link.md naming a parent: — holds no Epic to implement, because a BRD's work is authored in its slices; stop, before anything is read: IMPLEMENT_BRD_NOT_SLICED: <KEY> resolves to a BRD container at <path> — a BRD's Epics belong to its PRD- slices. <the remedy> <the remedy> lists the slices under it, found by the positive test §4.1 names — Implement within a slice instead: '/dev-workflows:implement <SLICE-KEY>' — <each slice's key>. — and, where it finds none: It has no slice yet: '/product-workflows:brd-split <KEY> "<how to cut it>"' carves one — the instruction is required there, and that run carves nothing where this BRD's ledger leaves no row unallocated. Where it leaves none, coverage-ledger-format.md §5 names two repairs, the narrow one first: hand-edit the one row to be built back to unallocated in coverage-ledger.md, leaving every other row as it stands; or, to re-take the whole inventory, re-run '/product-workflows:brd-intake <KEY> @<brd-file>', which reopens every row wherever its read finds a requirement and discards every deferred-to, rejected and superseded-by the ledger records. It is a user halt. A folder with no prefix — one §5's legacy fallback resolved, or an unprefixed folder an @<path> names, a name beginning with a kind token being prefixed only where it begins <KIND>-<the resolved key>- — is otherwise placed by positive evidence: a resolved kind: epic counts as an EPIC- folder below, and a resolved kind: prd, or a brd-link.md naming a parent:, as a PRD- folder. A folder none of these places is not guessed at — stop, naming the folder and what it carries — and, where it holds an idea.md and no prd.md, name /product-workflows:create-prd <KEY> too, whose prd.md places it (workflows-core:addressing §4.1). Then: