Bundles come with guarantees that are rarely stated out loud: info shows exactly what install will add; installs are idempotent and confined to the project root; remove never touches components another installed bundle still needs; and every command works offline against local or pinned sources.
Two of the core extensions deserve knowing separately. The bug extension gives a repeatable assess, fix and test cycle - so the agent does not jump straight from a bug report to a patch without validating the diagnosis. The assess extension turns a raw idea into a go, needs-clarification or kill decision through a separate five-step process.
Nobody Reviewed That Third-Party Code
This is worth reading before your first extension add. The warning stands in the repository twice, word for word:
Community extensions are independently created and maintained by their respective authors. Maintainers only verify that catalog entries are complete and correctly formatted - they do not review, audit, endorse, or support the extension code itself. Review extension source code before installation and use at your own discretion.
With 158 community extensions in the catalog, that is not a formality.
What 1.0 Means
Version 1.0.0 shipped on 21 August 2026, exactly one year after the first commit. And here the project does something an anniversary release usually does not.
The README says it outright: 1.0.0 was reached not because the work is finished or the project's shape is frozen, but because the project has grown into something coherent and useful. The lead maintainer's anniversary post defines the number even more sharply: it is now just a number. The reasoning: as agents make adapting to change dramatically cheaper, the value moves from stability to adaptability.
The changelog bears this out: the 1.0.0 entry contains not a single breaking change, just ordinary fixes and catalog updates. A major version bump in the usual sense did not happen.
The pace, meanwhile, makes pinning a release tag at install time practical advice rather than theory. The changelog records 217 releases. In July 2026 there were twenty-eight of them - roughly one a day.
What to Know in Advance
The project is built for new work, not existing work. The development phases are listed plainly: building from scratch, exploring variants in parallel, and iterative enhancement. For existing code there is a separate guide and a rule about keeping tooling updates apart from the evolution of specs/ artifacts, but entering someone else's codebase through this process is noticeably harder than starting from an empty directory.
The numbers on the front page live their own life. The documentation claims 38 integrations, 157 extensions, 33 presets and 270-plus contributors. The first and third matched a count of the catalogs; on the second the catalog is one entry ahead of the text. That is normal drift, but the figures should not be taken as measurements.
The version in the source is not the version of the release. pyproject.toml on the main branch carries 1.0.2.dev0 while the latest release is 1.0.1. That is ordinary development sequencing, not a discrepancy.
Git appears in the README prerequisites with no qualification, whereas the installation guide marks it optional and needed only when the git extension is enabled. The second is correct.
Everything works offline. Environment checks, installing from locally built wheels, self-hosted catalogs - closed networks were designed for deliberately rather than covered by accident.
First-Encounter Mistakes
Starting with /speckit.plan. There is nothing to plan without a specification: only specify is required before plan.
Discussing the stack in the specification. This is the rule the documentation repeats more than any other: what and why in the spec, the stack in the plan.
Ticking the checklist on the reviewer's behalf. Those boxes mean a person checked requirements quality, not that the code is written. The agent must not change them.
Assuming git checkout switches the feature. It does not: the active feature lives in .specify/feature.json.
Running implement in one go on a large feature. The documentation advises cutting it by phase and verifying each one.
Stopping after implement. The loop is closed by converge, and it has to be repeated until it converges.
Installing a community extension without looking. Nobody reviewed its code, and the authors say so in plain words.
Running specify init in CI without --non-interactive. The command will hang on the arrow-key agent picker.
Installing without a pinned tag. At twenty-eight releases a month, reproducibility rests on the tag alone.
To put it in one sentence: Spec Kit is not selling automation but order - and its main value is not that the agent writes code faster, but that by the time it writes, you have already made the decisions it would otherwise have made for you.
Sources
This article was checked against the github/spec-kit repository (branch main) on 25 August 2026: the README, pyproject.toml, CHANGELOG.md, docs/index.md, docs/quickstart.md, docs/installation.md, docs/reference/core.md, docs/reference/agentic-sdd.md, extensions/README.md, and the catalog.json and catalog.community.json files for integrations, extensions and presets. The integration, extension and preset counts were recounted from the catalogs rather than taken from the documentation text. Stars, forks and the latest release number were taken the same day; the project releases almost daily, so versions go stale within days.
