Book 1: Ship

Before you start

Requires: Book 1 Offer

Estimated time: ~2 hours with Claude Code

What Is SpecKit?

You have a vault full of organised knowledge and a validated offer with paying early adopters. Now you need to build the thing. SpecKit is a specification-driven development workflow that turns product descriptions into working code through a repeatable four-stage cycle: Specify, Plan, Tasks, Implement.

Each stage produces a concrete artefact that feeds into the next, so nothing gets lost in translation between what you imagined and what gets built.

SpecKit is an open-source CLI and skill set available on GitHub. In this book you will use it with Claude Code, but the methodology works with any LLM coding assistant.

The SpecKit Cycle

1. Specify (/speckit.specify). Describe what you want built in plain language. Claude Code generates a structured specification with an overview, user stories, requirements, and acceptance criteria.
2. Plan (/speckit.plan). Claude Code reads the specification and produces a technical blueprint: which files need to be created or changed, the implementation order, and any risks or dependencies.
3. Tasks (/speckit.tasks). The plan is broken into a flat, ordered list of discrete tasks. Each task is small enough to implement and verify independently.
4. Implement (/speckit.implement). Claude Code works through the task list one task at a time, writing code, running tests, and moving on.

SpecKit also provides optional commands for when you need them: /speckit.clarify asks targeted questions to fill gaps in your spec, /speckit.analyze validates consistency across your spec, plan, and tasks, and /speckit.checklist generates a custom verification checklist for your feature.

The four stages form a loop. After implementing a feature, you may discover that the spec needs updating, or that the plan should change for the next feature. This is expected. The spec is always the source of truth — when reality diverges from the spec, update the spec first, then cascade the change through plan and tasks.

The Constraint of the Sold

In the Offer page, you found 10 early adopters. They paid. They are waiting. The offer PDF you shared with them is your build constraint now.

You can only build what the offer promised. Not more. Not less. Without this constraint, you would spend three weeks adding features nobody asked for. With the constraint, you build what people paid for, and you ship it to them.

---

Setting Up SpecKit

Before starting the SpecKit cycle, you need to install the CLI and initialise your project. Follow the SpecKit Setup guide for step-by-step installation instructions, then come back here to continue.

---

Step 0: Clone the Repository

The complete Sleep Tracker starter project is available on GitHub.

git clone https://github.com/coengineers/odd-sleep-tracker-mob-app.git ~/Documents/odd-sleep-tracker-mob-app

---

Step 1: Open the Project in Claude Code

Navigate into the project folder and start Claude Code:

cd ~/Documents/odd-sleep-tracker-mob-app
claude

Claude Code will automatically detect the CLAUDE.md file in the repository and load the project context. From this point on, all prompts in this guide should be entered inside Claude Code.

Step 1 Copy prompt

I have cloned the Sleep Tracker starter project to ~/Documents/odd-sleep-tracker-mob-app. Can you read the folder structure and confirm everything is in place?

Example output

Step 2: Follow the README Setup Instructions

Open the README.md file in the repository and read through the setup instructions. These cover installing Flutter, setting up an emulator, and installing dependencies.

Step 2 Copy prompt

I have read the README for the Sleep Tracker project. Can you help me follow the setup instructions to get all dependencies installed and the development environment ready?

Example output

Step 3: Get the App Running

Step 3 Copy prompt

Run the Sleep Tracker app in my Android emulator and walk me through what I should see on screen.

Example output

Before moving on, confirm these three things:

1. The app launches without crash screens or error messages in your terminal.
2. Navigation works by tapping each tab in the bottom bar.
3. The core interaction responds: tap the sleep log button and confirm the form opens.

If any of these checks fail, copy the error message from your terminal and paste it into Claude Code.

---

Building with the SpecKit Cycle

The starter project gives you a working Sleep Tracker with the core features your offer promised: logging sleep, viewing history, and seeing insights. Now you will use the full SpecKit cycle to add a new feature — the Sleep Goal — which lets users set a target sleep duration and track their progress against it.

This is where SpecKit earns its keep. Instead of jumping into code and hoping for the best, you will work through each stage methodically: specify what you want, plan how to build it, break it into tasks, implement, and verify.

Step 4: Establish the Constitution

Before building any features, define your project’s constitution. The constitution captures the principles and development guidelines that every specification, plan, and implementation should follow. You do this once per project, not per feature.

Step 4 Copy prompt

/speckit.constitution Create principles for the Sleep Tracker app focused on: simplicity over features, local-first data storage (no cloud, no accounts), accessibility and clear visual hierarchy, British English in all user-facing copy, and Flutter/Riverpod/SQLite as the tech stack.

Example output

Review the constitution. It should reflect the non-negotiable standards for the Sleep Tracker. Every specification and plan that SpecKit generates will be guided by these principles, so get them right once and they will pay off across every feature you build.

