Spec Kit

What it is

Spec Kit is GitHub's open-source take on "spec-driven development". The idea: before an agent writes code, you and the agent write down what you're building and why (the spec), then how (the plan), then a checklist of small jobs (the tasks). The agent builds from those files instead of from a single chat message.

It has two parts. A small command-line tool called specify sets up your project. Then a set of slash commands, like /speckit.specify and /speckit.plan, run inside your coding agent. It works with Claude Code, Copilot, Cursor, Codex, Gemini and dozens of other agents.

It hit version 1.0 in August 2026 and now ships a new release every few days. Besides the main build flow, it now has add-ons for fixing bugs and deciding whether an idea is worth building, plus a catalog of community extensions.

What actually happens when you use it

1. Set the rules once. /speckit.constitution writes your project's ground rules, like "always write tests" or "keep it simple". The planning step checks your design against them.
2. Describe the feature. /speckit.specify turns your description into a spec with user stories and requirements. No code or tech choices yet.
3. Fill the gaps. /speckit.clarify asks up to five questions about things you left vague, and writes your answers into the spec.
4. Choose the tech. /speckit.plan is where you say "use Next.js and Supabase". It produces the technical design.
5. Break it into tasks. /speckit.tasks writes an ordered checklist. /speckit.analyze can check the spec, plan and tasks for contradictions first.
6. Build, then check for gaps. /speckit.implement works through the tasks. /speckit.converge compares the code to the spec and adds any missed work to the list. You repeat the two until it reports nothing left.

You run each step yourself and are meant to read the result before moving on. Everything lands as Markdown files in your repo, so the spec stays around after the chat is gone.

How it differs from Superpowers

Both make your agent think before it codes, and people often lump them together. They feel quite different in use:

• Superpowers runs itself. Its skills switch on automatically while you chat. Spec Kit waits for you to type each command in order.
• Superpowers is about how the code gets built: tests first, a separate workspace, a review after each task. Spec Kit is about what gets built: a written spec, plan and task list that you keep. It doesn't force tests-first or code review unless you add them.
• With Spec Kit, the documents are the point. The spec files are meant to be kept, updated and read by people who never open Claude Code, and any supported agent can pick them up.

Pick Superpowers if you work alone, mostly in one agent, and want guardrails like tests and reviews without thinking about them. Pick Spec Kit if you want a plain-English record of what your app should do, you switch between agents, or other people need to review the plan. A DataCamp guide gives the same split and suggests combining them: Spec Kit for the spec, Superpowers to build it. Running both means two lots of ceremony and tokens, so try one first.

What people like

• It keeps the agent on track. One regular user said it enforces discipline for them and the model, stops the agent going in circles, and saves tokens overall.
• It works on existing projects. The person who asked HN whether anyone still uses it said it still gives reliably good results in existing codebases, and another agreed for new and old projects alike.
• The ground-rules file is useful on its own. A team trying it on a multi-repo feature said the constitution was valuable for onboarding both engineers and AI.
• Teams get one shared way of working. Another commenter said it stops everyone having their own one-off agent sessions and planning documents.
• A strong model can plan for a cheaper one. One user has Claude write a very detailed Spec Kit plan, then hands it to a local model to build.

What people run into

• It's a lot of overhead. The top reply in a January r/ClaudeCode thread called it too much overhead for most projects, and pointed to the lighter OpenSpec or just a folder of plan files. In a September HN thread, an OpenSpec user called OpenSpec definitely less heavy than Spec Kit.
• Lots of text to review. When Birgitta Böckeler tried it on a medium feature, one spec spread across eight repetitive files she found verbose and tedious to review. She felt plain AI coding would have been as fast. That was a 2025 version, before 1.0.
• Mixed results for some. One former regular user said they had mixed results at best, because it just moves the guesswork and the review from the code to the documents.
• Agents built into the tools now do some of this. Several people say Claude Code's own plan mode and task list cover what they used Spec Kit for.
• It can make you lazy. One hobbyist found the longer they used it, the more they fired off build loops without reading the code, and hit decisions nobody had made until mid-build.

Before you install

• Use it for features, not fixes. The docs offer a shorter path for small features and a separate add-on for bugs. The full flow on a one-line change is overkill.
• Read the spec, not just the code. The specs are plain English, which is the big upside if you don't read code. They only help if you actually check them before saying "go".
• Adding it to an existing project overwrites some files. specify init --here --force can replace files Spec Kit manages, so commit your work first.
• Community extensions aren't checked. The README says catalog listings are not audits or endorsements. Read an extension before installing it.
• Expect frequent changes. The 1.0 release notes say plainly the team expects your agent to adapt to breaking changes for you. Pin a version if you want things to stay put.
• Recent reviews are thin. Most detailed hands-on write-ups are about 2025 versions. Version 1.x adds the converge step and the bug and idea add-ons, and there's little independent feedback on those yet.

The short version

Spec Kit is the most popular way to make an agent work from a written spec, and it's backed by GitHub and very actively maintained. It shines when the spec itself matters: on teams, across several agents, or when you want a plain-English record you can check without reading code. For a solo builder doing everyday features in Claude Code, many users find plan mode, Superpowers or the lighter OpenSpec gets them most of the benefit with less paperwork.