Spec-Driven
Development
with Spec Kit
Stop vibe coding. Start building software that works. The complete beginner's guide to structured AI development, from first install to a finished HabitTracker app.
Contents
- 01The Problem with Vibe CodingWhy unstructured AI coding wastes tokens and produces broken software
- 02The Anatomy of AI InteractionPrompts, agents, skills, MCP, pricing, and why your strategy, not GitHub's billing model, determines your cost and results
- 03What is Spec-Driven Development?The philosophy of specifications-first AI-assisted development
- 04Introducing GitHub Spec KitThe open-source toolkit, its commands, and project structure
- 05Setting Up Your EnvironmentInstalling VS Code, Copilot, and Spec Kit step by step
- 06The SDD Workflow Deep DiveConstitution → Specify → Plan → Tasks → Implement explained
- 07Token Optimization & Best PracticesSave money and get better AI output with structured specs
- 08Project: Build a HabitTrackerA complete walkthrough: every prompt, every command, every decision
The Problem with Vibe Coding
Why unstructured AI coding leads to wasted tokens, broken apps, and frustrated developers.
AI coding assistants have transformed software development. Tools like GitHub Copilot can generate entire functions, suggest algorithms, and build full applications from natural language. But there's a growing problem that developers experience daily.
When you sit down with an AI assistant and start giving it instructions without a clear plan, you're vibe coding: throwing vague prompts at an AI and accepting whatever it produces. At first it feels magical. But as projects grow, things fall apart fast.
The Vibe Coding Trap
Picture this: You're two hours into a coding session. You've given 15 different instructions. The AI built something that looked perfect 45 minutes ago. Then you realize it's completely wrong. The AI lost context, contradicted earlier decisions, and built something that doesn't match your original vision. Now you're burning tokens trying to fix it.
✕ Vibe Coding
- Random, ad-hoc prompts
- No persistent project context
- Contradictory AI outputs
- Massive token waste on re-explanation
- No quality gates or validation
- Zero traceability from intent to code
✓ Spec-Driven Development
- Structured, purposeful specifications
- Persistent context the AI always references
- Consistent, aligned output every time
- Optimized tokens: say it once, use it always
- Built-in analysis and consistency checks
- Full audit trail from spec to implementation
The problem isn't AI. It's how we communicate with AI. Spec-Driven Development gives your AI the structured context it needs to build exactly what you want, without re-explaining everything on every prompt.
The Anatomy of AI Interaction
Prompts, agents, skills, MCP servers, and pricing. Why your strategy, not GitHub's billing model, decides your cost and your results.
In 2025, GitHub announced it was moving Copilot from a subscription model built around Premium Requests to Usage-Based Billing (UBB), a pay-as-you-go model priced in AI Credits. Almost overnight, developers and companies started worrying: "Is Copilot suddenly more expensive? Are we going to blow through our budget?"
Here's the truth this chapter walks through: the pricing model isn't the real problem. It just shows you something that was already true. Under the old subscription model, wasteful AI usage was hidden behind a flat fee. Usage-based billing makes that waste visible: every prompt, every agent you call, every skill you load, every MCP server request gets turned into tokens, and tokens are what you pay for. Without a plan for how you use AI, you'll burn through your budget fast, no matter which pricing model GitHub uses.
The Anatomy of an AI Interaction
Every time you interact with an AI coding assistant, several parts work together before the model produces any output. It's easy to think of "prompting" as just typing a sentence into a chat box. In reality, by the time your request reaches the model, it usually carries a lot more with it:
Your Request
What you typed or spoke
Context Assembly
Open files, specs, memory, instructions
Agents / Skills / MCP
Extra tools & knowledge invoked
Compiled Prompt
Everything merged into one payload
Tokens
The unit models actually process
Billed Usage
What shows up on your invoice
Your typed message, the files Copilot reads for context, the custom agent you called, the skill it loaded, the MCP server it queried: all of it gets combined into a single prompt sent to the model. None of these pieces are free. Everything you add to your AI's context is something you pay for, in tokens and in cost. Treating these pieces as part of a real strategy, instead of adding them without thinking, is exactly what Spec-Driven Development (SDD) helps you do, as you'll see throughout this book.
GitHub Copilot's New Pricing Model
Here's a quick, plain-language summary of what changed. GitHub Copilot originally sold flat-rate subscription tiers (Free, Pro, Pro+, Business, Enterprise) that included a bucket of Premium Requests, a rough unit that didn't line up well with the actual cost of running a model. GitHub has since moved to Usage-Based Billing, where usage is tracked in AI Credits that scale with the model and the amount of work performed, on top of (or instead of) a base subscription.
Premium Requests (legacy)
- Flat monthly bucket of requests
- Rough measure: a tiny fix and a huge refactor could cost the same "1 request"
- Easy to underestimate real usage, so the cost stayed hidden
- Hitting the cap meant a hard stop or throttling
Usage-Based Billing / AI Credits
- Pay-as-you-go, tracked by actual model usage
- Cost scales with tokens used, so it reflects real effort
- Rewards efficient prompting and context management
- Punishes vague prompts, bloated context, and unnecessary tool calls
For the full, current details on plans and pricing, check GitHub's own pages. Pricing details change over time, so always check the source rather than relying on a snapshot in a book:
- github.com/features/copilot/plans: current Copilot plans and pricing
- github.blog: GitHub Copilot is moving to usage-based billing: the official announcement
Most of the worry around UBB isn't really about the pricing model. It's about how we interact with AI. Under Premium Requests, we felt free to over-prompt, over-explain, and pile on extra context, because the flat fee covered the waste. Usage-based billing removes that safety net. It didn't create the waste. It just showed us waste that was already there.
Prompt Engineering vs. Context Engineering
Two ideas matter here, and they're not the same thing:
Prompt Engineering
Writing the instruction itself: your goal, your constraints, your desired output format. It's about what you ask and how clearly you ask it.
Context Engineering
Choosing what the model can see: which files, specs, memory, and tools you include. As models get smarter, an average prompt with good context often works better than a great prompt with poor or missing context.
In practice you need both. A great prompt with no relevant context leaves the model guessing. Rich context with a vague prompt leaves the model unfocused. And it matters either way, because the more context you load, the more tokens you spend on every single turn. Good context engineering is selective: include the two files that matter, not the whole repository.
The Prompt Engineering Template
Use this five-part structure to write prompts that are clear, focused, and consistently effective. It's the foundation of good prompt engineering, whatever context you attach to it:
# Goal
Define what you want to achieve. State the desired outcome clearly and concisely so the AI understands the end result you're aiming for.
# Context
Provide the background information the AI needs. Include relevant constraints, existing code, project details, or domain knowledge that shapes the answer.
# Instructions
Specify exactly how the AI should approach the task. List steps, rules, or requirements the response must follow.
# Output (optional)
Describe the format, structure, or length of the expected response. For example: a JSON object, a numbered list, or a code block in a specific language.
# Persona (optional)
Assign the AI a role or expertise level. Framing the AI as a "senior security engineer" or "UX writer" shapes its tone, vocabulary, and perspective.
Copy-Paste Template
Save this blank template and fill in the comments for any new AI prompt. The # lines are real Markdown headings, and the <!-- ... --> lines are just guidance comments to replace with your own text:
<!-- Define what you want to achieve. State the desired outcome clearly and concisely so the AI understands the end result you're aiming for. -->
# Context
<!-- Provide the background information the AI needs. Include relevant constraints, existing code, project details, or domain knowledge that shapes the answer. -->
# Instructions
<!-- Specify exactly how the AI should approach the task. List steps, rules, or requirements the response must follow. -->
# Output (optional)
<!-- Describe the format, structure, or length of the expected response. For example: a JSON object, a numbered list, or a code block in a specific language. -->
# Persona (optional)
<!-- Assign the AI a role or expertise level. Framing the AI as a "senior security engineer" or "UX writer" shapes its tone, vocabulary, and perspective. -->
Not every prompt needs all five sections. Start with # Goal and # Instructions for simple tasks. Add # Context when the AI lacks background information. Use # Output and # Persona to fine-tune the style and format of the response.
Agents, Skills & MCP Servers: What, When, Why
Beyond raw prompts, modern AI coding tools let you extend the model with reusable building blocks. Each one is powerful, and each one adds to the context (and cost) of every interaction it's loaded into. Know what they are before reaching for them:
Agents
A configured "persona" with its own instructions, tools, and sometimes model choice, built for a recurring role (for example, a code reviewer or a release-notes writer). Best for ongoing, well-defined responsibilities you use again and again.
Skills
Focused, self-contained instructions or scripts for a specific, repeatable task (for example, "generate a memo" or "fill an expense report"). Best for narrow, procedural tasks that don't need a whole persona.
MCP Servers
External tool and data providers the model can call (databases, cloud APIs, ticketing systems). Best for giving the model real, live capabilities it doesn't have on its own, at the cost of extra tokens spent describing those tools on every turn.
Quick decision guide: reach for a skill when the task is a repeatable, narrow procedure. Reach for an agent when you need a persistent role with its own tone, tools, and judgment. Reach for an MCP server when the model needs to talk to a real external system. If a one-off prompt with good context solves it, don't reach for any of them.
Every agent, skill, and MCP server that's active in a session becomes part of the context sent with every prompt in that session, whether you use it on a given turn or not. Enabling ten MCP servers "just in case" adds cost to every request without you noticing. Use only what a given feature really needs, and turn off the rest. This is exactly the kind of decision Spec-Driven Development forces you to make on purpose, instead of by accident.
A few best practices for keeping this efficient in VS Code:
Scope custom instructions
Keep .github/copilot-instructions.md short and project-specific. It gets sent along with every request.
Enable MCP servers per project
Don't enable every MCP server globally. Configure them per workspace so unrelated projects don't pay for tools they never use.
Prefer skills over agents for one-off procedures
A skill is called on demand. An idle custom agent can still add overhead to how requests are routed and framed.
Review what's loaded from time to time
Review enabled extensions, agents, and MCP servers the same way you'd review dependencies. Remove what you no longer need.
Why Spec-Driven Development Is the Strategy
Everything above points to the same conclusion: AI doesn't fail because the model is weak, or because a pricing model changed. It fails because we hand it work without a plan. Spec-Driven Development is that plan. But SDD's value doesn't start when you open your AI assistant. It starts before you write a single prompt:
Requirements
Functional & non-functional
Architecture
Design the system, not just the feature
Specification
Turn decisions into a written spec
AI Validates & Plans
Use AI to check gaps, plan tasks
Small Steps
Implement one focused feature at a time
Notice what comes first: engineering the system, meaning clarifying functional and non-functional requirements, sketching architecture, understanding constraints, before AI enters the picture. Only then does AI take over, to check your thinking, plan the work, and implement it in small, focused steps rather than one giant, unfocused request. This is much cheaper, with fewer wasted tokens and fewer do-overs, and it produces much better software.
The bill you get at the end of the month reflects your AI strategy, not just GitHub's pricing choices. Vague prompts, bloated context, and unnecessary agents, skills, and MCP servers cost real money under UBB, and they always cost real time and quality, even under a flat subscription. The rest of this book teaches you the discipline, Spec-Driven Development, that turns AI from an unpredictable expense into a reliable, efficient partner. Let's start with what SDD actually is.
What is Spec-Driven Development?
Specifications become executable, directly generating working implementations rather than just guiding them.
Chapter 2 showed why prompts, context, agents, skills, and MCP servers all need a deliberate strategy, otherwise you burn tokens and budget with little to show for it. Spec-Driven Development (SDD) is that strategy, formalized. It flips the script on traditional software development: for decades, code was king, and specifications were scaffolding we discarded once the "real work" began. SDD changes this: specifications become the source of truth, directly driving AI-generated implementations.
Think of it as giving your AI assistant a detailed blueprint instead of shouting instructions from across a noisy room. The blueprint stays consistent, complete, and always available.
The Four Pillars of SDD
Intent First, Code Second
Define what you're building and why before thinking about how. This ensures your AI understands the goal, not just the task.
Specs as Source of Truth
Your spec files are the primary artifacts. Code is generated FROM specifications. When specs change, implementations follow.
Structured Communication
Instead of ad-hoc prompts, SDD provides a standardized language for communicating with AI agents. Every interaction builds on shared understanding.
Progressive Refinement
Start high-level and add detail incrementally. Each phase adds specificity, reducing ambiguity at every step.
The SDD Workflow at a Glance
Constitution
Project principles & rules
Specify
What to build & why
Clarify
Resolve ambiguities
Plan
Tech stack & architecture
Tasks
Actionable work items
Implement
AI generates code
Introducing GitHub Spec Kit
An open-source toolkit with 68,000+ stars that makes Spec-Driven Development practical and accessible.
GitHub Spec Kit is the open-source toolkit that provides structure, templates, and workflow automation for SDD. It works seamlessly with VS Code, GitHub Copilot, and 15+ other AI coding agents. Install once, use on every project.
The Slash Commands
After initializing Spec Kit in your project, these slash commands become available in your AI assistant's chat. Spec Kit has six core workflow commands plus three optional enhancement commands:
Core Commands
/speckit.constitution
Defines the non-negotiable rules for your project: coding standards, testing requirements, accessibility, performance targets. Every other command references this file. Run once per project.
/speckit.specify
Creates a feature specification from your description. Describe WHAT and WHY. Auto-creates a Git branch and spec directory. Run for each new feature.
/speckit.plan
Generates a technical implementation plan: architecture, dependencies, data models. You provide tech stack choices. Run after spec is finalized.
/speckit.tasks
Breaks the plan into ordered, executable tasks with clear dependencies and acceptance criteria. Each task is focused and manageable. Run after plan is ready.
/speckit.taskstoissues
Converts your generated task list into GitHub Issues for team tracking and execution. Links implementation tasks directly to your project board. Optional. Great for team projects.
/speckit.implement
Executes all tasks to generate working code, tests, and configuration. The AI references every artifact you've built. Run when everything is approved.
Optional Enhancement Commands
/speckit.clarify
Asks structured, sequential questions to resolve ambiguities before planning. Catches gaps before they become expensive bugs. Run after specify, before plan.
/speckit.analyze
Cross-artifact consistency check. Validates that constitution, spec, plan, and tasks all align. Flags CRITICAL findings. Run after tasks, before implement.
/speckit.checklist
Generates custom quality checklists that validate requirements completeness, clarity, and consistency, like "unit tests for English". Helps catch vague or conflicting requirements early. Use at any stage.
Project Structure
All spec files are plain Markdown, so they work great with Git. Commit them alongside your code so you have a complete, auditable trail from intent to implementation. When someone asks "why was it built this way?", your spec files have the answer.
Setting Up Your Environment
From zero to a working Spec Kit project in under 10 minutes.
Install VS Code
Download from code.visualstudio.com. Free for Windows, macOS, and Linux. We use VS Code because of its excellent Copilot integration and Agent Mode support.
Install GitHub Copilot
Open Extensions in VS Code, search "GitHub Copilot", install it, and sign in with your GitHub account. Critical: enable Agent Mode. Spec Kit's slash commands require it. Look for the agent toggle in the Copilot chat panel header.
Install the uv package manager
Spec Kit ships as a Python CLI tool distributed via uv. Install uv first:
Install Spec Kit
Find the latest release tag at github.com/github/spec-kit/releases
Initialize Your First Project
When VS Code opens, switch Copilot to Agent Mode in the chat panel. Type /speckit and you should see all the commands in the autocomplete. If they don't appear, restart VS Code.
The SDD Workflow Deep Dive
A detailed walkthrough of each phase, with examples and best practices for every command.
Phase 1: The Constitution
The constitution is the DNA of your project. It defines non-negotiable principles that every AI interaction must follow. Think of it as the "rules of the game": coding standards, testing strategy, performance targets, accessibility requirements.
Create governing principles for a modern web application.
# Context
This constitution will guide all code generation and be referenced throughout the project by every agent.
# Instructions
Define non-negotiable principles for each area below:
• Code quality: TypeScript strict mode, no any types, ESLint + Prettier
• Testing: Unit tests with Vitest, integration tests for critical paths, 80% coverage minimum
• Accessibility: WCAG 2.1 AA, semantic HTML, keyboard navigation, screen reader support
• Performance: <3s initial load, lazy loading for non-critical resources, Core Web Vitals passing
• Architecture: Feature-based folder structure, custom hooks for shared logic, no prop drilling beyond 2 levels
Keep it to 8-12 clear principles. Too many create conflicts; too few leave too much ambiguity. Always review the generated constitution. The AI expands your input, and you should verify it captured your intent correctly. This is the foundation everything else builds on.
Phase 2: Specification
Describe WHAT you want to build and WHY, not HOW. Focus on features, user stories, and expected behaviors. Spec Kit auto-creates a Git branch and directory for each feature.
Build a habit tracking application that helps users build and maintain positive daily routines.
# Context
Individual users who want simple, private habit tracking without accounts or internet access. The app must be enjoyable to use every day, especially on mobile.
# Instructions
Allow users to create daily habits with custom names and emoji icons, track completion with a simple tap, view current and longest streaks, and see weekly/monthly progress on a visual dashboard. The app should feel motivating and be usable one-handed on mobile.
The AI will expand this into a full specification with user stories, acceptance criteria, edge cases, and constraints, all stored in specs/001-habit-tracker/spec.md. Review every section. This is your most important checkpoint.
Phase 3: Clarification
The /speckit.clarify command triggers structured Q&A that eliminates ambiguity before it becomes expensive rework. The AI asks sequential questions based on gaps it detects in your specification.
Skip this for very simple features. Use it for anything with user interactions, data persistence, multiple states, or business logic. The 5 minutes you spend answering questions saves hours of debugging wrong assumptions later.
Phase 4: Technical Planning
Now you define the HOW: technology stack, architecture, and dependencies. The plan is checked against your constitution for compliance.
Define the technical architecture and stack choices for the habit tracking application.
# Context
The spec is finalized. This plan translates product requirements into concrete technical decisions aligned with the constitution.
# Instructions
Use React 18 with TypeScript and Vite for the frontend. Tailwind CSS for styling. Browser localStorage for persistence, no backend needed. React Router v6 for navigation. date-fns for date calculations. framer-motion for completion animations. Keep external dependencies minimal.
Phase 5: Tasks & Analysis
Run /speckit.tasks to generate ordered, actionable work items from your plan. Each task is small enough for reliable AI execution, with clear dependencies and acceptance criteria. Then run /speckit.analyze as your quality gate. It cross-validates that all artifacts (constitution, spec, plan, and tasks) are consistent and catches any CRITICAL misalignments before a single line of code is written.
Phase 6: Implementation
Run /speckit.implement and let the AI work. It reads the constitution for principles, the spec for requirements, the plan for architecture, and executes tasks in order, generating real code, tests, and configuration files.
Traditional Process: ~12 hours
- Write a PRD (2-3 hours)
- Create design documents (2-3 hours)
- Set up project structure (30 min)
- Write technical specifications (3-4 hours)
- Create test plans (2 hours)
SDD Process: ~17 minutes
- /speckit.constitution (5 min)
- /speckit.specify (5 min)
- /speckit.plan (5 min)
- /speckit.tasks (2 min)
- /speckit.analyze (2 min)
- /speckit.implement (automated)
Token Optimization & Best Practices
How SDD dramatically reduces AI token consumption while producing better output.
Every AI prompt costs tokens, and tokens cost money. Vibe coding wastes tokens through repetition, context-switching, and re-explanation. SDD minimizes this by giving the AI everything it needs, structured for maximum clarity, once.
Token Consumption Comparison
* Approximate comparison based on community reports. Savings vary by project complexity.
10 Best Practices
1. Invest in the First Prompt
Your /speckit.specify prompt is the highest-leverage moment. More detail upfront = fewer corrections later = fewer tokens wasted.
2. Review Every Artifact
Don't blindly accept generated specs, plans, or tasks. Your review turns generic output into a precise specification.
3. Keep the Constitution Focused
8-12 clear principles. Too many create conflicts; too few leave ambiguity that wastes tokens on clarification.
4. Always Clarify Complex Features
5 minutes answering /speckit.clarify questions saves hours of "no, that's not what I meant" debugging loops.
5. Run /speckit.analyze After Tasks
The analysis command is your quality gate. Run it after /speckit.tasks, before /speckit.implement. It catches misalignments before a single line of code is written.
6. One Feature Per Spec
Don't specify your entire app at once. Break into features with separate specs. Smaller specs = focused tasks = reliable output.
7. Iterate on Specifications
Specs aren't final after pass one. Update them as you learn, then re-run downstream commands. SDD is iterative.
8. Commit Specs to Git
Treat spec files as first-class code. Full audit trail of decisions. New team members read specs instead of reverse-engineering code.
9. Use Descriptive Names
"001-user-auth" beats "001-feature". Clear names help navigate specs/ and make Git history meaningful.
10. Learn from Results
After /speckit.implement, review the code. Gaps between expectation and output = feedback to improve your spec writing.
Project: Build a HabitTracker
A complete, hands-on walkthrough. Every prompt, every command, every decision, building a genuinely useful app.
This isn't a toy project. We're building a real HabitTracker app that you'll actually want to use daily. It tracks habits, calculates streaks, shows visual progress, and helps you build better routines. Follow along step by step, copy the prompts exactly, and you'll have a working app.
HabitTracker: Project Blueprint
A daily habit tracking app that helps users build and maintain positive routines
What We're Building
A genuinely useful app with these real-world features:
Habit Management
Create, edit, and delete habits with custom emoji icons and flexible frequency settings.
- Custom name + emoji picker
- Daily, weekday, or specific-day frequency
- Category grouping (health, learning, productivity)
- Drag-and-drop reordering
Daily Tracking
One-tap completion designed for mobile-first, one-handed use. Visual feedback that feels rewarding.
- Today view with all active habits
- Tap to complete with animation
- Undo within 5 seconds
- Progress ring showing daily completion %
Streaks & Motivation
Streak tracking that motivates consistency. Visual cues that make progress tangible.
- Current streak counter per habit
- Personal best streak record
- Streak milestones (7, 30, 100 days)
- Motivational messages based on progress
Progress Dashboard
Visual analytics that help users understand their patterns and celebrate wins.
- Weekly completion heat grid
- Monthly calendar heatmap
- Overall completion rate
- Best performing habits ranking
Smart Defaults
Pre-configured starter habits so new users get value immediately without setup friction.
- Starter pack: exercise, reading, water, meditation
- Quick-add from curated habit library
- Sensible default frequencies
- Skip onboarding if desired
Data Persistence
All data stored locally. No accounts, no backend, no privacy concerns. Works offline.
- localStorage with migration support
- JSON export for backup
- Import from backup file
- Data schema versioning
Step-by-Step Build Guide
Step 1: Initialize the Project
Open your terminal and create the project:
In the Copilot chat panel, look for a toggle or dropdown that says "Agent" mode. The /speckit commands only appear in Agent mode. If they don't show up, restart VS Code and try again.
Step 2: Define the Constitution
This sets the rules of the game. Copy this prompt into Copilot chat:
After Copilot generates the constitution, open .specify/memory/constitution.md and read it thoroughly. The AI will expand your input into detailed articles. Make sure it captured your intent, especially around testing and accessibility standards. Edit anything that doesn't match your expectations before moving on.
Step 3: Write the Specification
This is the most important prompt in the entire process. The more detail here, the better everything downstream will be. Copy this into Copilot chat:
Step 4: Clarify Ambiguities
Run the clarify command. The AI will ask structured questions. Here are the ones you'll likely see and suggested answers:
Q: What happens to historical data when a habit is deleted?
Answer: Keep completion history. Deleted habits move to an "archived" state so their data still shows in stats. Users can permanently delete from settings.
Q: Should the app handle timezone changes?
Answer: Use the browser's local timezone. "Today" is always based on device time. Don't handle timezone changes in v1, keep it simple.
Q: How should the emoji picker work?
Answer: A simple grid of ~30 pre-selected emojis organized by category (activities, objects, nature, food). No free-text emoji input. Fast and mobile-friendly.
Q: What's the behavior when opening the app for the first time today?
Answer: Show today's habits with all toggles unchecked. Display yesterday's completion rate as a small banner ("Yesterday: 5/6 completed!"). Focus is always on today.
Step 5: Create the Technical Plan
Step 6: Generate Tasks
Open specs/001-habit-tracker/tasks.md and review the generated tasks. Are they in the right order? Are dependencies clear? Are acceptance criteria specific? This is your last chance to adjust before running the analysis and implementation.
Step 7: Analyze for Consistency
Run the quality gate after tasks are generated:
If the analysis finds CRITICAL issues (e.g., "spec requires drag-and-drop but plan doesn't include a DnD library"), fix them in the spec, plan, or tasks before implementing. This is the cheapest place to catch mistakes, before any code exists.
Step 8: Implement!
This is the moment. Run the implement command and let Copilot build your entire app:
Step 9: Test & Verify
Step 10: Fix Issues (Normal!)
If something doesn't work, and it probably won't be perfect on the first try, here's the workflow:
Bug in Generated Code
Copy the error into Copilot chat. It has full context from the spec and will fix it quickly. For simple bugs, this is faster than updating the spec.
Missing Feature
Update the spec with the missing requirement. Re-run /speckit.tasks to generate a new task list, then /speckit.implement for the missing piece.
Architecture Issue
Update the plan to fix the architectural decision. Re-run tasks and implementation. The spec-driven approach means you're fixing the design, not patching symptoms.
You've built a genuinely useful HabitTracker app using Spec-Driven Development. Every decision is documented in your spec files. You can iterate, add features, or hand the project to another developer, and they'll know exactly what was built and why. That's the power of SDD.
Release Notes
What's changed in this eBook over time: content, structure, and reading-experience updates.
Chapter 02 reworked: "The Anatomy of AI Interaction"
- Retired the standalone "Prompt Engineer" chapter and folded its template into a broader Chapter 02.
- Added "The Anatomy of an AI Interaction": how prompts, agents, skills, and MCP servers all collapse into billed tokens.
- Added a plain-language explainer of GitHub Copilot's move from Premium Requests to Usage-Based Billing (AI Credits), with links to the official sources.
- Added "Prompt Engineering vs. Context Engineering" and "Agents, Skills & MCP Servers" sections with decision guides and VS Code best practices.
- Added "Why Spec-Driven Development Is the Strategy," tying requirements/architecture-first thinking back into the rest of the book.
New reading experience: sidebar navigation, search & release notes
- Added a persistent chapter/topic sidebar so you can jump straight to any section instead of scrolling the whole book.
- Added in-page search (press
/or click the search box) with live results and jump-to-highlight. - Added this Release Notes section to track future content updates in plain language.
- Simplified the top nav bar; chapter links now live in the sidebar, with quick access to Release Notes and the Spec Kit GitHub repo.
- Book history starts here, earlier updates weren't tracked individually before this redesign.
Stop vibe coding.
Start building with intent.
Spec Kit is free, open source, and backed by a growing community of 68,000+ developers who believe that better specifications lead to better software.