The Constitution

The constitution.md file defines policies, requirements, and technical standards that must be followed throughout the development process.

Spec-Driven Development Methodology

Each phase of the Spec-Driven Development (SDD) workflow plays a crucial role in transforming ideas into working software. Developers who understand the purpose, content, and output of each phase can apply SDD effectively to their own projects.

Note

A greenfield application is used to illustrate how each phase of the SDD process builds on the previous phase. The same greenfield scenario is used later in the module when you learn about the GitHub Spec Kit commands that facilitate each phase.

From vision to execution

Imagine you’re building a new application: an RSS Feed Reader that lets users subscribe to feeds, see new articles, and track what they’ve read. How do you go from this idea to working code using SDD? The answer is a systematic progression through four phases, each producing artifacts that feed into the next.

Phase 1: Specify

The specification defines exactly what the software should do. Every implementation decision traces back to it. If functionality doesn’t appear in the spec, it doesn’t appear in the final product unless you update the spec.

What a good spec contains

A well-structured specification includes several key sections:

  • Summary: A concise description of the feature from an end-user perspective. This section answers “What does this feature do?” in one or two sentences. For example: “This application enables users to subscribe to RSS and Atom feeds, view articles sorted newest-first, and track read/unread status. Feed data persists locally on the device.”
  • User stories: Brief narrative descriptions of how users interact with the feature. User stories capture intent and value rather than technica implementation. For example:
    • As a user, I want to add RSS feeds by URL so that I can follow my favorite websites.
    • As a user, I want to see unread articles sorted newest-first so that I can catch up on recent content.
  • Acceptance criteria: Specific, testable conditions that must be true for the feature to be considered complete. Write acceptance criteria as observable facts. For example:
    • User can add a feed by entering a valid RSS or Atom URL.
    • Invalid feed URLs display a clear error message.
    • New articles appear after refreshing feeds.
    • Articles display with read/unread status that persists between sessions.
  • Functional requirements: Detailed descriptions of system behavior - how the feature works. Functional requirements elaborate on user stories with specifics about interfaces, processes, and data handling.

Nonfunctional requirements: Quality attributes like performance, security, and scalability. Nonfunctional requirements ensure AI-generated code meets enterprise quality standards, not just functional correctness.

Edge cases: Unusual scenarios, error conditions, and boundary behaviors. Explicitly documenting edge cases prevents AI from making assumptions that might not match your intent.

The mindset shift

Writing the spec is as important as writing code. The spec isn’t a formality to satisfy project management - it’s the artifact that drives AI-assisted code generation. Invest the same care in crafting specs as you would in implementing features manually.

Phase 2: Plan

A specification defines what you need to build. A technical plan defines how you build it. The plan transforms requirements into architecture decisions, ensuring your implementation aligns with both the specification and your project’s governing principles.

What a good plan contains

A plan should include the following elements:

Architecture overview: A high-level view of how components interact. For the RSS Feed Reader:

“Build a .NET application with a local SQLite database for storing feeds and articles. A FeedService handles RSS/Atom parsing and validation. The UI displays a feed list and article view with read/unread tracking. When a user adds a feed, the app validates the URL, fetches the feed content, parses articles, and stores them locally.”

Technology stack and key decisions: Explicit documentation of technology choices and rationales. Each decision should align with both specification requirements and organizational principles.

Example decisions:

Runtime: .NET 8 console application.

Data storage: SQLite with Entity Framework Core for local persistence.

Feed parsing: System.ServiceModel.Syndication for RSS/Atom support.

Security: HTML sanitization before rendering article content.

Implementation sequence: The logical order of implementation steps. A typical sequence ensures foundational elements (database schema) exist before dependent components (API that writes to the database).

Constitution verification: A check that proposed solutions align with project principles. If your project constitution includes “HTML content must be sanitized before rendering,” the plan verification confirms you’re using an HTML sanitization library.

Assumptions and open questions: Documentation of assumptions and unresolved questions. This transparency helps identify potential issues before implementation begins.

The separation of specification and plan

If you later switch technologies - say, moving from SQLite to a different database - you update the plan while the specification remains largely unchanged. The feature requirements don’t change; only the implementation approach changes.

Phase 3: Tasks

Technical plans provide architectural direction, but implementation requires concrete, actionable steps. The tasks phase converts high-level decisions into specific work items.

What good tasks look like

Each task should be:

Actionable: The task clearly states what needs to be done.

Testable: You can verify when the task is complete.

