docs/history.md
Spec Kit began as a toolkit for making specifications the starting point of AI-assisted development. From its first full check-in, it described three ways to apply Spec-Driven Development:
All three moved from durable planning artifacts into implementation:
Specify → Plan → Tasks → Implement
Those development paths and that core sequence remain, but the project has grown into an extensible harness for coding agents, software delivery processes, and other structured work.
Spec Kit's history includes two distinct stewardship periods. Recording them here preserves the contemporary account of the project's leadership without reducing the work to any one person.
Den Delimarsky and John Lam conceived Spec Kit and gave the project its first shape. Den authored the initial commit on August 21, 2025 and led the repository through its first months.
That founding period established the shape users still recognize: the Specify CLI, coding-agent-specific scaffolding, project constitutions, and the specification → plan → tasks → implementation process. It also framed SDD as useful for greenfield development, parallel exploration, and brownfield enhancement rather than tying the method to a single agent or development scenario.
Manfred Riem took over as lead maintainer on
January 22, 2026. The transition became publicly visible when the repository's
global CODEOWNERS entry
changed to @mnriem on February 23.
During this stewardship, the maintainer team's focus moved from building a composable model to using it to ship complete first-party processes. That shift was not sequential for the community: the modular extension system began as a community contribution, and contributors adopted and extended each primitive as it arrived.
These dates and roles are also documented in the lead maintainer's six-month retrospective and first-anniversary account, and are consistent with the repository's commit and ownership history.
The repository history begins on August 21, 2025. The first releases established the Specify CLI, reusable templates, and the core Spec-Driven Development paths. Support for multiple coding agents through centrally configured, agent-specific scaffolding was part of the project from the start, keeping the process independent of any one model or tool.
The modular extension system arrived in February as a community contribution from Michal Bachorik, allowing capabilities to be added without expanding the core process. March brought pluggable presets, which made templates and commands replaceable or composable while preserving the same CLI experience.
The founding-era agent scaffolding was rewritten as a registry-backed integration architecture. Core assets were also embedded in the Python package, enabling reliable offline and air-gapped initialization.
The workflow engine introduced catalog-distributed automation and built-in workflow step types in April. Workflows could coordinate reusable steps rather than requiring users to invoke every command manually. An integration catalog followed, making coding-agent support discoverable and independently distributable.
The composable model came to be described through five primitives:
The emphasis during these first months was on creating reusable machinery: making the process configurable, distributable, and automatable before adding more first-party processes. Community contributors did not wait for the full model to be complete; they quickly used the new extension and preset surfaces to publish their own capabilities and process variations.
For the core team, June marked the turn from mainly building primitives to using them. A workflow step catalog made custom step types community-installable, extending a primitive that had shipped with the workflow engine in April. Bundles then made it possible to package extensions, presets, workflows, and steps as a coherent setup for a role or team, optionally targeting a specific integration.
Catalogs became the bridge between the primitives and the community. Community authors built extensions, presets, integrations, workflows, step types, and bundles; the maintainer team checked submission metadata and listed accepted entries in community catalogs so users could discover and install them. A catalog listing made a component visible, but did not mean its code had been audited or endorsed.
At the same time, core maintainers began using the model to add two first-party processes alongside feature delivery:
bug extension.
Its assess → fix → test process keeps bug diagnosis, remediation, and
verification separate and documented.assess extension.
Its intake → research → define → shape → decide process evaluates an idea
before it enters SDD.Distribution broadened too: the release pipeline added PyPI publishing, and Python joined Bash and PowerShell as a supported project script type. These changes made installation and cross-platform use simpler while preserving support for offline and enterprise environments.
Spec Kit turned one and released version 1.0.0 on August 21, 2026. By then, its five primitives — integrations, extensions, presets, workflows, and workflow steps — already formed a coherent model. Bundles composed extensions, presets, workflows, and steps around a selected integration. A README refresh made the existing SDD, bug-fixing, and idea-assessment processes easier to discover through separate quickstarts.
Version 1.0.0 did not create or freeze that model; it gave the project's evolving state a round number. The documentation then reported 38 coding-agent integrations, 157 community extensions, 33 presets, and 270+ contributors. Spec Kit continues to favor adaptability: processes, integrations, and conventions can evolve while agents help projects apply those changes.
Several themes connect the project's stewardship periods and technical evolution:
This page records the project's broad evolution, not every feature or breaking change. For release-level detail, see the changelog and GitHub Releases.