[Spec Kit Part 2] Getting Started with Spec Kit — From Installing the specify CLI to Wiring Up Claude Code

In Part 1 we looked at where vibe coding breaks down and the core idea behind Spec-Driven Development (SDD): treating the spec as the source of truth. That's enough theory. In this post we stop talking and start typing. We'll install the specify CLI, lay down SDD scaffolding in an empty directory, and bring /speckit.* commands to life inside Claude Code — all in one pass. Along the way we'll also stand up the first skeleton of the example project we'll build throughout this series: a real-time data quality monitoring service (dq-monitor).

What you'll learn in this post

• The prerequisites for installing the specify CLI (Python 3.11+, Git, uv) and the install steps
• How to bootstrap a project with specify init and connect your AI agent
• An anatomy of the generated .specify/ scaffolding — which directory does what
• How /speckit.* slash commands become active inside Claude Code
• A preview of the /speckit.* command roadmap that runs through the entire series

This is Part 2 of the Spec Kit series. It turns the premise from Part 1 — Why Spec-Driven Development, where "the spec is the source of truth" — into an actual tool installation. If you haven't read Part 1 yet, we recommend skimming it first; every command here only makes sense on top of that premise.

1. Prerequisites — What You'll Need

The specify CLI is written in Python and uses Git during project bootstrapping. Before you start, line up these three things.

uv is a manager that installs Python packages and tools fast and isolates them without polluting your global environment. It's the install path the Spec Kit docs recommend, and pipx works as an alternative. If you don't have uv yet, install it with one line.

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
 
# Windows (PowerShell)
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

After installing, open a new shell (or source your profile to refresh PATH), then confirm all three tools resolve.

python3 --version   # Python 3.11.x or newer
git --version       # git version 2.x
uv --version        # uv 0.x

If you prefer pipx over uv, just swap uv tool install for pipx install in the install command below. This post follows the officially recommended uv.

2. Installing the Specify CLI

With the prerequisites in place, install the CLI itself. Spec Kit isn't a PyPI package — you install it directly from the GitHub repository, and it's recommended to pin a release tag at install time. Without pinning, you're at the mercy of the default branch's changes and reproducibility suffers.

uv tool install specify-cli \
  --from git+https://github.com/github/spec-kit.git@vX.Y.Z

Replace vX.Y.Z with the latest release tag. You can find it on the repository's Releases page. For example, if the latest release is v0.0.42, you'd write:

uv tool install specify-cli \
  --from git+https://github.com/github/spec-kit.git@v0.0.42

Once installed, the specify command lands on your PATH. Verify the install.

specify --help
specify check     # Check that the required runtimes/tools are present

specify check is a command that verifies up front that runtimes like Python and Git resolve correctly. If something is missing it'll bite you at the init step, so it's best to get this passing first.

Tip — why pin the version. SDD treats spec files as the source of truth. But the templates that produce those specs change from version to version. Pinning the whole team to the same tag means the same /speckit.specify yields the same artifact shape, keeping things consistent. Upgrade deliberately — by changing the tag and reinstalling.

3. Initializing the Project — specify init

Now for the main event. Let's bootstrap our example project, dq-monitor.

specify init dq-monitor --integration claude
cd dq-monitor

Here's what that one line does:

1. Creates the dq-monitor/ directory and initializes it as a Git repository.
2. Downloads templates and slash-command definitions tailored to the specified AI agent (Claude Code here) and lays them down.
3. Installs the .specify/ scaffolding the SDD workflow runs on.

What --integration decides

specify looks at your current environment and tries to auto-detect which AI agent you use. But auto-detection can miss depending on your setup, so it's safer to force it explicitly with the --integration flag. Since we use Claude Code, we passed --integration claude.

Spec Kit isn't tied to any one tool. Check the list of supported agents with:

specify integration list

This prints 30+ supported agents — not just Claude Code but GitHub Copilot, Gemini CLI, Cursor, Codex, and more. Some agents support a skills mode, in which case you append an option.

specify init dq-monitor \
  --integration claude \
  --integration-options="--skills"

The key point: specs, plans, and tasks live as text files, so your assets survive even if you switch agents. Start with Claude Code today, move to a different agent tomorrow, and the contents of specs/ and .specify/ are still reusable as-is. This is the concrete reality behind the "no lock-in" we stressed in Part 1.

Here are the init options you'll reach for most.

4. Anatomy of the Generated Scaffolding

After cd dq-monitor, look at the directory structure: the heart of it sits in the dot-prefixed .specify/ directory. SDD's "operational assets" live there.

