Spec Kit introduces Spec-Driven Development (SDD), a methodology that redefines software development by making specifications "executable," directly generating working implementations rather than merely guiding them. SDD emphasizes intent-driven development where specifications define the "what" before the "how," promoting rich specification creation, multi-step refinement, and heavy reliance on advanced AI model capabilities for interpretation.

The core methodology of Spec-Driven Development, as facilitated by the Spec Kit toolkit, involves a structured, iterative process guided by an AI assistant:

1. Specify CLI Initialization (specify init): The process begins by setting up a new project using the specify command-line interface (CLI). This command initializes a project from a template, allowing users to select a preferred AI assistant (e.g., Claude, Gemini, Copilot) and configure initial project settings. It can create a new project directory ($specify init <PROJECT_NAME>$) or initialize within an existing one (specify init . or specify init --here). The CLI ensures the environment is set up for SDD by creating essential directories like .specify and checking for required tools.

2. Establish Project Principles (/speckit.constitution): Within the initialized project, the AI assistant is launched. The first step is to define the project's governing principles and development guidelines using the /speckit.constitution command. This command generates or updates the .specify/memory/constitution.md file, which serves as a foundational reference for the AI agent, guiding its decisions throughout the specification, planning, and implementation phases (e.g., principles for code quality, testing standards, UX consistency, performance).

3. Create the Specification (/speckit.specify): With the constitution in place, the core functional requirements are defined using the /speckit.specify command. Users describe "what" they want to build and "why," explicitly avoiding technical implementation details at this stage. For example, a prompt might describe an application's features, user interactions, and high-level data flow. This command results in the creation of a new feature branch (e.g., 001-feature-name) and a detailed specification document (spec.md) within a feature-specific directory (e.g., specs/001-feature-name/spec.md), containing user stories and functional requirements based on predefined templates.

4. Functional Specification Clarification (/speckit.clarify): Before technical planning, the specification undergoes a structured clarification phase using /speckit.clarify. This command facilitates sequential, coverage-based questioning by the AI to identify and resolve underspecified areas, recording clarifications in a dedicated section. The AI can also validate the specification against a "Review & Acceptance Checklist" to ensure completeness, clarity, and consistency, reducing downstream rework.

5. Generate a Technical Plan (/speckit.plan): Once the functional specification is clarified, the /speckit.plan command is used to introduce the chosen tech stack and architectural decisions. Users provide prompts detailing technologies (e.g., ".NET Aspire, Postgres, Blazor server, REST API"). The AI then generates a comprehensive technical implementation plan, populating various files within the feature directory, such as plan.md (high-level plan), data-model.md (data schema), api-spec.json (API contracts), research.md (research findings), and quickstart.md. This step may involve AI-driven research to validate tech stack choices and address rapidly changing library details.

6. Validate the Plan (AI Audit): The generated technical plan is audited by the AI to ensure completeness, identify potential blind spots, and check for over-engineered components. Users prompt the AI to review the plan.md and associated detail files, cross-referencing information and ensuring adherence to the project's constitution. This iterative refinement helps catch issues before implementation.

7. Generate Task Breakdown (/speckit.tasks): With a validated plan, the /speckit.tasks command automatically breaks down the implementation plan into specific, actionable tasks. This generates tasks.md within the feature specification directory. This file details tasks organized by user story, manages dependencies by ordering tasks correctly, marks parallelizable tasks with [P], specifies exact file paths for modifications, and integrates a Test-Driven Development (TDD) structure by including test tasks before implementation tasks. Checkpoint validations are also included for independent functionality.

8. Execute Implementation (/speckit.implement): The final step is execution using the /speckit.implement command. The AI validates prerequisites (constitution, spec, plan, tasks) and then systematically executes the tasks defined in tasks.md in the correct order, respecting dependencies and parallel markers. The AI provides progress updates and handles errors, often involving the execution of local CLI commands (e.g., dotnet, npm). Post-execution, any runtime errors (e.g., browser console errors) can be fed back to the AI for resolution.

Spec Kit supports a wide range of AI agents, including Qoder CLI, Amp, Auggie CLI, Claude Code, CodeBuddy CLI, Codex CLI, Cursor, Gemini CLI, GitHub Copilot, IBM Bob, Jules, Kilo Code, opencode, Qwen Code, Roo Code, SHAI (OVHcloud), and Windsurf, enabling diverse development environments and preferences. The experimental goals include validating technology independence, addressing enterprise constraints, supporting user-centric development, and enabling creative/iterative processes like parallel implementations and brownfield modernization.