forge-speclisted

# forge-spec Turn features into spec-driven, buildable units. Two jobs: produce the **build plan** (once per project) and write a **spec file** for each unit (right before building it). Read `context/project-overview.md` and `context/architecture.md` first for context. Specs live in `context/specs/`. Create that folder if it doesn't exist. **Delegate the thinking to `forge-architect`** (the plugin's opus-pinned agent): once the target and any user clarifications are settled, spawn `forge-architect` with the job (build plan, or spec for unit NN) and the relevant user answers. It reads the context files, applies unit-rules.md and the spec template, writes the spec file(s), and returns a summary plus any open questions — relay those to the user. Spec quality is the highest-leverage point of the whole methodology, which is why this one step gets the strongest model. If the agent (or the opus model) is unavailable, do the same work in-session following the same references. ## Argument Text after the command names the target (e.g. `/forge-spec the notifications feature` → Job B for that unit; `/forge-spec build plan` → Job A). No argument → if no build plan exists, do Job A; otherwise offer to spec the next unspec'd unit in the plan. ### Specs folder layout - `context/specs/00-build-plan.md` — the build plan (see Job A). - `context/specs/NN-feature-name.md` — the spec for each **active or pending** unit. - `context/specs/archived/` — specs for **completed** units. When a uni