Independent where possible: The task can often be completed without waiting for unrelated work.

Time-bounded: A developer can complete the task in a reasonable timeframe.

Here’s an example of a well-scoped task: “Implement an AddFeed method that accepts an RSS/Atom URL. The method validates the feed format, parses the feed content, stores feed metadata and articles in SQLite, and returns the feed ID.”

This task is specific about what to build, what it accepts, what validations to apply, where to store data, and what to return.

Phase-based organization

Complex features benefit from organizing tasks into phases:

Phase 1 – Foundation: Set up project structure, create database schema, and add required packages.

Phase 2 – Core functionality: Implement feed parsing, add URL validation, and implement article storage.

Phase 3 – User interface: Create feed list view, add article display, and implement read/unread tracking.

Phase 4 – Security: Add HTML sanitization, implement HTTPS-only feed fetching, and add error handling.

Phase 5 – Testing: Write unit tests, create integration tests, and document the application.

Task dependencies

The task order matters. Database schema changes typically come first because back-end code depends on schema existence. Back-end API endpoints come before front-end components that call those endpoints. Testing comes after the code being tested exists.

Verification checkpoint

Before moving to implementation, review tasks against the plan and spec. For example:

If a requirement isn’t covered by a task, add a corresponding task.

If a task isn’t associated with the plan or spec, evaluate whether the task is needed.

Phase 4: Implement

If phases 1-3 are done well, implementation should be straightforward. You can execute tasks one by one with clear guidance.

The implementation process

Implementation follows a simple loop:

Select the next task from the tasks list.

Write code to implement the task (manually or using AI assistance).

Test that the task meets spec and plan expectations.

Mark the task complete and move to the next task.

Implementation continues until all tasks are done, meaning the spec’s requirements are all implemented. Integrate and test frequently - possibly after each task or small group of tasks - to ensure the system works as a whole.

Handling discoveries during implementation

During implementation, you might discover something that was missed or needs to be updated. Rather than making ad-hoc code changes, SDD encourages you to go back and update the spec or plan accordingly, then adjust remaining tasks. This process keeps artifacts in sync with reality, maintaining them as living documents.

Iterative nature and checkpoints

While listed sequentially, SDD allows iteration. Here are some examples:

After writing a spec, you might get feedback that changes requirements. When requirements change, you should update the spec before creating the plan.

Halfway through implementation, some edge cases might surface that aren’t in the spec. When changes that affect implementation are discovered, you should update your spec, plan, and tasks documents before you continue your implementation.

Iteration is a key advantage. The cost of change is lower because knowledge is captured in the spec and plan. When changes occur, they propagate systematically.

Checkpoints between phases ensure quality and alignment. Before moving from spec to plan, verify the spec is complete and clear. Before moving from plan to tasks, ensure the plan is feasible and detailed enough. Before implementation, confirm tasks cover all requirements. It’s better to spend more time upfront than to fix issues later.

The outcome of SDD workflow

The end state is a fully implemented app or feature where the code aligns with a spec, and you have documentation (spec and plan) that exactly matches the implementation. The alignment between code and documentation provides the following benefits:

Maintenance: Understanding what the system does and why.

Onboarding: New team members can read the spec and plan to understand the system.

Trust: The documentation accurately reflects reality - unlike many projects where docs drift from code.

Writing all these artifacts by hand might sound laborious, but AI tools like GitHub Spec Kit can automate the heavy lifting of creating spec, plan, and tasks.

Summary

The four phases of spec-driven development - Specify, Plan, Tasks, and Implement - provide a structured workflow that transforms ideas into working software. Each phase produces artifacts that guide the next step, ensuring alignment between requirements and implementation. The living nature of these artifacts allows for continuous adaptation, while the systematic checkpoints maintain quality and coherence throughout the process.

GitHub Spec Kit

= https://github.com/github/spec-kit |_=> https://github.github.com/spec-kit/

History

  • https://medium.com/@reza.ra/spec-driven-development-from-history-to-modern-ai-workflows-d6d84f99e593
  • https://arxiv.org/html/2602.00180v1

6 of 11

GitHub Spec Kit is an open-source toolkit developed by GitHub to facilitate spec-driven development. It’s designed to integrate with AI coding assistants like GitHub Copilot and orchestrate the SDD workflow through structured commands, templates, and persistent artifacts.

Think of GitHub Spec Kit as a copilot for your copilot - it guides the AI through a structured process, ensuring consistent, high-quality output at each phase of development.

