# Spec Kit: specify init installs the templates, the agent's chat runs the process

> Spec Kit is a Python CLI plus a set of agent skills that impose a process on an AI coding agent. Only Spec-Driven Development is in the core package; bug fixing and idea assessment are opt-in extensions, every run is addressed by a slug you choose, and the quality gates are verdicts the agent writes about its own work.

**github/spec-kit** — Toolkit to help you get started with Spec-Driven Development. Spec Kit Define what to build before building it, with any AI coding agent.

- Repository: https://github.com/github/spec-kit
- Website: https://github.github.com/spec-kit/
- Stars: 139,409 · Forks: 12,492
- Language: Python
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/github-spec-kit

## uv tool install specify-cli, and the work happens in the chat

The install is three lines, and they are described as CLI setup only.

```bash
uv tool install specify-cli
specify init my-project --integration copilot
cd my-project
```

The requirements are Python 3.11 or newer, uv, and a supported AI coding agent on Linux, macOS or Windows. What happens next is not a command. You launch your coding agent inside the project directory and invoke each /speckit-* skill in the agent's chat, one at a time, reviewing the result before you continue, and the documentation is explicit that these are agent skills rather than terminal commands, with other agents and modes using different invocation syntax. That is the design decision to sit with: a tool whose process is a sequence of chat messages, installed by a CLI. Anything you wanted to script, schedule or put in a pull request check has to be re-thought, because the process itself does not run from a shell.

## Only Spec-Driven Development ships in core

The process table offers three entry points and is careful to say they are independent, not three mandatory phases. Build a feature or application gives you a specification carried through planning, implementation and convergence. Diagnose broken behavior gives an assessed cause, a scoped fix and a recorded verification. Decide whether an idea deserves investment gives an evidence-backed go, clarify or stop decision. Only the first is in the core package. The other two are bundled extensions you add from the project directory.

```bash
specify extension add bug
```

The assessment process has its own equivalent, `specify extension add assess`. The practical consequence is a setup mistake waiting to happen: a team that only wants help diagnosing a failing test has installed specify-cli and finds that /speckit-bug-assess does not exist until the extension is added, and the failure looks like a broken install rather than a missing opt-in. The artifacts also land in different places, with bug reports under .specify/bugs/ and assessments under .specify/assessments/, so anything you build on top has to know which process produced a given directory.

## Every skill takes a slug, and the slug names the directory

The bug path shows the addressing scheme, and it is the clearest idea in the whole tool.

```text
/speckit-bug-assess "Submitting an empty password crashes the login form." slug=login-crash
/speckit-bug-fix slug=login-crash
/speckit-bug-test slug=login-crash
```

One slug ties the three skills together, and the reports land in .specify/bugs/login-crash/. The assessment path does the same with slug=offline-mode across intake, research, define, shape and decide, ending in .specify/assessments/offline-mode/. This is a good design, because the human-readable symptom in quotes becomes a directory you can find again six weeks later. It is also an unversioned namespace that you type by hand, and the documentation does not describe what happens when two people in one project pick the same slug. Neither does it describe a way to keep two runs of the same bug apart, so the collision handling is yours to invent.

## Converged is a word the agent writes about itself

This is the part to be clear-eyed about. The Spec-Driven loop is constitution once per project, then specify, plan, tasks, implement and converge per feature, and you repeat implement and converge until convergence reports Converged. The skills are named /speckit-constitution, /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement and /speckit-converge, with clarification, checklists and consistency analysis available when you want more gates. The bug path is stricter about vocabulary: the final verdict is verified, partial or failed, and the documentation says plainly that missing verification is not a successful fix. Both are self-assessed. The agent that wrote the code is the agent that declares convergence, and nothing in this repository wires the verdict to an external test runner, so the gate is a prompt convention with three allowed words rather than a check. The one genuinely useful escape hatch is the assessment process, which treats stopping with a documented reason as a valid result.

## The wheel ships its own templates so init works air-gapped

The packaging tells you what the CLI is and what it carries.

```toml
[project]
name = "specify-cli"
version = "1.0.14.dev0"
```

It requires Python 3.11 or newer, exposes a single entry point named specify, builds with hatchling, and depends on typer and click for the command line, rich for output, readchar for interactive input, pyyaml, packaging, pathspec and json5. Then comes the part with operational consequences, a force-include block with this comment.

```toml
# Bundle core assets so `specify init` works without network access (air-gapped / enterprise)
```

So the checklist, constitution, plan, spec and tasks templates, plus vscode-settings.json, the commands, bash, PowerShell and Python scripts, and the git and agent-context extensions are all inside the wheel. An air-gapped install therefore works, and two extensions are available with no network call at all. The cost is that those templates are frozen at build time, so a template improvement reaches a disconnected team only when the CLI itself is upgraded.

