Spec-Driven Development: From a Written Spec to a Working Feature

Uses Git and a terminal daily, and has run a coding agent at least once.

You already use an AI coding agent. This workshop teaches the part that decides whether it builds the right thing: defining the requirements properly, then implementing exactly those requirements. Using GitHub's Spec Kit, you build a small app one step at a time (project rules, spec, plan, tasks, code), then change a requirement halfway and push it through the spec first. You leave knowing when a spec is worth writing, and when it is overkill.

One Line vs a SpecWhat Spec-Driven Development IsThe RulesThe SpecThe Plan and the TasksThe CodeWhen the Requirement ChangesWhen Not To

Prerequisites

You use Git and a terminal daily, and have run a coding agent at least once.
A free GitHub account. Everything runs in a codespace in your browser; nothing to install.
Copilot Free turned on in the codespace, with a free Kilo Code account as the backup agent.
Building along is optional: you can watch and catch up from any step afterwards.

Syllabus outline

01
One Line vs a Spec
The same app built twice by the same agent: once from a one-line prompt, once from a written spec. What the one-line build decided on its own, why none of it is broken code, and why that is the problem.
02
What Spec-Driven Development Is
Why agents guess, and what a spec gives them instead. Spec Kit, Kiro, OpenSpec and plan mode side by side, and what Spec Kit does not do for you.
03
The Rules
Spec Kit set up in an empty repo, who writes what at each step, and a three-rule constitution every later step is checked against.
04
The Spec
A spec written by the agent from plain words, its clarifying questions answered, and a spec clinic: which acceptance scenario an agent can be held to, and how to rewrite the one it cannot.
05
The Plan and the Tasks
A plan that breaks one of your rules on purpose, and who notices. Tasks checked for order and for a test before the code.
06
The Code
The agent builds from the tasks while the tests hold it to the spec. The finished app running in a browser tab, with the spec's own figures on its balances page.
07
When the Requirement Changes
A new requirement pushed through the spec first, then the plan, then the code, with converge checking the code against the spec until they agree.
08
When Not To
Where the critics are right, a task-size table, and your own decision card: when a spec is worth writing and when a plain prompt is enough.

Dates coming soon

We are arranging the dates and venue for the next batch. Interested? Get notified the moment it is announced.