GitHub Spec Kit addresses a fundamental challenge in AI-assisted development: maintaining context and consistency across multiple interactions with coding assistants. Without structure, each chat session with an AI operates in isolation, lacking awareness of previous decisions or overall project requirements. GitHub Spec Kit solves this challenge by:

Creating persistent artifacts: Specifications, plans, and tasks are stored as Markdown files in your repository, creating a permanent record of requirements and decisions.

Standardizing the workflow: A defined process guides you from high-level requirements through specification, planning, task breakdown, and implementation.

Providing reusable commands: Built-in slash commands encapsulate best-practice prompting patterns, so you don’t need to craft optimal prompts for each development phase.

Key point: GitHub Spec Kit isn’t an AI model itself - it’s a framework and CLI that works with your chosen AI agent. It helps transform a high-level idea into working code by generating the spec, plan, and tasks with AI, rather than requiring you to write everything manually.

Core principles of GitHub Spec Kit GitHub Spec Kit’s design directly implements SDD principles:

Executable specifications: GitHub Spec Kit makes the spec “executable” by using it to drive code generation through commands. Your specification isn’t just documentation - it’s the input that produces implementation.

Structured workflow enforcement: GitHub Spec Kit guides you through phases in order. You can’t effectively implement without first having a spec and plan, because the tool’s workflow is designed to build each phase on the previous one.

Intent-first approach: You always start by explicitly stating intent (in the spec) in the tool’s flow. The creators’ goal was to let developers focus on product requirements and outcomes, while the AI handles the boilerplate code.

Supported project types GitHub Spec Kit works with different types of projects, adapting its approach to your situation:

Greenfield projects Greenfield projects start with a project folder, but no existing code. You initialize GitHub Spec Kit in the project folder, and it helps you create your application. You describe your feature idea, and GitHub Spec Kit guides you through generating a complete spec, plan, and task list. The lab exercise in this module demonstrates this scenario.

Brownfield projects Brownfield projects start with an existing codebase. You initialize GitHub Spec Kit in the existing repository, and it helps you add new features while respecting the existing architecture and design decisions. GitHub Spec Kit can help summarize your codebase’s structure and rules into a project constitution - a document that contains standards and guidelines for the project. You create specifications for new features, and GitHub Spec Kit generates plans and tasks that integrate the features with the current code. This process ensures that AI-generated code remains consistent with your existing application.

Exploratory projects When you’re exploring multiple potential approaches, GitHub Spec Kit can generate multiple plans from the same specification. You can explore different optimization targets - performance, maintainability, or cost - by generating alternative plans and comparing them before choosing an approach.

Refactoring and modernization GitHub Spec Kit can guide refactoring efforts by treating the desired end state as a specification. You document what the refactored code should achieve (same functionality with improved structure), create a plan for the refactoring approach, and generate tasks for incremental changes.

How GitHub Spec Kit aligns to SDD phases GitHub Spec Kit provides a command or step for each SDD phase:

SDD Phase GitHub Spec Kit Command Output File Constitution (setup) /speckit.constitution constitution.md Specify /speckit.specify spec.md Plan /speckit.plan plan.md Tasks /speckit.tasks tasks.md Implement /speckit.implement Source code This one-to-one mapping shows that SDD isn’t just theory - GitHub Spec Kit operationalizes it into concrete commands and artifacts.

Components included in GitHub Spec Kit When you set up GitHub Spec Kit, you get several integrated components:

Specify CLI tool The specify command-line tool initializes and manages spec-driven projects. When you run specify init in your project directory, it:

Prompts you to select your AI coding assistant Creates a .github/prompts/ directory with workflow templates Generates a project structure with folders for specifications Creates template files: constitution.md, spec.md, plan.md, tasks.md Configures integration with your chosen AI assistant Markdown artifact files GitHub Spec Kit uses structured Markdown files as primary development artifacts. These files aren’t passive documentation - they actively drive AI code generation:

constitution.md: Project-wide principles, constraints, and non-negotiable requirements spec.md: Feature requirements, user stories, and acceptance criteria plan.md: Technical architecture and implementation strategy tasks.md: Discrete, actionable work items Slash commands GitHub Spec Kit integrates with Visual Studio Code through custom chat commands that trigger specific workflow phases. These commands appear in the GitHub Copilot Chat panel after initialization.

Templates GitHub Spec Kit includes template files for spec, plan, tasks, and other artifacts, ensuring a standard structure. When you start a new project, templates provide sections to fill in, guiding you on what information to include.

