There are two mechanisms for Memory in Windsurf: Memories, which can be automatically generated by Cascade, and rules, which are manually defined by the user at both the local and global levels.
Cascade will save memory itself, we can also prompt Cascade to “create a memory of …”.
Rules has global level and workspace level.
Sample rules of front end:
# General Code Style & Formatting
- Follow the Airbnb Style Guide for code formatting.
- Use PascalCase for React component file names (e.g., UserCard.tsx, not user-card.tsx).
- Prefer named exports for components.
# Project Structure & Architecture
- Follow Next.js patterns and use the App Router.
- Correctly determine when to use server vs. client components in Next.js.
# Styling & UI
- Use Tailwind CSS for styling.
- Use Shadcn UI for components.
# Data Fetching & Forms
- Use TanStack Query (react-query) for frontend data fetching.
- Use React Hook Form for form handling.
- Use Zod for validation.
# State Management & Logic
- Use React Context for state management.
# Backend & Database
Use Prisma for database access.
Another front end typescript rule:
# General Code Style & Formatting
- Use English for all code and documentation.
- Always declare the type of each variable and function (parameters and return value).
- Avoid using any.
- Create necessary types.
- Use JSDoc to document public classes and methods.
- Don't leave blank lines within a function.
- One export per file.
# Naming Conventions
- Use PascalCase for classes.
- Use camelCase for variables, functions, and methods.
- Use kebab-case for file and directory names.
- Use UPPERCASE for environment variables.
- Avoid magic numbers and define constants.
# Functions & Logic
- Keep functions short and single-purpose (<20 lines).
- Avoid deeply nested blocks by:
- Using early returns.
- Extracting logic into utility functions.
- Use higher-order functions (map, filter, reduce) to simplify logic.
- Use arrow functions for simple cases (<3 instructions), named functions otherwise.
- Use default parameter values instead of null/undefined checks.
- Use RO-RO (Receive Object, Return Object) for passing and returning multiple parameters.
# Data Handling
- Avoid excessive use of primitive types; encapsulate data in composite types.
- Avoid placing validation inside functions—use classes with internal validation instead.
- Prefer immutability for data:
- Use readonly for immutable properties.
- Use as const for literals that never change.
Data Science and ML Python rules
- You are a PyTorch ML engineer
- Use type hints consistently
- Optimize for readability over premature optimization
- Write modular code, using separate files for models, data loading, training, and evaluation
- Follow PEP8 style guide for Python code
- You are a data scientist who specializes in Python-based data science and machine learning
- Use Python 3 as the primary programming language
- Use PyTorch for deep learning and neural networks
- Use NumPy for numerical computing and array operations
- Use Pandas for data manipulation and analysis
- Use Jupyter for interactive development and visualization
- Use Conda for environment and package management
- Use Matplotlib for data visualization and plotting
Finally some general rules
-# Core System Components
- The main application logic is in src/core.
- Shared utilities and helpers are in src/utils.
- Feature flags and configuration settings are in src/config.
# Cascade
- Cascade's backend logic is in server/cascade_engine.
- All API request handlers for Cascade are in server/cascade_api.
- Cascade's task execution queue is managed in server/cascade_tasks/queue.py.
# Frontend Code Structure
- The UI components for the assistant are in frontend/components/assistant.
- The AI command panel logic is handled in frontend/components/command_panel.tsx.
- Styles for the AI interface are in frontend/styles/assistant.css.
# Data & Storage
- Vector embeddings are stored in server/data/vector_store.
- User session history is saved in server/data/sessions.
- Logs and analytics are collected in server/logs/usage_tracking.log.
# Testing & Debugging
- End-to-end tests for Cascade are in tests/e2e/cascade_tests.
- Mock API responses for local testing are in tests/mocks/api_mocks.py.
- Debugging scripts are located in scripts/debugging_tools.
Workflows enable users to define a series of steps to guide Cascade through a repetitive set of tasks, such as deploying a service or responding to PR comments. These Workflows are saved as markdown files, allowing users and their teams an easy repeatable way to run key processes. Once saved, Workflows can be invoked in Cascade via a slash command with the format of /[name-of-workflow], Upon invocation, Cascade sequentially processes each step defined in the workflow. For example

I can also ask Cascade to generate Workflows, especially the steps to push commit in platform deployment.
MCP was elaborated in previous blog.