new-spec

# Skill: new-spec Create a new feature spec under `docs/specs/<feature>/` with both `spec.md` and `plan.md`. ## Output rendering Key–value / one record — For a single record's fields, use an aligned key: value list, not a two-row table. ## When to invoke The spec is the contract; the plan is the strategy. Even a one-day feature benefits from a one-paragraph spec — it forces the question "what does done look like?" before any code. ## Procedure 1. Pick a kebab-case feature name from the user's description. Keep it short and noun-y: `user-onboarding`, `webhook-retries`, not `improve-the-onboarding-experience`. 2. Create the directory and copy this skill's bundled `assets/spec.md` and `assets/plan.md` into it as `docs/specs/<feature>/spec.md` and `docs/specs/<feature>/plan.md`. (Paths are skill-relative — the `assets/` folder lives next to this `SKILL.md` wherever your installer placed the skill.) 3. **Surface assumptions before writing any spec body — and run one targeted verification check per candidate first.** With the directory scaffolded, stop. The load-bearing rule: **one targeted check per candidate assumption — a repo read, a web lookup, or a read-only probe script — not a sweep.** Then split the result into what you confirmed and what still needs the user. Draft candidates covering the three categories below, generated from this repo's actual context — the template serves multiple project types, so don't carry assumpt...