Evergreen Tools
|
← Back to AI Tools

AI Spec-Driven Development

Write down what and why before letting the agent build: GitHub's open-source Spec Kit turns requirements into a specification, a technical plan and actionable tasks, so agent-written code can be reviewed and traced rather than vibe-generated from a single prompt

Tool Interface

Interactive tool will be available soon

Features

  • ✓ Three independent entry points: spec-driven development to build, bug fixing to repair, idea assessment to decide whether something deserves investment — no mandatory three-phase march
  • ✓ Templates fix the shape first: what a spec looks like, what a technical plan contains, how work breaks into tasks — so teams stop reinventing document structure every time
  • ✓ Executable, not decorative: the spec is broken into tasks an agent can pick up one by one and carried through implementation and convergence, rather than parked in a README
  • ✓ Not tied to one agent: GitHub Copilot, Claude, Cursor and other mainstream coding agents are supported, so switching tools does not mean rewriting your process
  • ✓ Driven through agent skills: the flow runs as /speckit skills inside your agent chat, one step at a time with human review before continuing

How to Use

  1. Set up the environment: Python 3.11+ and uv, then install the CLI with uv tool install specify-cli
  2. Init the project with specify init and name your coding agent integration; there is a separate guide for existing codebases
  3. Walk the process inside your agent chat: write the spec (what and why), then the technical plan, then break it into tasks and implement, reviewing each step before moving on
  4. Keep specs in version control and evolve them with change: the spec is the single source of truth — change it before changing code and review against it for drift

FAQ

What is spec-driven development?

A workflow that bakes think-before-you-build into engineering: write down the problem, the why and the acceptance criteria as a specification first, then let the coding agent produce a technical plan and tasks and implement against it. GitHub's open-source Spec Kit packages this as templates, scripts and agent skills, officially described as giving AI coding agents structured processes, reusable templates and documented outcomes. See https://github.com/github/spec-kit

How is it different from vibe coding?

Reviewability and traceability. Vibe coding hands a prompt to a model and struggles to explain what changed and why; spec-driven development freezes requirements into a document first, so agent output can be checked line by line and drift becomes visible in review. Microsoft's own write-up frames Spec Kit as moving from vibe coding toward spec-driven delivery — see https://developer.microsoft.com/blog/spec-driven-development-spec-kit

Must all three processes run in order?

No — they are independent entry points, not three mandatory phases. Building a feature or app uses spec-driven development; diagnosing and repairing broken behaviour uses bug fixing; deciding whether an idea deserves investment uses idea assessment. Per the official README, spec-driven development ships in core while the other two are bundled extensions you install when needed. See https://github.com/github/spec-kit

What prerequisites and agents are required?

Officially you need Python 3.11+, uv and a supported coding agent, on Linux, macOS or Windows. Install with uv tool install specify-cli and initialise with specify init. It does not supply the model, only the process and templates, so Copilot, Claude and Cursor can all be wired in. See https://github.com/github/spec-kit and https://github.github.io/spec-kit/reference/integrations.html

Can it be used on an existing codebase?

Yes. There is a dedicated guide for existing projects; the usual pattern is to reverse-engineer the current state into specs and an architecture note, then let the agent change code under those constraints so it does not rewrite your system from its own imagination. See https://github.github.io/spec-kit/guides/existing-projects.html and the main repo https://github.com/github/spec-kit

Won't the spec become documentation nobody reads?

It depends on whether the spec is actually used for acceptance. If it is broken into tasks the agent executes one by one and reviews check drift against it, it stays alive; written but never enforced, it becomes decoration. There is community debate too — fragmented incremental specs that are not the single source of truth are just vibe coding in a new coat, discussed at https://github.com/github/spec-kit/discussions/152