← ClaudeAtlas

spec-planlisted

Use when a spec is settled and the question becomes how to build it - "how would we do this?", "what is the approach?". Produces the implementation plan, and refuses a spec that still has open questions rather than planning around them.
repository-standards/core · ★ 4 · Testing & QA · score 77
Install: claude install-skill repository-standards/core
<!-- Based on github/spec-kit v0.13.2 (MIT - scripts/spec/LICENSE). PATCHED hunks are marked inline. --> <!-- PATCHED(repository-standards): ADR-010 clarify gate - mandatory precheck before planning --> **MANDATORY PRECHECK - the clarify gate.** Before anything else in this command, run `scripts/spec/check-spec-clarified.sh <FEATURE_SPEC>` from the repo root (resolve `FEATURE_SPEC` via `scripts/spec/check-prerequisites.sh --json --paths-only`). If it exits non-zero, STOP - the gate's output is the spec's gap list (open markers of the `[NEEDS ...` family: questions, missing ADR/BDR decisions, missing inputs like a UX design, missing assets like credentials - each with its owner). Report that list to the user; run the clarify loop (`/spec-clarify`) for the questions, and do not plan a spec that is not ready-to-develop. Also glance at `docs/discovery/` (ADR-024): if the topic's dossier has entries newer than its `Last reconciled:` stamp, route them through `/spec-clarify` first - planning on a spec that ignores fresh discovery builds the wrong thing correctly. <!-- PATCHED(repository-standards): the feature-resolution engine trusts a persisted pointer over the name in front of you - close that gap before it plans the wrong spec. --> **Also confirm you are planning the right feature.** `check-prerequisites.sh` resolves `FEATURE_SPEC` from `SPECIFY_FEATURE_DIRECTORY` or the persisted `specs/feature.json` pointer, never from `$ARGUMENTS` - it does not know or care what capabi