tdd

Context

• Repository: !git remote get-url origin
• Current branch: !git branch --show-current
• Working tree clean: !git status --short
• Feature spec: $ARGUMENTS
• Feature store: each feature lives in .feature-dev/features/<slug>/, managed by ${CLAUDE_PLUGIN_ROOT}/scripts/features.py (every call below passes --root <repo root>). Run progress is recorded there with step, never by editing a file. Layout: artifact-locations.md.

Phase 0: Resolve Spec and Validate

First, strip flags from $ARGUMENTS. --coordinator <session-name> names a live Claude Code session acting as this feature's coordinator (Phase 3 routes cross-repo questions to it). Remove the flag and its value before anything else reads $ARGUMENTS — what remains is the feature spec, and it may now be empty, which is the normal auto-discovery path. Record the name. Do not resolve or validate it yet; a coordinator that turns out to be unreachable must not block a run that is otherwise fine. Strip --pane / --no-pane too, and run ${CLAUDE_PLUGIN_ROOT}/scripts/herdr-pane.sh status once: it prints inside or outside (Herdr), and the checkpoint line below depends on it.

--pane hands the run to a fresh session. The run moves to a sibling Herdr pane in handoff mode (${CLAUDE_PLUGIN_ROOT}/references/herdr-pane.md) and this session stops: the pane gets a full context budget instead of inheriting this one. Resolve the argument to a PLAN-*.md or SPEC-*.md path first (step 1 below), then send /feature-dev:tdd <path> [--coordinator <name>] --no-pane with agent name tdd-<slug>. Phase 1b's resume re-verifies any steps already done, so handing off mid-run loses nothing. Do not run any step here after the handoff: two runs on one checkout race. Outside Herdr, say so and run here.

1. Resolve the feature spec:
   • If $ARGUMENTS is the path of an existing PLAN-*.md → read it and use it exactly as a single auto-discovered plan below (the closing lines of /feature-dev:explore-plan and /feature-dev:plan-review print this form). Its feature slug is its folder name under .feature-dev/features/; refuse any other path (a root PLAN-*.md, or the layout older than 2.0.0) in one line and name .feature-dev/features/<slug>/ as the only place plans live.
   • If $ARGUMENTS is the path of an existing SPEC-*.md → the feature slug is its folder name under .feature-dev/features/ (refuse any other path the same way). Read its feature: frontmatter value and use it as the spec; the spec path is the source spec. Then read the feature's entry from ${CLAUDE_PLUGIN_ROOT}/scripts/features.py list --json --root <repo root>:
     • If its status is implemented, say so and ask before continuing.
     • If the spec is still draft: ask once with AskUserQuestion "This spec is still a draft. Mark it approved and implement it?" (options: approve and continue / stop). Yes → run ${CLAUDE_PLUGIN_ROOT}/scripts/features.py approve <slug> --root <repo root> and continue. No → STOP and point the user to /feature-dev:review <spec path> to approve it first. Never implement from a draft.
     • If the feature already has a PLAN artifact in its entry, use that plan as the pre-selected plan (as for a PLAN-*.md argument) — a spec with a plan is not a no-plan run.
     • Otherwise there is no plan: skip the plan search in Phase 1 and take the no-plan path. This is the small-feature fallback /feature-dev:spec mentions; the spec's ACs (or its Tasks) are the reviewed anchor, the decisions go to its Decisions Log, and Phase 6 closes it. Record the run in the feature store before the first step: with the spec approved, run ${CLAUDE_PLUGIN_ROOT}/scripts/features.py plan <slug> --steps <number of ACs> --from-spec --root <repo root> (one step per AC, matching the criteria Phase 2 derives). A refusal (refused: …) names the state and the valid events; report it instead of editing feature.json.
   • If $ARGUMENTS is #N, owner/repo#N, or an issue URL → resolve it per issue-store.md's Argument parsing, then run issue-store.md's Import algorithm against it, start to finish. Do not restate Import's steps here — follow the reference; its own step 3 is where a closed issue asks before continuing, the same shape as this command's implemented check above. A failed gh preflight, or a failed gh issue view call, stops here and names the issue that could not be read. On success, continue as if $ARGUMENTS had been the resulting SPEC-<slug>.md path (the SPEC-*.md bullet above applies).
   • If $ARGUMENTS is anything else → use it as the feature spec. There is no feature in the store, so the run records no state. Continue to step 2.
   • If $ARGUMENTS is empty → run ${CLAUDE_PLUGIN_ROOT}/scripts/features.py list --json --root <repo root> (a missing .feature-dev/features/ is an empty list) and keep the features whose status is planned, running or halted and that have a PLAN artifact, plus the running or halted features with only a SPEC artifact (a run straight from the spec; for these the SPEC path stands in for the plan path below, and the run continues as for a SPEC-*.md argument):
     • 0 plans found → STOP and ask the user for a feature description.
     • 1 plan found → read its PLAN (path from artifacts), extract the feature: value from the spec when the feature has one (else the plan's title), and use that as the spec. Record the plan path as the pre-selected plan for Phase 1. Inform the user: "Auto-selected plan: <plan path> (feature: , )".
     • 2+ plans found → use AskUserQuestion to let the user pick one (label = feature name or slug, description = <slug> — <status>). The chosen feature's plan path is the pre-selected plan for Phase 1.
2. Check the working tree. Use the Working tree clean field from the Context section above — it was captured before Phase 0 ran, so an issue import in step 1 (which writes a new, untracked SPEC-<slug>.md when no local copy exists) never trips this check on its own output.
   • Clean → proceed normally. If the resolved feature is halted, still go to Phase 1b: Resume after Phase 1: it records the restart, and step done is refused until it does.
   • Dirty → this may be a halted run, not stray edits. Take the feature's status and plan.completed from list --json (a run with no feature in the store cannot be a resumable run: apply the stop below). If status is running or halted (a halt at step 1 leaves plan.completed empty and is still this command's work), the dirty tree is this command's own unfinished work → go to Phase 1b: Resume after Phase 1.
   • Dirty with no running or halted feature → STOP and ask the user to commit or stash.