3 Days of Spec-Driven Development

Setup: twenty minutes before Day 1

Day 0 · 20 min · Do this once, at the desk where you will do the course.

Four things, in order: confirm Claude Code runs and is signed in, pick the lane you will use for three days, copy the sandbox somewhere you can break it, and watch one test run go green. Nothing here teaches an idea. It is the twenty minutes that keep Day 1 from turning into a toolchain afternoon.

Confirm Claude Code runs

This course assumes Claude Code is already installed in your terminal and signed in with the sign-in your team uses for Claude Code. One command confirms it:

claude --version

It prints the installed version. Every mechanical claim in this course — keystrokes, mode names, settings keys, the strings on the approval prompt — was checked against Claude Code 2.1.280 on 2026-09-22. A newer version is expected and fine; if a keystroke on a lesson page does not match what your terminal does, trust your terminal and check the linked documentation at the bottom of that page.

Connectors can wait

If your team runs read-only connectors, such as your read-only source-control connector, none of them are needed today. Day 2 is where the environment gets written down and turned on. Today the only thing that has to work is the terminal.

Pick a lane

The sandbox ships twice from one spec: a Swift package and a Kotlin JVM project on Gradle. The two lanes produce the same output strings, so every lesson and every exercise works in either. Pick the toolchain already on your machine and stay in it for three days. Switching mid-course costs you the state you built up, not the ideas.

Swift lane

You need Swift 6.2 or later, from Xcode 26 or a standalone toolchain. Check it with swift --version.

Kotlin lane

You need a JDK 17 or later; the Gradle wrapper is committed, so you do not install Gradle yourself. Check the JDK with java -version.

The lane buttons at the top of this page remember your choice in this browser. Until you press one — and with JavaScript off — both lanes stay visible under their own names and nothing is hidden from you.

Copy the sandbox to a working folder

You never edit sandbox/ itself. Every day starts from a fresh copy, which is what makes an exercise repeatable and a mistake cheap. For this check, make a scratch copy at the course root called setup-work/, the same place Day 1's first exercise will make its own day1-work/.

Run this from the course folder, the one holding this page, in your clone or download of the course repository; the hosted pages alone have no sandbox/ to copy.

Swift lane 
cp -R sandbox/swift setup-work
Kotlin lane 
cp -R sandbox/kotlin setup-work

Run the tests once

This is the whole point of setup: a green run before Day 1, so that when Day 1 turns a test red on purpose you know the red came from the lesson and not from your machine. The test command runs from the course folder and never asks you to change directory.

Swift lane 
swift test --package-path setup-work

A fresh copy on this machine, on 2026-09-23, printed this verdict for the whole suite and its count line:

Test Suite 'All tests' passed at 2026-09-23 16:04:08.343.
	 Executed 34 tests, with 1 test skipped and 0 failures (0 unexpected) in 0.013 (0.016) seconds

Your timestamp and durations will differ; the counts will not. The skipped test is deliberate, and Day 1 turns it on. The run also prints Test run with 0 tests in 0 suites passed: the suite is XCTest, so swift-testing has nothing of its own to run.

Kotlin lane 
setup-work/gradlew -p setup-work test

A fresh copy on this machine, on 2026-09-23, printed Gradle's verdict, with the duration and the link shortened to … here:

BUILD SUCCESSFUL in …
5 actionable tasks: 5 executed
Consider enabling configuration cache to speed up this build: …

BUILD SUCCESSFUL is the line that decides; the configuration-cache line is a hint, and a re-run reports the tasks as up to date. This lane's summary carries no test counts.

What matters in both lanes is zero failures: the Swift count line says so, and in the Kotlin lane BUILD SUCCESSFUL does. That is all setup-work/ was for: nothing later in the course uses it, so delete it with rm -rf setup-work once you have seen the green run. Day 1 makes its own copy.

If you see something else instead

Swift lane
Swift, first run

The first swift test run builds the package before any test runs, so it is slower than later runs. It downloads nothing, so it needs no network access.

Kotlin lane
Kotlin, first run

The first gradlew run downloads the Gradle distribution and the test libraries, so it needs network access and takes a few minutes; later runs are seconds. If it stops at something like Could not resolve all files or a timeout against a distribution URL, that is the network, not your code. On a restricted machine, run it once where downloads are allowed, or ask your platform team which internal mirror to point it at.

Swift lane
Kotlin lane

Self-check

Four lines. Tick each one when it is true on your machine, not when it sounds true.

Ticks need JavaScript and stay in this browser.

What Day 1 expects

Day 1 assumes exactly the four lines above and nothing else: no editor plugin, no connectors, no account beyond the sign-in. It opens with a ten-minute video, then six short lessons and four exercises, and it makes its own copy of the sandbox in the first exercise.

Done when

All four self-check lines are true and you have seen a green test run in your own terminal with your own eyes.

Sources

No ledger entry covers the install command itself, so this page links the official documentation instead of restating it.