GitHub Spec Kit Deep Dive — Spec-Driven Development, the Constitution, /speckit.* Slash Commands, and the Specify CLI for Taming AI Coding Agents

As AI coding agents become routine, the most common failure mode is vibe coding: you start with a one-line prompt and the code itself silently becomes the spec. Code is inherently a binding artifact — once an implementation is locked in, every shifting requirement triggers expensive rework. GitHub Spec Kit flips this on its head. Instead of treating specifications as throwaway scaffolding you discard once "real coding" begins, it promotes the specification to a first-class, executable artifact — the heart of Spec-Driven Development (SDD).

Open-sourced by GitHub in September 2025, Spec Kit has grown into the most widely adopted SDD tool as of May 2026, with 90k+ stars and 8k+ forks. Its official docs were last updated on May 27, 2026, and it now supports 30+ coding agents. This guide breaks down the Constitution, the /speckit.* slash commands, and the Specify CLI from an operations and architecture lens — plus the rollout checklist ManoIT used internally.

1. Why Spec-Driven Development in 2026

As Microsoft's developer blog puts it, SDD is not about long requirement docs nobody reads, and it's not a return to waterfall. The point is to make technical decisions explicit, reviewable, and evolvable — "version control for your thinking." If three sprints into a notification system the PM assumed per-channel toggles, the backend built a single on/off switch, and the frontend wired up OS notifications, that's not a communication failure — it's a missing shared context. SDD surfaces those assumptions when changing direction costs a few keystrokes, not entire sprints.

This matters even more with AI agents. Because the spec lives outside the code, you can generate a Rust and a Go variant from the same spec to compare performance, or explore multiple design directions in parallel — multi-variant implementation. The spec becomes the asset that steers the agent toward the right solution.

Aspect	Traditional / Vibe Coding	Spec-Driven Development
Primary artifact	Code (spec is scaffolding, discarded)	Spec (executable, generates code)
Requirement negotiation	Negotiated in code → costly rework	Negotiated in Markdown → a few keystrokes
Decision record	Email, someone's head, scattered docs	Version-controlled spec / plan / constitution
AI agents	One-shot prompt, unpredictable result	Multi-step refinement, steered by shared context
Tool lock-in	Bound to agent / IDE	30+ swappable agents, spec stays constant

2. Specify CLI — install and bootstrap

Spec Kit has two pillars: (1) the Specify CLI (Python-based, MIT-licensed, package specify-cli) that scaffolds a project for SDD, and (2) a bundle of templates and helper scripts defining what a spec, plan, and task list look like. There is no magic beyond these two parts. Prerequisites:

• Linux / macOS / Windows (native or WSL)
• A supported AI coding agent (Copilot, Claude, Gemini, Codex, Cursor, Windsurf, and 30+ others)
• uv (recommended) or pipx for persistent install · Python 3.11+ · Git

# Persistent install (recommended) — replace vX.Y.Z with the latest Releases tag
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z

# Or bootstrap directly with a one-off run (uvx)
uvx --from git+https://github.com/github/spec-kit.git specify init my-project

# Initialize a project and pick your agent
specify init my-project --integration copilot
cd my-project

# List integrations available in your installed version
specify integration list

Initialization creates a .specify/ folder plus an agent-specific folder (e.g. .github/ for Copilot). .specify holds the spec/plan/tasks templates and the scripts for your platform (bash for POSIX, PowerShell for native Windows). And one file you may not have seen before — memory/constitution.md — is the keystone.

# Structure created after `specify init` (abridged)
my-project/
├── .github/                      # agent-specific: slash-command prompt definitions
│   └── prompts/
│       ├── specify.prompt.md
│       ├── plan.prompt.md
│       └── tasks.prompt.md
└── .specify/
    ├── memory/
    │   └── constitution.md       # non-negotiable principles (project constitution)
    ├── scripts/                  # bash or powershell helpers
    └── templates/                # spec / plan / tasks / agent-file templates

On init, Specify ensures you're inside a Git repository (creating one if needed). The helper scripts then force all work onto the same feature branch and keep subsequent prompts correctly referencing the spec, plan, and data contracts created earlier.

