From Validated Idea to Claude Code Project

To turn a ShipFit playbook into a Claude Code project, export your validated decisions into the project’s instruction file (commonly CLAUDE.md), commit it to the repo root, and start a Claude Code session. The agent reads that file on start, so your buyer, V1 scope, and pricing become standing build instructions for every prompt, not context you have to re-paste.

Before you start

You need a completed playbook. Run the full 9-decision flow first. A Quick Take takes about 2 minutes; the full playbook 15 to 20 minutes. The export needs the prior 8 decisions locked, because those decisions are what the instruction file is made of: who pays, what hurts, what is in V1, how you charge, and how you launch.

You also need Claude Code installed and a repo to work in.

Step by step

1. Finish the playbook and reach the export step. The export is the final decision of the 9. Pick Claude Code as a target. ShipFit turns your validated decisions into a project instruction file in the format Claude Code reads, i.e. CLAUDE.md at the repo root (some setups also use an AGENTS.md). It reads as plain build instructions, not a data dump.

2. Commit the file to the repo root. Place CLAUDE.md at the top level of the project and commit it. Claude Code picks up project instructions on session start from the working directory, so the root is where it looks first.

3. Start a session in the project directory. Open Claude Code in the repo. The instruction file loads automatically. Read it once so you know what the agent now knows: the buyer persona, the above-the-line pains, the V1 feature cut, and the pricing model, all in prose the agent treats as standing direction.

4. Smoke-test the instructions. Ask the agent: “Summarize who this is for and what we are building first.” If it answers with your validated buyer and your V1 scope, the file is loading. If the answer is generic, the file is in the wrong directory or you started the session somewhere else.

5. Separate validation from engineering conventions. Keep the validated decisions (buyer, scope, pricing) in their own section and your engineering rules (test command, directory layout, commit style) in another. Re-exporting after a pivot refreshes the validation section and leaves your engineering section alone.

6. Build against the scope. Now ask the agent to build. Because the V1 scope is in its instructions, it builds the validated cut first and should flag scope creep when you ask for a V2 feature. Ask for “an analytics dashboard,” and a correctly instructed agent checks whether that was in V1 before it starts writing.

Keeping it in sync

Re-run the export after any meaningful pivot, e.g. a new buyer or a new pricing model, and commit the refreshed file. Because it lives in the repo, the instruction file is versioned with your code, so you can see exactly when the validated direction changed. A stale CLAUDE.md quietly steers the agent toward a product you no longer intend to build.

For the product-side view of what the export contains and how Claude Code consumes it, see the Claude Code integration page. This guide covers the steps; that page covers the mechanics.

Common mistakes

• Hand-writing CLAUDE.md from your gut. You can write the file yourself, but then it encodes assumptions rather than validated decisions. The point of exporting is that the buyer and scope cleared the 9 forced decisions (roughly 1 in 4 ideas is killed in that flow) before they became build instructions.

• Starting the session in the wrong directory. Claude Code reads project instructions from the working directory. Launch it from the repo root, then smoke-test.

• Never re-exporting. Pivot without refreshing the file and the agent keeps building the old plan. Re-export on every pivot and commit it.

• Expecting the agent to validate the idea. Claude Code builds; it does not test demand. Validation happens upstream. If you have not run a playbook yet, see pricing (free tier includes 3 credits a month, paid playbooks from $5).