Multi-agent support GitHub Spec Kit supports multiple AI coding assistants beyond GitHub Copilot. When you run specify init, you select from supported agents:

GitHub Copilot (integration through Visual Studio Code) Claude Code Cursor Windsurf Amazon Q Developer And others The underlying specification artifacts (spec.md, plan.md, tasks.md) remain identical regardless of which AI assistant you use. This agent-agnostic approach prevents vendor lock-in and allows teams to experiment with different AI tools while maintaining consistent SDD practices.

Why use GitHub Spec Kit? GitHub Spec Kit offers several advantages for developers adopting spec-driven development with AI assistance:

Efficiency: It drafts specs and plans quickly with AI. What might take hours to write from scratch, GitHub Spec Kit can generate in minutes (though you refine it).

Consistency: It enforces a consistent format via templates and a consistent approach every time - valuable for teamwork and repeatable processes.

Multi-agent flexibility: Use the AI environment you prefer (Visual Studio Code with GitHub Copilot, Claude, or others) without changing your workflow.

Enterprise ready: The constitution concept means GitHub Spec Kit is ready to encode company-wide best practices and ensure AI follows them in every plan.

Open source and extensible: Organizations can customize templates, contribute improvements, or integrate GitHub Spec Kit with their systems.

GitHub Spec Kit empowers you to accomplish in minutes what might otherwise take days - it’s like having an AI project manager guiding your code generation while you focus on what matters: the product requirements and outcomes.

Summary GitHub Spec Kit is an open-source toolkit that operationalizes spec-driven development by providing a structured workflow, persistent artifacts, and AI integration. It guides you through the SDD phases of Specify, Plan, Tasks, and Implement using commands and templates, enabling efficient, consistent, and high-quality software development. With multi-agent support and enterprise readiness, GitHub Spec Kit empowers teams to apply AI effectively while maintaining control over project requirements and design principles.

7 of 11

Before you can use GitHub Spec Kit to practice spec-driven development, you need to set up your environment. This unit covers the prerequisites, installation process, and configuration steps to get GitHub Spec Kit running in your development environment.

Prerequisites and system requirements Before installing GitHub Spec Kit, ensure your development environment meets the requirements for operating system, software dependencies, and AI coding assistant support.

Operating system Your development environment must use one of the following operating systems:

Linux or macOS: Fully supported. Windows: Fully supported with PowerShell scripts. Required software Your development environment must include the following software:

Python 3.11 or later: GitHub Spec Kit’s CLI is a Python tool. Git: Required for version control integration and pulling the toolkit. uv tool: GitHub Spec Kit uses the uv tool for package management. The uv tool is a modern package manager that can install tools directly from GitHub. AI coding assistant Your development environment must have at least one supported AI coding assistant configured and working. GitHub Spec Kit supports:

Agent Environment Slash Command Support GitHub Copilot Visual Studio Code Yes Claude Code CLI / IDE Yes Cursor Cursor IDE Yes Windsurf Windsurf IDE Yes Amazon Q Developer CLI CLI / IDE check Gemini CLI CLI Yes And others Various Varies The lab exercise in this module uses Visual Studio Code with GitHub Copilot.

Install the uv tool You can install the uv tool using one of the following methods:

On macOS and Linux:

Bash curl -LsSf https://astral.sh/uv/install.sh | sh On Windows (in PowerShell):

PowerShell powershell -c “irm https://astral.sh/uv/install.ps1 | iex” After installation, restart your terminal to ensure uv is available in your PATH.

Install Specify CLI GitHub Spec Kit uses the specify CLI tool to manage specifications and interact with AI coding assistants. There are two main ways to install the specify CLI tool.

Method 1: Global installation (recommended) The recommended approach is to install specify-cli globally using uv. A global installation makes the specify command available in any project.

Bash uv tool install specify-cli –from git+https://github.com/github/spec-kit.git Global installation provides these benefits:

Available in any project directory. Easy to update using uv tool upgrade specify-cli. No need to rerun installation commands each time. Method 2: One-time usage If you prefer not to install globally, you can run GitHub Spec Kit directly using uvx:

Bash uvx –from git+https://github.com/github/spec-kit.git specify init One-time usage downloads and runs GitHub Spec Kit for that single invocation. It’s useful for:

Trying out GitHub Spec Kit before committing to installation Running on systems where you can’t install globally (like some CI servers) The drawback is that you need to prefix commands with the full uvx –from … each time, which is less convenient for regular use.

