chore: bump Spec Kit to v1.0.6 and rename setup-plan's SPECS_DIR key to FEATURE_DIR - #299

Bumps this repository's pinned Spec Kit version from v1.0.4 to v1.0.6 and performs the one migration the auto-update stage correctly refused to do on its own: upstream renamed setup-plan.sh --json's feature-directory key from SPECS_DIR to FEATURE_DIR (github/spec-kit#4397, shipped in v1.0.5), and this repository had consumers hard-coded to the old name.

Why by hand

The auto-update stage evaluated v1.0.5 and routed it to a maintainer (needs-migration, see #292) because a plain pin bump would have pulled in the renamed script while leaving two consumers reading .SPECS_DIR: the speckit-plan skill's instructions, and the stage's own end-to-end self-test in auto-update-spec-kit.yml, which extracts .SPECS_DIR and fails the gate when it is absent. v1.0.6 then superseded v1.0.5 as the candidate; this PR takes the repository straight to v1.0.6.

What the prepare job would have done, done here

Mirrors the stage's prepare step byte-for-byte in shape: ran uvx --from git+https://github.com/github/[email protected] specify integration upgrade claude --script sh --force from the repo root on a clean checkout of main (all 22 vendored files matched their manifest hashes before the run, so --force overwrote nothing local), then applied the pin edits the step applies afterwards.

• .specify/init-options.json — speckit_version 1.0.4 → 1.0.6 (the pin the stage reads; the CLI wrote this itself).
• .github/actions/wing-commander-preflight/action.yml — SPECKIT_SUPPORTED_VERSION 1.0.4 → 1.0.6 (prepare's sed).
• .specify/integration.json, .specify/integrations/{claude,speckit}.manifest.json — version + per-file SHA-256 rewritten by the CLI; every hash re-verified against the LF content on disk.

What changed upstream between v1.0.4 and v1.0.6 in the files this repo vendors

Of the ~100 files upstream touched, these are the only ones that land in .specify/ or .claude/skills/speckit-*/:

• scripts/bash/setup-plan.sh → .specify/scripts/bash/setup-plan.sh: JSON key and plain-mode label SPECS_DIR → FEATURE_DIR (#4397). The value was always the feature directory; only the name changed.
• scripts/bash/create-new-feature.sh → .specify/scripts/bash/create-new-feature.sh: branch-name sanitizing made byte-identical to the Python/PowerShell twins (#4286) — LC_ALL=C so [^a-z0-9] is not collation-dependent, --* instead of GNU-only -\+, printf instead of echo so a name like -n is text.
• templates/commands/*.md → all ten .claude/skills/speckit-*/SKILL.md: the extension-hook preamble/postamble no longer says to skip silently when .specify/extensions.yml is unreadable; the agent must report the parser error and that no hooks (including mandatory ones) were checked (#4456).
• templates/commands/plan.md → speckit-plan/SKILL.md: step 1 now says "parse JSON for FEATURE_SPEC, IMPL_PLAN, FEATURE_DIR, BRANCH".
• templates/commands/tasks.md → speckit-tasks/SKILL.md: new bullet requiring data-model.md field constraints to be quoted verbatim in generated tasks (#4430).
• templates/commands/constitution.md → speckit-constitution/SKILL.md: the Sync Impact Report is described as temporary review material expected to be removed before commit (#4431).

Unchanged upstream, and therefore unchanged here: check-prerequisites.sh, common.sh, setup-tasks.sh, resolve-template.sh, all five .specify/templates/*-template.md, .specify/.gitignore.

The rename, applied to every consumer

grep -rn SPECS_DIR across the repository (including specs/, docs/, .github/) after the refresh found exactly these, all now FEATURE_DIR:

• .github/workflows/auto-update-spec-kit.yml — verify job, "End-to-end verification" step: jq -r '.FEATURE_DIR // empty', the feature_dir shell variable, and the "documented FEATURE_SPEC/IMPL_PLAN/FEATURE_DIR/BRANCH shape" failure detail. (.claude/skills/speckit-plan/SKILL.md was rewritten by the CLI, not by hand.)
• specs/034-e2e-verification-tier/contracts/e2e-verification-tier.md and research.md — describe the live assertion, updated to match.
• specs/034-e2e-verification-tier/tasks.md — T006 is a completed-task record; updated too so a future grep finds no stale mention of the old key.

The remaining SPECS_DIR hits are create-new-feature.sh's internal shell variable ($REPO_ROOT/specs), which upstream did not rename and nothing outside that script reads.

Verification

• bash .specify/scripts/bash/setup-plan.sh --json (with SPECIFY_FEATURE_DIRECTORY set, as the stage invokes it) emits {"FEATURE_SPEC":…,"IMPL_PLAN":…,"FEATURE_DIR":…,"BRANCH":…}; plain mode prints FEATURE_DIR: ….
• bash .github/scripts/auto-update-spec-kit-tests/run-tests.sh — 518 passed, 0 failed across all ten suites. t4_verify.sh Scenario 1 is the contract check here: it copies the real .specify/scripts into a fixture worktree and runs the real extracted verify step, so it only passes when the script and the self-test agree on the key.
• python .github/scripts/run-local-gates.py — 61/61 passed (the suite includes run-tests.sh as one of its gates).
• container-shell-safety skill on the edited run: step (inside verify's container: job): the step already pins shell: bash; Gate 43 passes.

Tracking issue

The stage never calls gh issue close — its own version-bump PRs close the tracking issue through GitHub's Closes #N keyword, and once the pin equals the latest upstream release detect reports up-to-date and settle is skipped, so nothing would ever touch #292 again. This PR therefore closes it the same way. It deliberately does NOT carry the stage's version-bump PR-body marker: that marker is the pr-merged job's self-recognition contract for PRs the bot opened, and on this merge that job is meant to be a no-op.

Closes #292

🤖 Generated with Claude Code