## main is already 1.0.14.dev0 while the newest tag is 1.0.13

The release record is short and fast: v1.0.11 on 2026-09-24, v1.0.12 on 2026-09-25 and v1.0.13 on 2026-09-29, with the last push on 2026-09-29 and the repository not archived. The manifest on the default branch already declares 1.0.14.dev0. Two practical consequences. First, there is no slow-release comfort here: three patch versions in six days means a weekly upgrade is normal, and because the bundled templates travel inside the wheel, a patch bump can change the document skeletons your team is about to fill in. Second, the dev suffix in the branch version is a signal, not a bug, and it tells you a source checkout and a tool install are not the same artifact. Pin the version if your templates are load-bearing, because uv tool upgrade will move you a patch without anybody reviewing a diff.

## Bring your own process, through four extension points

The project's answer to disliking its process is not to leave, and the vocabulary is precise. Extensions add capabilities, presets adapt existing behaviour, workflows automate steps, and bundles package a role-based setup, with project-local overrides recommended for one-off template changes. That is a more useful answer than a single plugin system, because the four points answer different questions: whether a capability exists, whether the defaults suit your team, whether a step should happen automatically, and whether a whole role is packaged. It also means adopting Spec Kit is a set of decisions rather than one install, and the community pages for extensions, presets, bundles and walkthroughs are where those decisions get made. The only part to keep in view is that all four operate on the same core process, so a preset that changes behaviour does not change the fact that the quality gate is self-assessed.

## The repository dogfoods its own .specify/ directory

The tree is broader than a tool. Alongside src/, templates/, scripts/, tests/, extensions/, presets/, workflows/, integrations/, bundles/ and examples/ it carries docs/, design/, media/ and newsletters/, so the same repository is the documentation site, the design archive and a newsletter source. Then there are the process files: AGENTS.md, DEVELOPMENT.md, spec-driven.md, spec-kit.code-workspace, CHANGELOG.md, SECURITY.md, SUPPORT.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, CITATION.cff, .zenodo.json, a .devcontainer/, .pre-commit-config.yaml, .markdownlint-cli2.jsonc, and translated READMEs in Japanese and Simplified Chinese. The .specify/ directory at the root is the interesting one, because it means the project keeps its own specifications where the tool tells you to keep yours. That is a useful sanity check on the convention, and it also means a newcomer reading a file has to know whether they are looking at a template or at the tool before they can tell what a change would affect.

## Conclusion

Use Spec Kit when your failure mode is an agent that guesses at scope, because the process forces a written specification, a plan and a task list before code, and the bug path keeps diagnosis, repair and verification separate. Do not expect it to supply the judgement: convergence is a word the agent writes, and the bug verdict comes from the same agent that made the change. Before the first run, pick the process you actually want, since only Spec-Driven Development is in core and the other two need an extension, and pin the CLI version, because main already carries 1.0.14.dev0 while the newest tag is 1.0.13 and the templates inside the wheel are frozen at build time.

## FAQ

### What is a spec kit?

Spec Kit is a toolkit that gives an AI coding agent a structured process, with reusable templates and documented outcomes. It offers three independent entry points: Spec-Driven Development for building a feature, bug fixing for an assessed cause with a recorded verification, and idea assessment that ends in a go, clarify or stop decision.

### how to install spec-kit

You need Python 3.11 or newer, uv, and a supported AI coding agent. The documented install is `uv tool install specify-cli`, then `specify init my-project --integration copilot` and a change into the new directory, with pinned releases and other installers covered on the installation page of the documentation site.

### How do I use Spec Kit?

Launch your coding agent in the project directory and invoke the /speckit-* skills in the agent's chat, one at a time, reviewing each result before continuing. The documentation is explicit that these are agent skills rather than terminal commands, and that other agents and modes may use different invocation syntax.

### how to use spec-kit with github copilot

The examples use GitHub Copilot's default skills mode, which is what the copilot argument to specify init selects. To use another supported agent you replace copilot with your integration key, and the list of keys lives on the integrations reference page of the documentation site.

### how to use spec kit in existing project

The project keeps a dedicated guide for codebases that already exist, linked from the getting started section, and it also offers the bug fixing process, which explicitly requires no Spec-Driven Development feature workflow first. The bug skills take a slug and write their reports under .specify/bugs/.

### how to install spec kit on windows

Windows is listed as a supported platform alongside Linux and macOS, and the package bundles a scripts/powershell directory next to scripts/bash and scripts/python inside the wheel, so PowerShell is a first-class path. The same templates and commands are used on all three platforms.

## Sources

- [Official documentation](https://github.github.com/spec-kit/)
- [Official README](https://github.com/github/spec-kit#readme)
- [Project repository](https://github.com/github/spec-kit)
- [Release notes](https://github.com/github/spec-kit/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/github-spec-kit