AI coding agents are powerful but undisciplined. Leave them without a persistent set of constraints and every new session starts from scratch — and your engineering standards quietly erode. That’s the problem GitHub SpecKit was built to solve.
SpecKit is Microsoft and GitHub’s open-source answer to unstructured AI-assisted development: MIT-licensed, agent-agnostic, and structured around a four-phase workflow anchored by a single governance document. If you’re evaluating where Microsoft sits in the spec-driven development landscape, this is the analysis.
What is GitHub SpecKit and how does it approach spec-driven development?
GitHub SpecKit (repo: spec-kit, CLI: specify-cli) is an open-source CLI toolkit released under the MIT licence. Its job is to replace unstructured, prompt-driven AI coding — vibe coding — with a governance-first workflow that produces versionable artefacts at every stage.
💡 Vibe coding refers to generating code through freeform AI prompting without formal specifications or persistent constraints, producing outputs that are difficult to reproduce or audit.
What sets SpecKit apart is IDE-agnostic portability. It works with 30+ AI coding agents — GitHub Copilot, Claude Code, Gemini CLI, Amazon Q, Cursor, Windsurf — without modification. Den Delimarsky from Microsoft described it at AI Dev Days as a toolkit for “product scenarios and predictable outcomes instead of vibe coding every piece from scratch.”
SpecKit is the tooling implementation of Microsoft’s Agentic-Agile framework: the idea that AI agent teams require the same discipline as human Agile teams — explicit intent, structured tasks, persistent constraints. Agents are treated as contributors, and every agent action carries the same downstream consequences as a human commit.
As of May 2026, SpecKit has 93,000+ GitHub stars. That’s a demand indicator for the spec-driven development category, not a quality rating for SpecKit specifically. Worth keeping in mind.
What is the “constitution” in GitHub SpecKit and how does it function?
The constitution.md is a project-wide constraints document. It sets out your defined engineering principles — TDD requirements, naming conventions, security baselines, architecture boundaries — and every AI agent in the workflow must respect them.
If you’ve written ADRs (Architectural Decision Records) or RFCs, the constitution does the same job. It records the persistent intent of your engineering team and makes that intent binding across all agents and workflow phases. It’s not advisory. It’s the contract between developer and agent, and a violation is a workflow failure.
One practitioner confirmed with a SpecKit maintainer that TDD requirements added to the constitution propagate through all workflow phases. The Microsoft Learn module frames it as encoding “internal engineering guidelines (security, performance, compliance)” and ensuring generated plans adhere to these constraints. The constitution is established in the Specify phase, before any code or design begins — which connects to the community principle explored in A Sufficiently Detailed Spec Is Code.
One gap worth noting: GitHub Issue #2362 documents community demand for a native security governance preset covering threat modelling, supply-chain transparency, and ASVS verification. No official preset exists yet. If your team has compliance requirements, you’ll need to author your own governance entries until native presets are released. The issue puts it well: “Projects with compliance or audit pressure need repeatable evidence locations and starter artifacts instead of ad hoc document structures.”
How does the SpecKit four-phase workflow operate in practice?
The four phases run in sequence: Specify, Plan, Tasks, and Implement. The specify-cli drives you through each phase inside a .specify project directory.
Specify: The developer documents requirements and writes the constitution.md. Nothing moves forward until governance is in place.
Plan: SpecKit generates a technical design with AI assistance. Constitution constraints are active throughout — no design decision can contradict them. Output: plan.md.
Tasks: The design is broken into discrete, executable agent tasks — an auditable checkpoint where engineering leads can review before execution begins. Output: tasks.md. This is the phase that structurally separates SpecKit from tools that hand a design straight to an agent.
Implement: AI agents execute the task list against the spec and constitution. In one independent evaluation, it took roughly 90 minutes to reach spec, plan, and task breakdown, followed by about 35 minutes of agent execution. Once artefacts are version-controlled, you can swap agents over time without touching the spec format.
Microsoft has also published a 13-unit Microsoft Learn curriculum covering Azure DevOps integration and multi-agent collaboration — a solid credibility signal for enterprise evaluation.
How does SpecKit compare to AWS Kiro on philosophy and workflow?
SpecKit and Kiro represent different bets about what AI coding governance actually means. SpecKit is a governance layer — a persistent constraints document that defines what every agent is allowed to do, regardless of which tool or IDE your team uses. Kiro is a workflow mandate — a structured requirements-to-implementation pipeline with tight AWS and VS Code integration built in.
SpecKit’s four-phase model separates task decomposition from implementation. Kiro’s three-phase model — Requirements, Design, Implementation — moves from design to agent execution without a dedicated task-list phase, removing one human review gate.
Kiro uses EARS notation to generate structured acceptance criteria covering edge cases.
💡 EARS (Easy Approach to Requirements Syntax) is a structured notation for software requirements that uses defined sentence patterns to ensure edge cases and alternative scenarios are explicitly captured.
SpecKit uses the free-form constitution.md — more flexible, but it demands more discipline to write governance well. The IDE constraint matters: Kiro is VS Code-first with deep AWS and Amazon Bedrock integration, constrained to Anthropic Claude models. SpecKit works across IDEs and 30+ agents. If your team runs a multi-cloud or heterogeneous tooling environment, that portability is a genuine differentiator.
SpecKit’s constitution also persists across sessions and projects. Kiro’s requirements documents are per-project artefacts. Teams inside the AWS ecosystem with VS Code standardisation have a strong case for Kiro; teams with mixed tooling or portability requirements have a strong case for SpecKit. The dedicated Kiro analysis covers the AWS side in depth.
How does SpecKit integrate with GitHub Copilot and Azure DevOps?
For teams already on the Microsoft developer stack, SpecKit forms the governance backbone of a coherent three-component setup: GitHub Copilot handles AI agent execution, Azure DevOps handles the enterprise pipeline, and SpecKit provides the spec and governance layer.
The constitution.md functions as a persistent constraints context for Copilot — an always-on governance document, not a one-time prompt. Copilot holds approximately 40% market share with over 20 million all-time users, so most Microsoft-stack teams already have it in the workflow.
Azure DevOps integration is confirmed as an official supported workflow in Microsoft Learn Unit 11: integrating SpecKit artefacts — specs, task lists, constitution — into Azure DevOps pipelines for enterprise SDLC governance. For configuration steps, the Microsoft Learn module is the authoritative reference.
Microsoft also provides the Agentic-Agile Template (microsoft/agentic-agile-template) as a companion project scaffold with persistent agent guidance files. For larger enterprises, SpecKit supports multiple AI agents running on different tasks, all governed by the same constitution.
How does SpecKit compare to OpenSpec on brownfield vs. greenfield teams?
SpecKit and OpenSpec have a clean philosophical divide. SpecKit is about governance permanence — establish the constitution before any code is written, and every agent honours it. OpenSpec (from Fission AI) is about continuity — keeping specs synchronised with existing, evolving code.
SpecKit performs best on greenfield codebases. Independent testing confirms it struggles with legacy frameworks and complex existing codebases: retrofitting a constitution means mapping existing patterns against governance principles, and those patterns often conflict. This is the most commonly cited enterprise limitation.
OpenSpec’s living-spec model is designed for exactly that context — its propose, apply, archive flow tracks changes relative to existing functionality rather than generating full specs upfront.
SpecKit upgrades can also overwrite customisation files — documented in v0.1.6 upgrade warnings. Enterprise teams need an abstraction strategy between SpecKit upgrades and their org-specific customisations.
The practical guidance: starting something new, SpecKit is a strong choice. Managing a large existing codebase, start with OpenSpec and consider SpecKit for new components in a hybrid approach. The full framework landscape including BMAD-METHOD gives you the broader comparison.
What does SpecKit’s adoption signal tell us about the SDD market?
The 93,000+ GitHub stars tells us a large number of developers are watching or bookmarking the tool — not that they are running it in production at enterprise scale. Star counts accumulate through press coverage, social sharing, and developer curiosity. The VS Magazine headline — “GitHub Spec Kit Takes Off as Antidote to Piecemeal ‘Vibe Coding'” — gives you a sense of why the figure spiked: it reflects frustration with vibe coding as much as active SpecKit adoption.
No community-originated SDD framework — BMAD-METHOD, OpenSpec — has reached comparable star counts. SpecKit’s Microsoft and GitHub backing gives it discoverability and institutional credibility that community tools simply don’t have. What the figure doesn’t tell us: whether enterprise teams are running SpecKit at scale, or whether brownfield retrofit success rates are high. Named enterprise case studies aren’t yet publicly available.
SpecKit is a well-resourced entry in the SDD market with genuine enterprise traction potential. Microsoft’s backing gives it structural advantages over grassroots alternatives. Do your due diligence on brownfield fit and security governance before committing. Broader context is at spec-driven development.
Frequently Asked Questions
What does “constitution.md” mean in GitHub SpecKit?
The constitution.md is the project-wide constraints file that establishes defined engineering principles all AI agents must follow. Think of it as an Architectural Decision Record — it records the persistent intent of your engineering team and makes that intent binding across all agents and workflow phases. It’s not a README or style guide; it’s a governance document the agent workflow enforces.
Is GitHub SpecKit only for greenfield projects?
SpecKit performs best on greenfield codebases where the constitution can be established before any code is written. Independent testing confirms it struggles with legacy frameworks and complex existing codebases. A hybrid approach works for many teams: use SpecKit for new components or services within a broader brownfield codebase.
What agents are compatible with GitHub SpecKit?
SpecKit supports 30+ AI coding agents including GitHub Copilot, Claude Code, Gemini CLI, Amazon Q, Cursor, and Windsurf. Amazon Q — a direct AWS competitor — is on the compatible list, which is the strongest demonstration of SpecKit’s portability argument.
How does GitHub SpecKit differ from BMAD-METHOD?
SpecKit is vendor-backed (Microsoft/GitHub), MIT-licensed, CLI-driven, and officially supported with a 13-unit Microsoft Learn curriculum. BMAD-METHOD is community-originated with no vendor backing or official enterprise support. Teams inside the Microsoft ecosystem with enterprise support requirements will find SpecKit’s institutional backing worth considering; teams that prefer community-driven tools may prefer BMAD.
Can I use GitHub SpecKit without GitHub Copilot?
Yes. SpecKit is agent-agnostic by design. GitHub Copilot is the primary showcase agent for Microsoft-stack teams but is not required. Teams already using Claude Code or Gemini CLI can adopt SpecKit without changing their AI tooling.
What is Microsoft’s Agentic-Agile philosophy and how does SpecKit fit into it?
Agentic-Agile is Microsoft’s framework for applying Agile engineering discipline to human-agent development teams. SpecKit is the tooling implementation — the spec and constraints layer. The companion Agentic-Agile Template (microsoft/agentic-agile-template) provides the project scaffold alongside SpecKit’s governance layer.
Does GitHub SpecKit support security and compliance governance?
Not natively. GitHub Issue #2362 documents community demand for a security governance preset covering threat modelling, supply-chain transparency, and ASVS (OWASP Application Security Verification Standard) verification. Teams can embed security requirements manually in the constitution.md, but there’s no official preset yet.
How does GitHub SpecKit handle upgrades without overwriting customisations?
This is a known limitation. SpecKit upgrades can overwrite customisation files — documented in v0.1.6 upgrade warnings. Teams with opinionated or extended SpecKit configurations need an abstraction layer between their org-specific customisations and the upgrade process. Factor this into your adoption plan.
What is the difference between GitHub SpecKit and OpenSpec?
SpecKit is governance permanence — a constitution established before coding that all agents must honour; strongest on greenfield projects. OpenSpec (Fission AI) is a continuity layer — living specs synchronised with evolving code; designed for brownfield codebases. The choice depends on codebase context. See the full framework landscape for the broader comparison.
Is GitHub SpecKit free to use?
Yes. SpecKit is MIT-licensed and free for commercial use with no paid enterprise tier. The specify-cli is open source. The Microsoft Learn training curriculum is free. Pricing only applies to the AI agent you use alongside it — GitHub Copilot has its own subscription.
Where can I find the official GitHub SpecKit documentation?
The Microsoft Learn module is the most structured starting point: 13 units covering constitution creation, the four-phase workflow, Azure DevOps integration, CI/CD, and multi-agent collaboration.
How does the SpecKit Tasks phase differ from Kiro’s approach?
SpecKit’s four-phase model adds an explicit Tasks phase between Plan and Implement — decomposing the technical design into discrete, executable agent tasks before any agent begins coding. This creates a human review checkpoint that Kiro’s three-phase model omits. For teams that need human approval gates before agent execution, that extra phase is a governance advantage.