3. The Constitution — lock non-negotiables before any code

In SDD, the Constitution captures a project's non-negotiable principles: "web apps always follow this testing approach," "every app this team builds is CLI-first," and so on — pinned down before any SDD iteration begins. This is how organizations establish an opinionated stack that guides every new and existing project.

# Run your agent in the project dir, then first of all:
/speckit.constitution Create principles focused on code quality, testing standards, user experience consistency, and performance requirements

This creates or updates .specify/memory/constitution.md, which the agent references during the specify, plan, and implement phases. The constitution isn't just a doc — it's a guardrail that binds every subsequent step. The plan produced by /speckit.plan is grounded by the constitution, suppressing decisions that violate your conventions.

4. The core workflow — /speckit.* slash commands

At launch, Spec Kit started with three commands (/specify, /plan, /tasks). As of 2026 they've settled into a namespaced /speckit.* scheme (Codex CLI in skills mode uses $speckit-*). In one line the flow is Spec → Plan → Tasks → Implement, with the constitution and quality gates wrapped above and below.

4.1 Core commands

Command	Agent skill	Role
/speckit.constitution	speckit-constitution	Create/update governing principles and dev guidelines
/speckit.specify	speckit-specify	Define the what & why — requirements and user stories (PRD)
/speckit.plan	speckit-plan	The how — implementation plan with your chosen stack/architecture
/speckit.tasks	speckit-tasks	Break the plan into an actionable task list
/speckit.taskstoissues	speckit-taskstoissues	Convert tasks into GitHub issues for tracking/execution
/speckit.implement	speckit-implement	Execute all tasks to build the feature per the plan

/speckit.specify explicitly excludes technical decisions — you write motivations and functional requirements, not the stack. Conversely /speckit.plan handles the "how" (frameworks, libraries, DB, infra) and produces extra metadata like research, data contracts, and a quickstart so teammates can start experimenting immediately.

# Step 4: what / why (do NOT specify the stack)
/speckit.specify Build an app that organizes photos into albums grouped by date,
re-orderable by drag-and-drop on the main page, no nested albums, tile-style previews per album.

# Step 5: how (stack / architecture)
/speckit.plan Use Vite with minimal libraries. Prefer vanilla HTML/CSS/JS.
Images are not uploaded anywhere; metadata stored in local SQLite.

# Step 6: break into tasks
/speckit.tasks

# Step 7: execute implementation
/speckit.implement

4.2 Optional commands — the quality gates

Command	Agent skill	Role / recommended timing
/speckit.clarify	speckit-clarify	Resolve underspecified areas via questions — before plan (formerly /quizme)
/speckit.analyze	speckit-analyze	Cross-artifact consistency & coverage — after tasks, before implement
/speckit.checklist	speckit-checklist	Generate requirement completeness/clarity checklists ("unit tests for English")

In practice the most recommended end-to-end flow is constitution → specify → clarify → plan → tasks → analyze → implement. Filling spec gaps with clarify and verifying that spec/plan/tasks don't contradict each other with analyze before implementing is what cuts rework the most.

flowchart TD
  A["/speckit.constitution\nproject constitution = non-negotiables"] --> B["/speckit.specify\nwhat / why (PRD)"]
  B --> C["/speckit.clarify\nresolve ambiguity"]
  C --> D["/speckit.plan\nhow (stack / architecture)"]
  D --> E["/speckit.tasks\nactionable task breakdown"]
  E --> F["/speckit.analyze\nartifact consistency / coverage"]
  F --> G{"consistent?"}
  G -->|no| B
  G -->|yes| H["/speckit.implement\nexecute tasks -> code"]
  H --> I["verify: tests + manual review\ncompare spec vs implementation"]
  I --> J{"spec satisfied?"}
  J -->|no| C
  J -->|yes| K["merge / next feature branch"]
  A -. grounding .-> D
  A -. grounding .-> H

5. Extensions and presets — organizational customization

Spec Kit can be tailored via two complementary systems — Extensions and Presets — plus project-local overrides. Templates are resolved at runtime: Spec Kit walks the priority stack top-down and uses the first match.

