spec-driven-developmentlisted

# Spec-Driven Development Write a structured specification before writing any code. The spec defines what we're building, why, and how we'll know it's done. ## Gated Workflow Four phases. Do not advance until current phase is validated by the user. ``` SPECIFY → PLAN → TASKS → IMPLEMENT ↓ ↓ ↓ ↓ Review Review Review Review ``` ## Cross-Repo Context (optional) **Skip this section entirely when `repos=` is absent.** No discovery, no subagents, no extra spec sections — this is the most important rule. When `repos=<path>` appears in `$ARGUMENTS`: - Relative paths resolve against `$HOME` (`Development/tba` → `$HOME/Development/tba`); absolute and `~/`-prefixed paths are used as-is. The path is used exactly as given — on case-sensitive filesystems the case must match exactly. - If the resolved path does not exist or contains no git repositories, skip discovery and continue as a single-repo run without failing. - The primary repo root is resolved via `git rev-parse --show-toplevel`; it is not overridable. - **Refuse** if the resolved path is `/`, `$HOME`, or a system root (`/Users`, `/home`, `/root`) — those resolve to an unbounded scan blast radius. Echo the resolved absolute path and the full candidate list before scanning begins so scope is visible before any data is read. - Discover candidates: direct children of `<path>` that have a `.git` **directory** (not a file) at their own root. A `.git` file signals a submodule or linked worktree whose