Best PromptsWindsurf Rules Template
A workspace rules file for Windsurf and Cascade: stack facts, verification commands, and the boundaries the agent must not cross.
# Project rules [ONE SENTENCE: what this project is and who uses it.] ## Stack - [FRAMEWORK + VERSION] - [LANGUAGE + STRICTNESS, e.g. "TypeScript, strict mode"] - [DATABASE / ORM] - Package manager: [pnpm / npm / uv / cargo]. Use it; do not switch. ## Commands - Install: `[COMMAND]` - Dev: `[COMMAND]` - Typecheck: `[COMMAND]` - Test: `[COMMAND]` (single file: `[COMMAND] path/to/file`) - Lint: `[COMMAND]` Run typecheck and the tests covering your change before saying the work is done. If you cannot run them, say so explicitly rather than implying they passed. ## How to work here - Read the existing code in the area you are changing before writing. Match its patterns for naming, error handling, imports, and file layout. - Prefer editing an existing file over creating a new one. - Make the smallest change that solves the problem. Do not refactor code you were not asked to touch, and do not fix unrelated lint warnings in the same change. - When a task is ambiguous in a way that changes the design, ask one specific question rather than choosing silently. ## Conventions - [e.g. "All data access goes through lib/db. Components never query directly."] - [e.g. "Server components by default; add 'use client' only for interactivity."] - [e.g. "Errors: throw typed errors from the domain layer, format them at the edge."] - [ANY DOMAIN VOCABULARY: the terms this codebase uses and what they mean.] ## Do not - Do not add dependencies without asking first. - Do not edit: [GENERATED FILES, MIGRATIONS, LOCKFILES]. - Do not commit, push, or open pull requests unless asked. - Do not write to [PROTECTED PATHS, e.g. infra/, .env files]. ## Where things live - `[DIR]`: [what it holds] - `[DIR]`: [what it holds] - Deeper docs, read only when the task touches them: `docs/[X].md` ([one line on what it covers])
How to use
Save as .windsurf/rules/project.md, or paste into Windsurf Settings for global rules. Keep it under roughly 60 lines: every rule competes for attention with your actual task, and a long rules file is followed less reliably than a short one. The commands block is the highest-value section, since an agent that cannot run your tests cannot verify anything and will fall back to claiming success. Never duplicate rules your linter already enforces.
More agent prompts
You are a software engineering agent working in the [PRODUCT/TEAM] codebase ([LANGUAGE/STACK]). Your objective is to take an assigned task from description to verified, working code. You may read and modify anything in the repository; you do not push, merge, deploy, or alter CI configuration unless the task explicitly says to. # Operatin
Coding Agent System Prompt
Autonomous coding agent that matches repo conventions, proves work with passing tests before claiming done, and reports failures truthfully.
You are a debugging agent for the [PRODUCT] codebase. Your objective is to find the root cause of a reported bug, fix it with the smallest possible change, and prove the fix. You are not here to refactor, harden, or improve unrelated code: a debugging session that ends in a 40-file diff has failed even if the bug is gone. # Reproduce Bef
Debugging Agent System Prompt
Root-cause-first debugging agent: no fix until the bug is reproduced, minimal diffs only, and done means the repro dies while the test suite stays green.
You are a code migration agent. Your objective is to move the [PRODUCT] codebase from [SOURCE VERSION/FRAMEWORK] to [TARGET VERSION/FRAMEWORK] while preserving behavior exactly. You are a mechanical translator with judgment, not a redesigner: the product must work the same after every step you take. # The Prime Rule: Migration Changes On
Code Migration Agent System Prompt
Framework-upgrade agent that migrates in build-green slices, verifies every codemod, follows official guides over memory, and never mixes in behavior changes.