SDD Observatory

Compare frameworks

Put any of the 19 tracked frameworks side by side — how each one works, which agents it drives, how active it is, and where it falls short. The selection lives in the URL, so a comparison is shareable.

Frameworks to compare

Side by side

Framework GitHub Spec Kit established Grill-Me Skills emerging OpenSpec established
Summary Open-source toolkit from GitHub that scaffolds a phase-gated, spec-first workflow into any of 40+ AI coding agents. Matt Pocock's composable family of agent skills built around "grilling" — a relentless one-question-at-a-time interview that aligns human and agent before code is written — chaining into spec, tickets, and TDD implementation. Change-folder-based SDD for AI coding assistants — fluid, iterative, and explicitly built for brownfield codebases, not just greenfield.
GitHub stars ★ 131.8K ★ 238.3K ★ 66.4K
Contributors 277 7 103
Last push 4 hours ago3 days ago9 hours ago
Repo age 1 years7 months1.1 years
Latest release v1.0.1v1.2.3v1.11.0
Tracked projects None yet
Core approach Treats specifications as executable artifacts that directly generate working implementations rather than just guiding them. The specify CLI scaffolds a phase-gated slash-command workflow — grounded in a project "constitution" of governing principles — into whichever AI coding agent you use. Deliberately anti-pipeline: the README names Spec Kit and BMAD as approaches that "own the process" at the cost of user control, and offers small, hackable, composable skills instead. The core primitive is grilling — walk the plan's decision tree one question at a time, each question paired with a recommended answer, reading the codebase for anything it can settle itself. Two front doors wrap it: grill-me (stateless, leaves no artifacts) and grill-with-docs (writes a CONTEXT.md ubiquitous-language glossary and sparing ADRs as terms and decisions resolve), feeding a spec → tickets → implement chain the user drives step by step. Each unit of work is a change folder under openspec/changes/ containing a proposal, requirement deltas (ADDED/MODIFIED blocks with WHEN/THEN scenarios), a design doc, and a task list. On completion the change is archived and its deltas merge into living specs under openspec/specs/. The workflow was recently rebuilt around the artifact-guided "OPSX" commands.
Workflow
  1. /speckit.constitution — create project governing principles
  2. /speckit.specify — define what to build (requirements, user stories)
  3. /speckit.clarify — optionally resolve underspecified areas before planning
  4. /speckit.plan — technical implementation plan with the chosen tech stack
  5. /speckit.tasks — generate an actionable task list (optionally converted to GitHub issues)
  6. /speckit.analyze — optional cross-artifact consistency check
  7. /speckit.implement — execute all tasks
  8. /speckit.converge — assess the codebase against spec, plan, and tasks; append remaining work
  1. /setup-matt-pocock-skills — one-time per-repo config: issue tracker (GitHub, Linear, or local files), triage labels, doc locations
  2. /grill-me or /grill-with-docs — one-question-at-a-time interview down the plan's decision tree; the docs variant captures terms into CONTEXT.md and hard-to-reverse decisions into ADRs inline
  3. /to-spec — synthesize the settled conversation into a spec (problem, user stories, seams, out-of-scope) and publish it to the tracker, without re-interviewing
  4. /to-tickets — split the spec into tracer-bullet vertical-slice tickets, each declaring its blocking edges
  5. /implement — build the tickets via red-green-refactor TDD at the pre-agreed seams, then run /code-review (standards + spec axes) and commit
  6. /wayfinder — optional upstream step for efforts too big for one session: chart a map of investigation tickets first
  1. /opsx:explore — optional no-stakes thinking partner to shape the idea
  2. /opsx:propose — create openspec/changes/<id>/ with proposal, spec deltas, design, and tasks
  3. /opsx:apply — implement the task checklist
  4. /opsx:sync — reconcile artifacts with reality
  5. /opsx:archive — archive the change and update the living specs
  6. Expanded profile adds /opsx:new, /opsx:continue, /opsx:ff, /opsx:verify, /opsx:bulk-archive, /opsx:onboard
Supported tools 12 tools — see matrix 3 tools — see matrix 12 tools — see matrix
Strengths
  • Backed by GitHub, with a fast release cadence and very high activity
  • Widest agent integration surface of any SDD kit — 40+ agents and IDEs plus a generic fallback for unlisted ones
  • Extensible via extensions, presets, bundles, and project-local template overrides
  • Optional quality gates (/speckit.clarify, /speckit.analyze, /speckit.checklist) act as unit tests for English
  • Small, composable, editable skills instead of a phase-gated pipeline — the user keeps control of the process and can debug it
  • One question at a time with a recommended answer each; questions the codebase can settle are answered by reading, not asking
  • grill-with-docs leaves durable in-repo artifacts — a CONTEXT.md glossary and sparing ADRs — building a DDD-style ubiquitous language that cuts agent verbosity
  • Tracer-bullet vertical-slice tickets with explicit blocking edges, so several agents can work the frontier in parallel
  • Explosive adoption (176k+ stars within six months) and two install philosophies: hackable copies via skills.sh, or a managed Claude Code plugin
  • Heavily dogfooded — the repo itself carries 36 live capability specs and over a dozen in-flight changes
  • Explicitly brownfield-friendly; artifacts are plain Markdown with no special syntax
  • Very broad tool support — 34 documented integrations via skills and slash commands
  • Stores (beta) share planning repos across teams and repositories for cross-repo features
Limitations
  • GitHub still frames the methodology as experimental, and the multi-phase ceremony can be heavy for small changes
  • Requires a Python/uv toolchain for the Specify CLI on top of the coding agent itself
  • Dogfooding is partial — the repo's own .specify/ holds only a constitution, with no in-tree feature specs
  • The template/override stack (core vs extension vs preset vs local) adds configuration complexity
  • Deliberately not turnkey — you orchestrate the chain yourself, and the interview-driven flow demands sustained human attention per change
  • The engineering chain needs per-repo setup (tracker, triage labels, doc locations) before to-spec and to-tickets work
  • Specs and tickets publish to the issue tracker rather than versioning in-repo — only the glossary and ADRs live in the tree, so spec-to-code drift is hard to observe
  • Young and fast-moving under a single maintainer, with skills still being deprecated and reshaped (deprecated/ and in-progress/ directories in-tree)
  • Fast-moving: the workflow was just rebuilt (legacy to OPSX), so guidance churn is real
  • The Stores multi-repo feature is still in beta
  • Requires Node.js 20.19+ and a global npm install
  • The spec-delta format (ADDED/MODIFIED requirement blocks) has its own conventions to learn
Assessment Reviewed last month Reviewed last month Reviewed last month
Links

Tool support

Which AI coding agents and editors each framework drives. Rows appear only when at least one selected framework supports the tool.

Tool GitHub Spec Kit Grill-Me Skills OpenSpec
Amazon Q Developer
Amp
Any skills-compatible agent
Claude Code
Cline
Codex
Cursor
Gemini CLI
GitHub Copilot
Goose
Kiro
OpenCode
Qwen Code
RooCode
Windsurf
Zed

Repository figures are collected automatically from the GitHub API; everything else is a human assessment. · How we track · All frameworks