GitHub Spec Kit v1.0.4: what the scaffold proves, and what it cannot

GitHub’s Spec Kit can populate a new project directory with templates, scripts, manifests and agent-facing skills. In an empty ARM64 Linux directory, its v1.0.4 source commit created 30 files for the selected Codex integration. That is a repeatable observation about an initializer. It is not evidence that Codex discovered the skills, generated a feature or passed a test.

Reproduce the scaffold from a resolved commit

uvx --from 'git+https://github.com/github/spec-kit.git@cb610277fdea781fcfa83d20522c2db37c94068d' specify init demo --non-interactive --integration codex --script sh --ignore-agent-tools

GitHub published the v1.0.4 release on 2 September 2026.[2] A release tag is a version label, not an immutable reproduction input: GitHub currently marks this release as mutable. At the time of this test, v1.0.4 resolved through annotated tag 98d9fe5010aa7d857264e19d439782e186bf641a to commit cb610277fdea781fcfa83d20522c2db37c94068d; the annotated tag is unsigned.[6][7] The command above names that commit directly. It fixes the repository revision used here, but does not turn the scaffold into a supply-chain audit.

--non-interactive addresses initialization pickers that may otherwise wait for terminal input.[5] The associated change is limited to specify init picker paths. It does not guarantee that later agent, extension or workflow commands will be non-interactive.

Selected captured output

Selected coding agent integration: codex
Selected script type: sh
Initialize Specify Project
├── ● Install integration (Codex CLI)
├── ● Install shared infrastructure (scripts (sh) + templates)
└── ● Finalize (project ready)

Environment and method. Raspberry Pi ARM64, Linux 6.12.47, Python 3.13.5 and uv 0.11.6. The command ran once in a new empty directory. The host did not have Codex CLI installed, so --ignore-agent-tools bypassed its availability check. The resulting tree was inventoried after initialization. No agent prompt, generated specification, implementation, test suite or acceptance check was run.

What the initializer placed on disk

The commit-scoped run created 30 regular files: 10 SKILL.md files under .agents/skills, six shell scripts under .specify/scripts/bash, templates, manifests and workflow data. It did not create a .git directory. The command selected --script sh; the observed script path is reported literally rather than used to infer a portability guarantee.

The local tree matches the narrow role described by the project documentation. Spec Kit calls its approach Specification-Driven Development and documents a sequence from constitution and specification through planning, tasks, implementation and convergence.[1] The captured initializer output also names a later Codex step. Neither statement proves that a particular Codex installation discovers the files or produces a correct change.

Documentation-only Spec Kit artefact sequence: intent and design lead to a documented next agent step that was not exercised; the dashed return route is an editorial feedback suggestion. — A documentation-based process sketch. The dashed return route is editorial synthesis, not a recorded Codex execution or an automatic correctness control.[1][4]

The runtime boundary

The initializer’s success and an agent integration’s runtime behaviour are separate states. This run deliberately bypassed the Codex prerequisite check and stopped after files were written. A closed 2025 issue contains one user’s report that Spec Kit commands were not visible in that user’s Codex CLI after installation.[8] That report is not evidence of a current general defect, but it is a reason not to treat a scaffold inventory as a discoverability test.

A separate 2026 contributor report distinguishes a temporary uvx --from git+… execution from upgrading a locally installed specify command.[9] It describes a configuration issue, not a v1.0.4 benchmark. The practical limit is still useful: initialization, the installed CLI version, agent discovery and a completed feature are distinct things to verify.

What Spec Kit documents, and what a team still owns

Spec Kit’s project history describes five composable primitives: integrations, extensions, presets, workflows and workflow steps.[3] That structure permits teams to vary an integration or add domain-specific material without replacing every template. It also creates a review boundary. The project says a community-catalog listing makes a component visible, not audited or endorsed.[3]

For an existing repository, GitHub’s guide recommends choosing how specifications persist and starting from a clean tree or dedicated branch so generated changes can be reviewed together.[4] A team still has to decide which generated files to retain, which commands may modify repositories or external systems, and how a proposed patch is tested.

Limits of this observation

This run does not compare coding agents, measure productivity, assess extension safety or establish portability beyond one empty ARM64 Linux target. It does not test a brownfield repository, a forced refresh, a local CLI upgrade, skill discovery, prompt handling, generated code, security review or a test result.

The observed result is therefore precise but small: commit cb610277fdea781fcfa83d20522c2db37c94068d produced the recorded 30-file scaffold with the stated flags on this host. A useful adoption test begins after that point, with a real agent session and independently checked acceptance criteria.