---

Step 5: Write the Specification

Your vault already contains the product requirements document at 03_build/app_prd.md — you completed it during the Vault guide. Your PRD lists several features. Do not try to build them all at once. Pick one feature for your first SpecKit cycle. You will repeat the full cycle (Specify → Plan → Tasks → Implement → Verify) for each remaining feature afterwards.

For this walkthrough, we will use the Sleep Goal feature. Point SpecKit at your PRD and tell it which feature to specify.

Step 5 Copy prompt

/speckit.specify Read the PRD at ~/Documents/sleep-tracker/03_build/app_prd.md and generate a specification for the Sleep Goal feature described there. This is the first feature I am building — ignore the other features in the PRD for now.

Example output

Review the specification against your offer PDF. Every requirement should trace back to something you promised your early adopters. If a requirement does not appear in the offer, remove it. If something from the offer is missing, add it. The spec is your contract with your customers.

If your spec has ambiguous areas, run /speckit.clarify — it asks targeted questions and encodes the answers back into the spec before planning begins.

---

Step 6: Generate the Plan

With a reviewed specification in place, generate a technical implementation plan. This is where architectural decisions get made before any code is written.

Step 6 Copy prompt

/speckit.plan I am building with Flutter, Riverpod for state management, SQLite for local storage, and SharedPreferences for user settings. The project structure follows the convention in the existing codebase: lib/screens/, lib/widgets/, lib/models/, lib/providers/, lib/database/.

Example output

This is the cheapest place to catch architectural problems. Changing a plan document costs nothing. Changing code after it has been written costs time and introduces risk. Read through the plan and check that the implementation order makes sense, the file structure follows the existing conventions, and no unnecessary dependencies have been introduced.

---

Step 7: Break into Tasks

The plan describes what needs to happen. Now break it into a flat, ordered list of discrete tasks. Each task should be small enough to implement and verify independently.

Step 7 Copy prompt

/speckit.tasks

Example output

After generating tasks, you can optionally run /speckit.analyze to validate consistency across your spec, plan, and tasks. It flags contradictions or gaps without modifying any files.

Review the task granularity. If a task touches more than three files or would take more than 15 minutes to verify, it is probably too large — ask Claude Code to split it. If two tasks always need to happen together, they should be one task.

---

Step 8: Implement

Now ask Claude Code to work through the task list in order. The key discipline here is sequential execution: complete one task, verify it works, then move to the next.

Step 8 Copy prompt

/speckit.implement

Example output

If a task fails, do not skip it and move on. The sequential order exists for a reason — later tasks depend on earlier ones. Fix the failure, verify the fix, then continue. If you cannot fix it, go back to the spec or plan and check whether the approach needs changing.

---

Step 9: Verify the Feature

Once all tasks are complete, run a final check against the acceptance criteria from your specification. This confirms that what was built matches what was specified.

Step 9 Copy prompt

Read the acceptance criteria from .specify/specs/sleep-goal/spec.md. For each criterion, verify whether the current Sleep Tracker implementation satisfies it. Report the result as a checklist with PASS or FAIL for each criterion. If any criterion fails, describe what is missing or broken.

Example output

If any criterion fails, you have two options: fix the implementation to match the spec, or update the spec if the criterion was wrong. Either way, the spec and the code must agree before you move on.

---

Running the Cycle Again

The SpecKit cycle is not a one-time process. Each feature in the Sleep Tracker gets its own cycle: Specify, Plan, Tasks, Implement, Verify.

You have just built the Sleep Goal feature. If your offer promised other features — or if early adopter feedback reveals something worth adding — start a new specification. Each iteration gets faster because Claude Code learns the project structure, your conventions become clearer, and you get better at writing specifications that leave less room for ambiguity.

The spec is always the source of truth. When you finish a feature, commit the spec, plan, and task list alongside the code. They are documentation that explains not just what was built, but why it was built that way.

---

Delivering to Your Early Adopters

The app is built. Now put it in the hands of the people who paid for it.

Your 10 early adopters from the Offer page are waiting. Share a development build (APK for Android, TestFlight for iOS). Send it to each early adopter with a short message: “Here is the Sleep Tracker you signed up for. I would love to hear what you think.”

Run lightweight UAT. Ask each person to do three things: log one night of sleep, check the history screen, and look at the insights dashboard. If they can do all three without asking you a question, the core experience works.

Collect feedback simply. A shared note, a WhatsApp group, or a reply to your message. Close the loop: when you fix something based on their feedback, tell them. Early adopters who feel heard become advocates.

---

What Comes Next

You have taken a starter project, set up a development environment, and built a real feature using the SpecKit workflow with Claude Code. The Sleep Tracker is yours to keep building.

Head to the Scale page to learn how to grow beyond your first 10 early adopters with outreach, content, and the Core Four framework.