Ship

Before you start

Requires: Offer Guide

Estimated time: ~30 minutes with your LLM

You have a vault full of organised knowledge and a validated offer with paying early adopters. Now build the thing.

This guide introduces SpecKit, an open-source CLI and skill set available on GitHub, for turning product descriptions into working software. It works with any LLM coding assistant — Claude Code, Codex, Gemini CLI, or whatever comes next. The methodology stays the same regardless of the tool.

---

What Is SpecKit?

SpecKit is a specification-driven development workflow. Instead of jumping straight into code, you work through a structured cycle that turns a plain-language description into a finished feature. 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.

The SpecKit Cycle

1. Specify (/speckit.specify). Describe what you want built in plain language. Your LLM coding assistant generates a structured specification with an overview, user stories, requirements, and acceptance criteria.
2. Plan (/speckit.plan). Your LLM coding assistant 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). Your LLM coding assistant 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 guide, 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: Open Your Terminal and Start Your AI Tool

Before you can run any prompts, you need a terminal open and an AI coding tool running.

1. Open a terminal. If you have not used a terminal before, follow the Using the Terminal guide.
2. Navigate to your project folder. This should be a separate folder from your vault. SpecKit will generate application code, configuration files, tests, and build artefacts — keeping them in a dedicated project folder stops your vault from becoming cluttered with files that have nothing to do with your knowledge base.

   cd ~/path-to-your-project

3. Start your AI coding tool. Type the command for whichever tool you have installed:

   claude        # Claude Code
   gemini        # Gemini CLI
   codex         # Codex

Once your tool is running and waiting for input, continue to Step 1.

---

Step 1: 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 1 Copy prompt

/speckit.constitution Create principles focused on [your project's priorities — e.g. accessibility, performance, simplicity, British English copy]

Example output

Review the constitution. It should reflect the non-negotiable standards for your project. 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 2: Write the Specification

Take your product requirements document and ask your LLM coding assistant to generate a structured specification. The spec is the single source of truth for what gets built.

Step 2 Copy prompt

/speckit.specify [description of your feature based on 03_build/app_prd.md]

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.

---

Step 3: Generate the Plan

With a reviewed specification in place, ask your LLM coding assistant to produce a technical implementation plan. This is where architectural decisions get made before any code is written.

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

Step 3 Copy prompt

/speckit.plan I am building with [your tech stack — e.g. Astro, React, Supabase]

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 your project’s conventions, and no unnecessary dependencies have been introduced.

---

Step 4: 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 4 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 your LLM coding assistant to split it. If two tasks always need to happen together, they should be one task.

---

Step 5: Implement

Now ask your LLM coding assistant 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 5 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 6: 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 6 Copy prompt

Read the acceptance criteria from .specify/specs/[feature-name]/spec.md. For each criterion, verify whether the current 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 your offer gets its own cycle: Specify, Plan, Tasks, Implement.

Pick the next feature from your offer PDF. Start a new specification. Each iteration gets faster because your LLM 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 product is built. Now put it in the hands of the people who paid for it.

Your 10 early adopters from the Offer guide are waiting. Share a working build — a deployed URL, an APK, a TestFlight link, whatever suits your product. Send it to each early adopter with a short message: “Here is the product you signed up for. I would love to hear what you think.”

Run lightweight UAT. Ask each person to complete three core tasks that exercise the main features of your product. 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. You are not looking for detailed bug reports at this stage — you want to know if the product delivers the transformation you promised in the offer.

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 product specification and turned it into working software using a repeatable workflow. The SpecKit cycle works for every feature: Specify, Plan, Tasks, Implement, Verify.

When you are ready to grow beyond your first 10 early adopters, move on to the Scale guide. That guide covers lead generation, the Core Four framework, and practical next steps for reaching your next 100 customers.