From Validated Idea to Windsurf Project

To turn a ShipFit playbook into a Windsurf project, export your validated decisions into Windsurf’s rules file (.windsurfrules), place it in the repo root, and reopen the project so Cascade loads it. The Cascade agent then has your buyer, V1 scope, and pricing in context for every conversation, so its multi-file diffs build the validated product instead of a plausible guess.

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 depends on the prior 8 decisions being locked, because that is what populates the rules: your buyer, your above-the-line pains, your V1 cut, and your pricing model.

You also need Windsurf installed and a project folder to work in.

Step by step

1. Finish the playbook and reach the export step. The export is the last of the 9 decisions. Pick Windsurf as a target (you can select multiple tools at once). ShipFit packages your validated decisions into Windsurf’s rules format, i.e. a .windsurfrules file that Cascade reads as standing context.

2. Place the file in the repo root. Drop .windsurfrules at the top level of the project. Windsurf reads project rules on session start, so the root is where Cascade looks. A rules file buried in a subfolder will not load.

3. Reopen the project in Windsurf. Project rules load on session start, so reopening the folder guarantees the new context is active. Open the rules file and read it once. You should see your buyer persona, your V1 feature cut, and your pricing model in plain language.

4. Smoke-test Cascade. In a new Cascade conversation, ask: “Who is this for and what is in V1?” If Cascade answers with your validated buyer and V1 scope, the rules are loading. A generic answer means the file is misplaced or the project was not reopened.

5. Keep validation and engineering rules apart. Put validated decisions (buyer, scope, pricing) in one section and engineering conventions (test framework, file layout, linting) in another. Re-exporting after a pivot refreshes the validation section and leaves your engineering section in place.

6. Build against the scope. Cascade is aggressive about large, multi-file changes, which is exactly when scope discipline matters most. With the V1 scope in its rules, Cascade builds the validated cut first and should flag when a request belongs in V2. Ask it to “rebuild the whole onboarding flow,” and a well-scoped project keeps that rebuild inside the V1 boundary instead of quietly shipping features you parked.

Keeping it in sync

Re-run the export after any meaningful pivot, e.g. a new buyer segment or a new pricing model. The repo’s .windsurfrules should always match your current validated state. Because Cascade ships big diffs fast, a stale rules file does real damage quickly: it can rebuild large surfaces against decisions you have already dropped.

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

Common mistakes

• Writing .windsurfrules by hand. You can author the file yourself, but then it carries assumptions rather than validated decisions. The value is that the buyer and scope survived the 9 forced decisions (roughly 1 in 4 ideas is killed in that flow) before reaching Cascade.

• Wrong file location. Rules outside the root that Windsurf does not scan never load. Root, reopen, then smoke-test.

• Letting the rules drift. Pivot without re-exporting and Cascade rebuilds against the old plan, fast. Re-export on every pivot.

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