Verifying your installation After installing, verify that GitHub Spec Kit is working correctly:

Bash specify check This command checks for required tools and confirms that installation succeeded. It reports:

Whether or not Git is found and configured. Whether or not your AI coding assistant is detected. Any missing dependencies or configuration issues. If specify check reports issues, address them before proceeding.

Setting up Visual Studio Code with GitHub Copilot You can use the following steps to set up Visual Studio Code with GitHub Copilot (for use with GitHub Spec Kit):

Install Visual Studio Code.

Download and install Visual Studio Code from code.visualstudio.com if you haven’t already.

Install GitHub Copilot extension.

Open Visual Studio Code. Go to the Extensions view (Ctrl+Shift+X or Cmd+Shift+X). Search for “GitHub Copilot.” Install the GitHub Copilot extension. Sign in with your GitHub account that has an active GitHub Copilot subscription. Verify GitHub Copilot is working.

Open the GitHub Copilot Chat panel and verify chat functionality is working.

Open the integrated terminal.

You can run specify commands in Visual Studio Code’s integrated terminal:

Open a new Terminal. Navigate to your project directory. To verify everything is configured, run specify check. Installing for other environments If you’re not using Visual Studio Code, the process is similar:

Claude Code Install specify-cli globally as described previously Open Claude’s interface in your project folder Type slash commands (/speckit.specify, etc.) directly in the chat Cursor Install specify-cli globally. Open your project in Cursor. Ensure the AI agent is running. Use slash commands in Cursor’s AI chat interface. Other AI tools Most supported AI coding assistants follow the same pattern:

Install the specify-cli globally. Open your project in your preferred environment. Use the slash commands in that tool’s AI chat interface. Check the “Supported AI Agents” table in GitHub Spec Kit README file for any tool-specific considerations.

Troubleshooting common issues You might encounter some common issues during installation or setup. The following sections provide solutions for common problems.

uv command not found If uv isn’t recognized after installation:

Close and reopen your terminal. Ensure the installation directory is in your PATH. On Windows, you might need to restart your computer. Specify command not found If specify isn’t found after installation:

Close and reopen your terminal. Check that ~/.local/bin (or the uv tool bin directory) is in your PATH. Try running uv tool list to see if specify-cli appears. AI tool not detected If specify check reports your AI tool isn’t found:

Ensure the AI tool is installed and running. For Visual Studio Code with GitHub Copilot, ensure the extension is installed and you’re signed in. Check that you’re running the check from a terminal where the AI tool is accessible. Windows-specific issues If you’re on Windows and experiencing issues:

Ensure PowerShell is available (typically preinstalled). Run PowerShell commands in a PowerShell terminal (not Command Prompt). Install prerequisites (Python, uv, Git) for Windows. For issues beyond these common problems, consult the GitHub Spec Kit README and community resources on the GitHub repository.

Summary GitHub Spec Kit supports various development environments and AI coding assistants. Core requirements include Python 3.11+, Git, and the uv tool. You can install the specify CLI globally or use it one-time via uvx. Visual Studio Code with GitHub Copilot is a common setup, but other AI tools are supported as well. Verifying your installation with specify check helps ensure everything is configured correctly.

8 of 11

With GitHub Spec Kit installed, you’re ready to use its commands to practice spec-driven development. This unit walks through each command in the workflow, explaining what it does, what output it produces, and how to work with the results. Understanding this process prepares you for the hands-on lab exercise.

Command overview GitHub Spec Kit provides two types of commands:

Terminal commands: Run in your shell (like specify init, specify check) Slash commands: Run inside your AI assistant’s chat interface (like /speckit.specify, /speckit.plan) The workflow follows a specific sequence, with each command building on the outputs of the previous one:

Order Command Type Output 1 specify init Terminal Project structure 2 /speckit.constitution Slash constitution.md 3 /speckit.specify Slash spec.md 4 /speckit.plan Slash plan.md 5 /speckit.tasks Slash tasks.md 6 /speckit.implement Slash Source code Project initialization Initialize your project with the specify init terminal command. This command sets up the necessary directory structure, configuration files, and templates for GitHub Spec Kit to work.

The specify init command Start every GitHub Spec Kit project with the specify init command in your terminal:

Bash specify init my-project This command creates a new directory with a standard GitHub Spec Kit structure:

text my-project/ ├── .github/ │ ├── agents/ │ └── prompts/ ├── .specify/ │ ├── memory/ │ │ └── constitution.md │ ├── scripts/ │ └── templates/ ├── specs/ │ └── (feature directories will go here) For an existing project directory, use –here to initialize in place:

