We Installed GitHub's Spec Kit. Here's What It Sets Up

If you use a coding agent, you've probably seen Spec Kit mentioned. It's GitHub's toolkit for "spec-driven development", their name for a simple idea: write the specification, the plan, and the task list before the code. You can see the shape of it in the files the kit installs. The pitch is easy to find. What's harder to find is a plain answer to the first question anyone has: what do you actually get when you install it?

We installed it in a clean container and looked. ToolRiot has no affiliate relationship with GitHub or Spec Kit; this is just the test. Exact commands and versions are in the Technical details at the end.

The install, and what appeared

One pip install, then specify init with the Claude integration selected. It finished without errors and left behind a project skeleton: the file tree lists five workflow templates, a project constitution file, shell scripts, and ten skill files named for the workflow's steps, from specify and plan through tasks and implement.

We opened the specification template, read its first sixty lines closely, and saved a full copy as evidence. It's real, structured content: prioritized user stories, each written to be independently testable, with acceptance scenarios in a given-when-then shape. The plan, task, checklist, and constitution templates we verified by their presence in the file tree, so we'll only vouch in detail for the one we read.

There's also a specify check command. In our container it ended with "Specify CLI is ready to use!" after reporting the terminal coding agents as not found and noting that the tools living inside an IDE can't be checked from a terminal. That matched our empty container.

Starting a feature

In a second run, we used the bundled script that begins each new piece of work, handing it "add tagging to notes" as the feature idea. The saved feature tree from that run lists five numbered spec folders, specs/001-tagging-notes through specs/005-tagging-notes, each holding a spec file. The JSON output for feature 005 is shown below.

That file starts as placeholders, and that's where our test stopped: the file was still a template when we finished. Our container had no connected coding agent, so everything past the scaffold stayed untested in our runs.

So here's our honest boundary: the scaffolding is real and coherent. Whether the full workflow produces better software than prompting without it is a question this test can't answer.

Who it's for

If you're already working with a coding agent on projects with more than one moving part, Spec Kit hands you a written planning structure that would otherwise take real effort to assemble. For quick scripts and single experiments, this much structure may be more than you need.

A simple way to decide: install it, run init in an empty directory, and read the specification template it gives you. That one file will tell you whether this way of working fits how you build.