From Validated Idea to a Gemini Build

To turn a ShipFit playbook into a Gemini build, export your validated decisions as an AGENTS.md file, drop it in your repo root, and open the project in Gemini or Antigravity. The agent reads AGENTS.md as standing context, so it has your buyer, V1 scope, and pricing on every prompt and builds what you validated, not what it guesses.

Before you start

You need a finished playbook. Run the full 9-decision flow first (a Quick Take takes about 2 minutes, the full playbook 15 to 20 minutes). The export only works once the prior 8 decisions are locked, because that is what fills AGENTS.md with real content: your buyer, your above-the-line pains, your V1 cut, and your pricing model.

You also need a repo (empty is fine) and access to Gemini or Antigravity, which read an AGENTS.md file at the project root as persistent agent instructions.

Step by step

1. Finish the playbook and reach the export step. The export is the last of the 9 decisions. Pick Gemini as a target (you can pick more than one tool at once). ShipFit packages your validated decisions into an AGENTS.md file.

2. Drop AGENTS.md in your repo root. The agent reads it from the root, alongside package.json or your equivalent. Location matters: an AGENTS.md in the root gets picked up as standing context, while a doc buried in a subfolder does not.

3. Open the project in Gemini or Antigravity. Once the project loads, the agent treats AGENTS.md as instructions for the whole session. Open the file and read it once. You should see your buyer persona, the V1 feature cut, and the pricing model in plain language.

4. Smoke-test the context. In a new chat, ask: “Who is this product for and what is in V1?” If the agent answers with your validated buyer and your V1 scope rather than a generic guess, AGENTS.md is loading. If the answer is vague, the file is in the wrong place or the session predates it.

5. Keep validation and engineering separate. Hold validation context (buyer, scope, pricing) in its own section, apart from engineering rules (test framework, file layout, linting). When you re-export after a pivot, the validation section refreshes and your engineering section stays untouched.

6. Build against the scope. Now when you ask for a feature, the agent already knows whether it is in V1 or parked. Ask “let’s add team billing,” and a well-scoped project should push back if billing was cut. That pushback is the point: the MVP scope decision survives into the agent instead of dying in a doc.

Keeping it in sync

Re-run the export after any meaningful pivot, e.g. a new buyer segment or a changed pricing model. The repo’s AGENTS.md should always match your current validated state. A stale file is worse than none, because the agent will confidently build against decisions you have already abandoned.

For the product-side detail on what the export contains and how Gemini and Antigravity consume AGENTS.md, see the Gemini integration page. This guide is the how-to; that page is the what-and-why.

Common mistakes

• Writing AGENTS.md by hand. You can hand-write the file, but then it carries your assumptions, not validated decisions. The whole value is that the buyer and scope survived the 9 forced decisions (roughly 1 in 4 ideas gets killed in that flow) before they reached the agent.

• Putting the file in the wrong place. An AGENTS.md the agent does not scan will silently never load. Root, then open the project, then smoke-test.

• Letting the file go stale. If you pivot and do not re-export, the agent keeps building the old product. Re-export on every pivot.

• Treating Gemini as the validator. Gemini and Antigravity build; they do not validate. The validation happens upstream in the playbook. If you have not done that work, see pricing to start (the free tier includes 3 credits a month, paid playbooks from $5).