Priority	Component	Location
1 (highest)	Project-local overrides	.specify/templates/overrides/
2	Presets — customize core & extensions	.specify/presets/templates/
3	Extensions — add new capabilities	.specify/extensions/templates/
4 (lowest)	Spec Kit Core — built-in SDD commands & templates	.specify/templates/

For integrations that support skills mode, --integration <agent> --integration-options="--skills" installs agent skills instead of slash-command prompt files — so you can ship the same SDD workflow as either slash commands or skills.

6. Limits and operational caveats — "the spec is perfect, the code is empty"

SDD is not a silver bullet. The most-raised issues in the official blog's comments map directly onto real operational risks.

• False done: the spec/plan/tasks docs read beautifully, the agent reports "implementation complete," yet much of the functionality is missing and there are zero tests. → Don't treat /speckit.implement as a trusted finish line. Pin "every feature ships with tests" into the constitution and compare implementation against the spec via checklist and real test runs.
• What goes in the spec: a fundamental question — "user stories, or some other form?" A more detailed first prompt dramatically improves spec quality, so be concrete about the experiences critical to success and what you explicitly don't want.
• Multi-agent, multi-developer: in one monorepo with devs using Cursor, Claude Code, and Gemini CLI, how do you keep a single spec? → Keep the spec outside the IDE, versioned alongside the repo. Then swapping tools still means implementing against the same contract, and the speedup comes from alignment.

In short, SDD's speed comes not from "faster typing" but from alignment — and alignment holds only when a human reviews and approves the constitution and spec to the end.

7. ManoIT internal rollout checklist

#	Task	Owner	Done criteria
1	Prep prerequisites — uv, Python 3.11+, Git; pick a standard agent	Platform	specify integration list works
2	Apply specify init --integration <agent> to a PoC repo	Lead eng	.specify/ + agent folder created
3	Author a company-standard constitution.md (tests, security, CLI-first)	Architect	Shared constitution PR merged
4	Run specify→clarify→plan once on a representative feature	Domain owners	spec/plan/data contract produced
5	Mandate the analyze consistency gate after tasks	Domain owners	implement only at zero warnings
6	Standardize checklist + real tests to prevent "false done"	QA	impl-vs-spec comparison report
7	Version specs under specs/ per feature branch	Platform	same spec reused after tool swap
8	Standardize internal templates via Extensions/Presets	DX	auto-applied on new-repo scaffolding
9	Wire taskstoissues to link tasks ↔ GitHub issues	Each team	auto-loaded onto sprint board

8. Conclusion — "intent before code, constitution above the agent"

In one line, GitHub Spec Kit is a toolkit that pins intent, plan, and principles into an executable spec before code, in order to control what AI agents output. The Constitution turns an organization's non-negotiables into a guardrail across every step, and the staged /speckit.specify → clarify → plan → tasks → analyze → implement flow separates "what/why" from "how" so each decision is reviewable. The Specify CLI bootstraps all of this across 30+ agents with near-zero config — but remember the tool itself is "not magic, just templates + scripts."

Three operational recommendations to close: (1) Start with the constitution — if you don't pin testing, security, and architecture conventions into constitution.md first, you'll be left with empty implementations behind well-written specs. (2) Don't skip clarify and analyze — resolving ambiguity and checking artifact consistency cut implementation rework the most. (3) Version specs like code — the spec must live outside the IDE in the repo so you can collaborate against the same contract even when tools change. The shortest possible advice: run specify init on one PoC repo this sprint, write your internal constitution, and complete one full pass on a representative feature.

---

This article was researched and written by ManoIT's automated blogging pipeline (Claude Opus 4.6 + Cowork Agent), using the GitHub Spec Kit official docs (github.github.com/spec-kit, updated 2026-05-27), the github/spec-kit repository README (slash commands and CLI reference), the Microsoft developer blog (Den Delimarsky, 2025-09-15) and its community discussion, and SDD adoption reporting as primary sources. Command names, CLI options, directory structure, and statistics reflect official docs as of 2026-05-31; Spec Kit is explicitly an experimental project and may change. Verify the latest commands and integration status at github.com/github/spec-kit Releases before adopting in production.

---

Originally published at ManoIT Tech Blog.