Windsurf Rules

gistfile1.txt

**Project Approach**

* Always check for a PRD (Product Requirements Document) before starting a new task and follow it closely
* Look for comprehensive project documentation to understand requirements before making changes
* Focus only on code areas relevant to the assigned task
* Prefer iterating on existing code rather than creating new solutions
* Keep solutions simple and avoid introducing unnecessary complexity

**Code Quality**

* Keep files under 300 lines of code; refactor when approaching this limit
* Maintain a clean, organized codebase
* Avoid code duplication by checking for similar existing functionality
* Write thorough tests for all major functionality
* Consider different environments (dev, test, prod) when writing code
* Unless explicitly instructed, instead of trying to gracefully handle an error or failure, make sure to fix the underlying issue.

**Development Workflow**

* Kill all related running servers before starting a new one
* Always start a new server after making changes to allow for testing
* Make only requested changes or changes you're confident are well understood
* Consider what other code areas might be affected by your changes
* Don't drastically change existing patterns without explicit instruction

**Version Control**

* Never leave unstaged/untracked files after committing to git
* Don't create new branches unless explicitly requested
* Never commit .env files to version control
* Never overwrite .env files without first asking and confirming

**Best Practices**

* Avoid writing one-time scripts in permanent files
* Don't mock data except for tests (never for dev or prod environments)
* Exhaust all options using existing implementations before introducing new patterns
* If introducing a new pattern to replace an old one, remove the old implementation

These are very good. And I'd offer a suggestion. If the goal is for Cascade to behave like a human junior programmer, this is fine.
However, there are merits to accessing the latent intelligence in every LLM.
Instead of specific behaviors (don't make this or that mistake), tap into this creativity.
It's because LLMs already know how to be good junior programmers.
And they are heavily trained to be brief and uninteresting.
And to make matters worse, they are trained to code eagerly.
They don't need our help being average.
What works for me is to ask Cascade to write the PRD.
And then launch a second session and ask that Cascade to make it better.
Then go back to the first session.
Rinse and Repeat.
Then build.
Test.
Ship.
Support (ha!).

Interesting, how does this work with new and extra eager sonnet 3.7…? I’m having hard time taming it..

Hi CREWorx, I faced similar challenges with 3.7. So far, I've have had good luck with the use of memories and in-progress markdown files (supplemental memory). My key pain has been forgetfulness ... so I steer it back to the documents to help it recall earlier decisions and insights.
Another method I've tried is to have it search the web and then tell me why it might disregard what it has found. Kind of a mini-RAG / ReACT approach.

Needed to hear this approach right now. 3.7 took me on a wild ride for a couple weeks because of it's eagerness so badly I had to start another project from scratch because it left me in a dead end. It was super creative to be sure but a bit like a drinking coding buddy who was doing perfectly fine then overdid it and became an amnesic blackout drunk. @jackccrawford how do you provide the supplemental memory?

... @jackccrawford how do you provide the supplemental memory? - @owenlawlor117
Think of Windsurf Cascade memories in a number of categories:
1 - Cascade memories. Available in the "Memories Panel". They are editable and deletable. They are created when Cascades decides, or when you ask Cascade to create one. They are only persistent in a single Windsurf or Windsurf-Next install since they are stored in local encrypted files (they don't move from one computer to another).
2 - Databases you might write to directly and ask Cascade to retrieve for you.
3 - MD files you ask Cascade to write to disk in the opened folder. They will be semantically indexed by Windsurf. THIS is MY best memory option.
4 - Session history - after very long sessions (uses local computer memory), the chat window can get very sluggish. At that point, I ask Cascade to write a prompt to handoff to another AI session. It works pretty well.
5 - Pasting in content to the chat interface. This put all of it into the context window.
6 - Ask Cascade to read a file. But Cascade will only read about 200 lines of the file at a time, sometimes leaving important parts out. The strategy for this approach is to put the important stuff at the beginning of the file.

I know this is quite a lot, but that's what I do with what we get from Windsurf.