Bash specify init –here During initialization, you’re prompted to select your AI coding assistant. Choose the one you plan to use (for this module, that’s GitHub Copilot).

Creating the constitution The constitution defines your project’s guiding principles, constraints, and non-negotiable requirements. It ensures consistency across specifications, plans, and code.

The /speckit.constitution command Before diving into features, establish your project’s guiding principles. In your AI assistant’s chat, type:

text /speckit.constitution The AI generates a constitution.md file that captures project-wide principles, constraints, and requirements. For a greenfield project, the information could be provided as inline text or in documentation that outlines your coding standards and guidelines. For a brownfield project, the AI can analyze your existing codebase to suggest coding conventions.

What constitution.md contains A typical constitution includes:

Technology standards: Required languages, frameworks, and services Security requirements: Authentication, authorization, and data protection rules Performance expectations: Response time targets, scalability requirements Coding conventions: Naming patterns, architectural patterns, testing requirements Compliance needs: Regulatory or organizational policy requirements Review and update After generation, review the constitution carefully. The AI uses this document when generating plans and code, so it needs to be accurate. If your organization requires “all data storage must use Azure services” or “APIs must follow RESTful conventions,” ensure those principles are documented here.

Generating the specification The specification defines what you’re building - user stories, acceptance criteria, and requirements.

The /speckit.specify command With the constitution in place, create your first feature specification. In the AI chat, provide a description of what you want to build:

text /speckit.specify Create an RSS Feed Reader application that allows users to subscribe to feeds by URL, view articles sorted newest-first, and track read/unread status. Data should persist locally on the device. The AI generates a spec.md file based on your description.

What spec.md contains The generated specification includes the standard sections you learned about in Unit 5: summary, user stories, acceptance criteria, functional requirements, nonfunctional requirements, and edge cases.

User stories describe features from the user’s perspective. For example, a user story could be similar to the following example:

As a user, I want to add RSS feeds by URL so that I can follow my favorite websites. Acceptance criteria define how to verify functionality. For the RSS Feed Reader, acceptance criteria might include:

User can add a feed by entering a valid RSS or Atom URL. Invalid feed URLs display a clear error message. New articles appear after refreshing feeds. Review and refine The generated spec is a starting point - the AI’s interpretation of your prompt. Your job is to:

Verify completeness: Does it capture all your requirements? Check accuracy: Is everything correctly understood? Add missing details: Fill in any gaps the AI missed Remove incorrect items: Delete anything that doesn’t belong Think of it this way: could you hand this spec to a developer (or AI) and have them understand exactly what to build? If not, refine it until you can.

Creating the technical plan The technical plan outlines how you implement the specification - architecture, technology choices, and implementation sequence.

The /speckit.plan command With a complete specification, create the technical design. Provide guidance about your preferred technologies and constraints:

text /speckit.plan Use .NET 8 for the application, SQLite for local data persistence, and System.ServiceModel.Syndication for RSS/Atom parsing. Apply HTML sanitization for security. The AI generates a plan.md file that translates specification requirements into technical decisions.

What plan.md contains The generated plan includes the sections covered in Unit 5: architecture overview, technology stack, implementation sequence, constitution verification, and assumptions. The AI translates your specification requirements into technical decisions. For example:

Build a .NET application with SQLite for local storage. A FeedService handles RSS/Atom parsing with System.ServiceModel.Syndication. Data access uses Entity Framework Core with a clean repository pattern. Review and adjust Check that the plan makes sense and aligns with your expectations:

Are the technology choices appropriate? Does the architecture address all specification requirements? Is anything from the spec unaddressed in the plan? If the AI proposed something you don’t want (maybe it chose a database you don’t prefer), edit the plan. The plan drives task generation, so it needs to be correct before proceeding.

Generating the task list The task list breaks down the plan into discrete, actionable work items for implementation.

The /speckit.tasks command With a solid plan, generate the implementation task list:

text /speckit.tasks This command reads the spec and plan to produce a tasks.md file - a checklist of discrete work items.

What tasks.md contains The generated task list reflects the phase-based organization and task characteristics you learned about in Unit 5. Tasks are organized into logical groups:

Phase 1: Foundation:

Create project structure and configure SQLite database. Define Feed and Article data models with Entity Framework Core. Phase 2: Core Feed Management:

