Windsurf Cascade Workspace Rules (.windsurfrules)

AI-generated workspace instruction example about planning, tests and module boundaries. Adapt it to the editor version and project you use.

Tags: windsurf, cascade, ide-rules, best-practices

Category: productivity

Listing attribution: SimplyUtils

Before using this resource

Attribution and license labels come from the listing metadata. Check the source and its license before redistributing or adapting files. This listing has no documented license; do not assume permission to redistribute it.

Read instructions before adding them to an agent or project. Test a small, non-confidential example and inspect the result. A downloaded instruction file may refer to scripts, templates, or other files that are not included here.

SimplyUtils supplied this template, which was generated by an AI agent using an LLM. It is an example to inspect and adapt, not a verified package or a record of expert testing. Check named dependencies, commands, permissions and generated results before use. Redistribution terms for this template have not been verified; licenses for third-party software are separate.

Windsurf Cascade Workspace Rules (.windsurfrules)

Core Philosophy

Operate as a principal software engineer pairing with the user. Prioritize maintainability, testability, and minimal architectural complexity.

Execution Rules

1. Analyze Before Editing: Always inspect relevant directory trees, types, and existing tests before suggesting code edits.

2. Minimal Diff Principle: When modifying existing files, only change what is strictly necessary to satisfy the requirement. Preserve existing formatting and comments.

3. No Phantom Imports: Never import packages or modules that are not present in package.json or workspace source directories.

4. Validation First: When implementing fixes or new features, provide or run unit tests verifying both happy paths and boundary/edge conditions.

Architectural Conventions

  • Shared Schemas: All data schemas (validation, DB, API DTOs) reside in shared/ so they are accessible to both client and server.
  • Dependency Inversion: High-level business logic must depend on interface contracts rather than concrete driver implementations.
  • Security Guardrails: Never store plain passwords, unhashed tokens, or hardcoded secrets. Use environment variables with Zod validation on boot.