dq-monitor/
├── .specify/
│   ├── memory/
│   │   └── constitution.md      # Project-wide governing principles (the constitution)
│   ├── templates/               # Core Spec Kit templates (spec/plan/tasks, etc.)
│   ├── presets/                 # Template customization overrides
│   └── extensions/              # Third-party capability extensions
├── specs/                       # Where per-feature artifacts accumulate (empty at first)
└── (per-agent slash-command definition files)

Here's what each directory is for.

How specs/ gets filled in later

Right now specs/ is empty, but in Part 4, running /speckit.specify creates a numbered per-feature folder. Here's the shape to expect.

specs/
└── 001-freshness-monitor/       # A feature unit (number + slug)
    ├── spec.md                  # What/why — requirements and user stories
    ├── plan.md                  # How — tech stack and architecture
    ├── tasks.md                 # Dependency-ordered task list
    ├── data-model.md            # Data model (entities and relationships)
    ├── contracts/               # API contracts (interface definitions)
    ├── research.md              # Technical research and decision records
    └── quickstart.md            # Quick-start scenario for validating the feature

This structure is SDD's source of truth. To change a feature, you edit these files first — not the code — and the code is regenerated and validated from here. The "spec → code" direction we only sketched as a diagram in Part 1, now implemented as real files on disk.

5. Connecting Your AI Agent — Bringing /speckit.* to Life in Claude Code

With the scaffolding down, it's time to make the AI agent aware of it. We'll use Claude Code, the agent our readers know.

The principle is simple. specify init --integration claude placed slash-command definition files in a format Claude Code reads at the project root. Open Claude Code from this directory and it reads those definitions, registering the /speckit.* commands as project-local slash commands.

# From inside the dq-monitor directory
claude

Once Claude Code is up, open the slash menu; if you see commands starting with /speckit, the integration succeeded. You can now invoke commands like /speckit.constitution and /speckit.specify directly inside the agent.

> /speckit.
  /speckit.constitution    Establish project principles
  /speckit.specify         Specify requirements
  /speckit.clarify         Resolve ambiguity
  /speckit.plan            Technical design
  /speckit.tasks           Task breakdown
  ... (see the table below)

Other agents work the same way. Spec Kit generates definition files in each agent's native slash-command format, so the identical /speckit.* workflow carries over to GitHub Copilot, Gemini CLI, Cursor, Codex, and more. Swap the tool; the workflow and artifacts are preserved.

6. First Contact — A Taste of /speckit.constitution and the Full Roadmap

Now that the integration checks out, let's note what the first step of the workflow is and hand off to the next post. The SDD workflow always starts with the constitution.

> /speckit.constitution

This command kicks off a conversation that fills in .specify/memory/constitution.md — the step where you agree on principles that govern the whole project: code quality, testing strategy, observability, data accuracy. How to set up a constitution that fits a data team is covered in full in Part 3. For now, just remember that the workflow starts from the constitution.

The /speckit.* command roadmap

Here's the full map of commands we'll wield across the series. Each command owns one phase of SDD and generally flows top to bottom.

To stress it again: these commands are not magic that pops out code in one shot. The source of quality is the multi-step refinement structure where a human reviews the artifacts at the end of each phase. That's also why /speckit.analyze sits after /speckit.tasks and before /speckit.implement — it's a gate that verifies the consistency of spec, plan, and tasks before you write any code.

7. From Install to First Command — The Full Flow

Here's everything so far on a single page. The setup is a straight line; the real iteration happens inside the /speckit.* workflow (from Part 3 onward).

Run through this flow once and an empty directory turns into a workshop ready to drive SDD. On disk you have .specify/; inside the agent you have /speckit.*.

Wrapping Up

In this post we came down from theory to our hands. We installed the specify CLI with uv, pinned a release tag, and stood up the example project's skeleton with specify init dq-monitor --integration claude. We dissected what each directory in the generated .specify/ scaffolding is responsible for, saw how /speckit.* commands come alive inside Claude Code, and laid out the full map of commands we'll use across the series.

The workshop is ready, but we haven't written a single line of spec yet. Good SDD starts not with code but with principles. In Part 3, we'll run the workflow's first step — /speckit.constitution — in earnest and establish the Constitution for our dq-monitor project: nailing down the principles a data team can't compromise on — data accuracy, alert reliability, observability — as the baseline that every subsequent step references.

References

• GitHub Spec Kit repository
• Spec Kit official documentation
• Spec Kit Quickstart
• Diving Into Spec-Driven Development With GitHub Spec Kit (Microsoft for Developers)