Implement FeedService with URL validation and RSS/Atom parsing. Add feed refresh logic to detect new articles. Phase 3: Article Display:

Implement sorted article view (newest-first). Add read/unread tracking with database persistence. Review and verify Cross-check the task list against the spec and plan:

Do these tasks, if completed, fulfill everything in the spec? Is any requirement missing a corresponding task? Are any tasks too vague or too large to implement directly? If a task says something like “Implement authentication,” that’s probably too broad - break it down into smaller, specific tasks.

Implementing the tasks The implementation process uses the task list to generate working code, either with AI assistance or manually.

The /speckit.implement command GitHub Spec Kit provides an implement command that guides AI-assisted code generation:

text /speckit.implement The AI works through tasks sequentially, generating code for each one. You can also target specific tasks:

text /speckit.implement implement tasks 1-3 Implementation approaches You have options for how to work through tasks:

AI-assisted implementation: Use /speckit.implement to have the AI generate code for each task. Review and validate each piece before moving on.

Manual implementation with AI help: Work through tasks yourself, using your AI assistant for code suggestions and completion as needed.

Hybrid approach: Use AI for some tasks (especially boilerplate or repetitive work) and write others manually.

Verify each task However you implement, verify each task against the specification:

Does the code do what the spec requires? Does it follow the plan’s architectural decisions? Does it align with constitution principles? Run tests, manually check behavior, or use whatever verification is appropriate for the task.

Keeping artifacts updated If you discover something during implementation that changes the design - maybe you need a different approach than the plan specified - update your artifacts. Edit plan.md (and spec.md if requirements changed) to reflect the latest design requirements. This process keeps your documentation accurate and useful.

Optional enhancement commands GitHub Spec Kit provides other commands for quality and consistency:

The /speckit.clarify command Analyzes your specification to identify ambiguities and missing details. The AI asks clarifying questions like:

“The spec mentions refreshing feeds but doesn’t specify how often to check for updates. Should there be an automatic refresh interval?” Answer the questions, and the AI updates the spec accordingly.

The /speckit.analyze command Performs cross-artifact consistency checking. It verifies that:

The plan addresses all specification requirements Tasks cover all plan elements Everything aligns with the constitution Run this command after generating plan and tasks but before implementing.

The /speckit.checklist command Generates quality verification checklists for your specification. Use this command for self-review before sharing specs with stakeholders.

Best practices There are several best practices to follow when using GitHub Spec Kit:

Always review AI outputs: Don’t blindly accept generated content. The AI assists, but you’re the domain expert.

Communicate clearly in prompts: The quality of output depends on the quality of input. Include all important requirements and constraints.

Use the constitution for consistency: Document organizational standards early so all generated artifacts follow them.

Commit your artifacts: Save spec.md, plan.md, and tasks.md in your repository alongside code. They’re valuable documentation.

Know when to re-run vs. edit: If output is wrong, consider rerunning with a better prompt. For minor issues, just edit the file directly.

Follow the sequence: Run commands in order - spec before plan, plan before tasks. Each builds on the previous outputs.

Summary GitHub Spec Kit provides a structured set of commands that operationalize spec-driven development. By following the workflow from project initialization through constitution, specification, planning, task generation, and implementation, you can systematically transform ideas into working software. Each command produces artifacts that guide the next steps, ensuring alignment and quality throughout the process. Optional enhancement commands help clarify requirements and verify consistency, while best practices ensure effective use of AI assistance. With this understanding, you’re ready to apply GitHub Spec Kit in your development projects.

9 of 11

EXERCIE

10 of 11

ASSESSEMENT

11 of 11

MCP

  • https://www.anthropic.com/news/model-context-protocol
  • https://anthropic.skilljar.com/introduction-to-model-context-protocol
  • https://modelcontextprotocol.io/docs/getting-started/intro
  • https://www.deeplearning.ai/short-courses/mcp-build-rich-context-ai-apps-with-anthropic/

SDD

  • https://www.deeplearning.ai/short-courses/spec-driven-development-with-coding-agents/

Quizz

  1. What is the primary characteristic that distinguishes spec-driven development (SDD) from traditional development approaches?

Code is treated as the ultimate source of truth, and specifications serve as supporting documentation.

Specifications become the primary artifact that drives implementation, and code becomes an expression of those specifications. Correct

Developers write code first and then create specifications to document what was built.

  1. What happens to specifications in spec-driven development (SDD) when requirements change?

Specifications are treated as static documents that rarely need updates once created.

Specifications are discarded and new ones are created from scratch.

