From Validated Idea to Cursor Project

To turn a ShipFit playbook into a working Cursor project, export your validated decisions as Cursor project rules, drop them in the repo root, restart Cursor, and confirm the rules load. The editor then has your buyer, V1 scope, and pricing in context on every prompt, so it 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 the rules with real content: your buyer, your above-the-line pains, your V1 cut, and your pricing model.

You also need Cursor installed and a repo (empty is fine) to drop the files into.

Step by step

1. Finish the playbook and reach the export step. The export is the last of the 9 decisions. Pick Cursor as a target (you can pick more than one tool at once). ShipFit packages your validated decisions into Cursor’s project rules format, i.e. a .cursorrules file or a rules file under the project’s rules directory, depending on your Cursor version.

2. Drop the export in your repo root. Unzip into the root of the project, alongside package.json or your equivalent. Cursor reads project rules on session start, so the location matters: rules in the root get picked up automatically, a doc buried in /docs does not.

3. Restart Cursor and open the project. Project rules load on session start, so a fresh window guarantees the new context is live. Open the rules file and read it once. You should see your buyer persona, the V1 feature cut, and the pricing model written in plain language.

4. Smoke-test the context. In a new chat, ask: “Who is this product for and what is in V1?” If Cursor answers with your validated buyer and your V1 scope rather than a generic guess, the rules are loading. If it gives a vague answer, the file is in the wrong place or Cursor was not restarted.

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

6. Build against the scope. Now when you ask Cursor for a feature, it already knows whether that feature is in V1 or parked for V2. Ask “let’s add team billing,” and a well-scoped project should push back if billing was cut from V1. That pushback is the point: the MVP scope decision survives into the editor 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 rules should always match your current validated state. A stale rules file is worse than none, because the editor will confidently build against decisions you have already abandoned.

For the product-side detail on what the export contains and how Cursor consumes it, see the Cursor integration page. This guide is the how-to; that page is the what-and-why.

Common mistakes

• Skipping the playbook and writing rules by hand. You can hand-write a .cursorrules 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 editor.

• Putting the file in the wrong place. Rules in a subfolder Cursor does not scan will silently never load. Root, then restart, then smoke-test.

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

• Treating Cursor as the validator. Cursor builds; it does 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).