Specifications are updated, and affected implementation plans and code can be regenerated accordingly. Correct

  1. What are the four phases of the spec-driven development (SDD) workflow?

Research, Design, Develop, and Deploy.

Specify, Plan, Tasks, and Implement. Correct

Requirements, Architecture, Coding, and Testing.

  1. What distinguishes spec-driven development (SDD) outputs as ‘living artifacts’ compared to traditional documentation?

Living artifacts are stored in version control systems.

Living artifacts can evolve as new information emerges, with changes propagating through plan, tasks, and code. Correct

Living artifacts are automatically generated without human input. 5. How does spec-driven development (SDD) complement Agile methodologies?

SDD replaces Agile practices entirely with a more structured approach.

SDD can operate within Scrum by treating each user story with a micro-cycle of specify, plan, tasks, and implement. Correct

SDD requires comprehensive upfront documentation that conflicts with Agile values. 6. When comparing spec-driven development (SDD) to Test-Driven Development (TDD), what is a key difference in their approach?

TDD operates at the unit test level, while SDD works at a higher requirements level to describe complete features. Correct

TDD and SDD are mutually exclusive approaches that can’t be used together.

SDD produces automated tests while TDD produces specifications. 7. In the Specify phase of spec-driven development (SDD), what does a well-structured specification include?

Only a high-level summary of the feature with implementation details.

Summary, user stories, acceptance criteria, functional requirements, nonfunctional requirements, and edge cases. Correct

Architecture diagrams and technology stack decisions. 8. What is the purpose of the Plan phase in the spec-driven development (SDD) workflow?

To define what the software should do and capture user needs.

To determine how to build what the spec describes, including architecture decisions and technology choices. Correct

To break down work into actionable development tasks. 9. What is GitHub Spec Kit?

A proprietary AI model developed by GitHub for code generation.

An open-source toolkit that facilitates spec-driven development by integrating with AI coding assistants. Correct

A Visual Studio Code extension that replaces GitHub Copilot. 10. How does GitHub Spec Kit address the challenge of maintaining context across AI chat sessions?

By storing specifications, plans, and tasks as Markdown files in your repository. Correct

By replacing the AI’s memory with a cloud-based storage system.

By limiting AI interactions to a single continuous session. 11. What is required to install GitHub Spec Kit’s specify CLI tool?

Only Visual Studio Code with the GitHub Copilot extension.

Python 3.11 or later, Git, and the uv tool for package management. Correct

A paid enterprise license from GitHub. 12. Which AI coding assistants does GitHub Spec Kit support?

Only GitHub Copilot in Visual Studio Code.

Multiple agents including GitHub Copilot, Claude Code, Cursor, Windsurf, and Amazon Q Developer. Correct

Only command-line AI tools, not IDE-integrated assistants. 13. What is the purpose of the constitution.md file generated by the /speckit.constitution command?

To store the source code for the application’s core functionality.

To define project-wide principles, constraints, and non-negotiable requirements that ensure consistency. Correct

To list all the tasks required for implementing a feature. 14. What is the recommended sequence for using GitHub Spec Kit commands in a greenfield project?

Run commands in any order since they’re independent of each other.

specify init, then /speckit.constitution, /speckit.specify, /speckit.plan, /speckit.tasks, and finally /speckit.implement. Correct

Start with /speckit.implement and work backward to /speckit.specify.

Summary

In this module, you learned how to implement a spec-driven development (SDD) methodology using GitHub Spec Kit. You used the SDD workflow to develop a greenfield application by defining specifications upfront rather than iteratively prompting the AI with fragmentary instructions.

The main takeaway from this module is the ability to implement a spec-driven development process, which allows you to use AI tools like GitHub Copilot to generate code based on structured specifications. This approach enables you to focus on defining clear requirements and technical plans before implementation begins, ensuring that generated code aligns with intended behaviors from the start. You also learned how to compare SDD with other methodologies, set up your environment for GitHub Spec Kit, and use commands like /speckit.constitution, /speckit.specify, /speckit.plan, and /speckit.tasks to generate the artifacts that guide implementation. These skills are essential for effectively using AI-driven tools in a structured, enterprise-ready workflow.

You can apply the knowledge gained in this module to build greenfield applications with confidence, maintain consistency across AI-assisted development sessions, and reduce the gap between specifications and implementation. By practicing spec-driven development with GitHub Spec Kit, you can enhance your productivity and deliver higher-quality software that meets stakeholder requirements.

Note