Windsurf Prompt Templates (2026)

GOAL: Implement [FEATURE_NAME] so that [USER_OUTCOME].

CONTEXT (read first):
@file [PATH/TO/PRIMARY_FILE]
@folder [PATH/TO/RELATED_DIR]
@codebase [PLAIN_ENGLISH_DESCRIPTION_OF_WHERE_THIS_LIVES]
@docs [LIBRARY_OR_FRAMEWORK_NAME]

SCOPE:
- Only modify files under [ALLOWED_PATHS]. Do NOT touch [DO_NOT_TOUCH_PATHS] or unrelated files.
- Match the existing patterns for [NAMING / ERROR_HANDLING / STYLE].

ACCEPTANCE CRITERIA (done when all true):
- [OBSERVABLE_BEHAVIOR_1]
- [OBSERVABLE_BEHAVIOR_2]
- `[TEST_OR_BUILD_COMMAND]` passes with no new failures or type errors.

PROCESS:
1. Propose a short plan and list the files you will change. Wait for my OK.
2. Implement, then run `[TEST_OR_BUILD_COMMAND]` and fix anything it reports.
3. Show me the per-file diff and a one-line summary of each change.

Create a new [FRAMEWORK] component named [COMPONENT_NAME] at [PATH/TO/COMPONENT].

Requirements:
- Props: [PROP_1: TYPE], [PROP_2: TYPE], [PROP_3: TYPE].
- Behavior: [WHAT_IT_RENDERS_AND_DOES].
- Match the structure and styling conventions in @file [PATH/TO/EXISTING_SIMILAR_COMPONENT].
- Add types/prop-types and a minimal usage example in a comment.

Do not wire it into any page yet and do not modify other files.
When done, list the exported names and the file path.

Implement the spec described in @file [PATH/TO/SPEC.md].

Treat that file as the source of truth. Before coding:
- Restate the spec as a checklist of acceptance criteria.
- List every file you expect to create or edit under [ALLOWED_PATHS].
- Flag anything in the spec that is ambiguous or conflicts with @file [PATH/TO/EXISTING_CODE].

Then implement it, run `[TEST_COMMAND]`, and iterate until the checklist is fully satisfied. Do not add features that are not in the spec.

I hit this error. Find the root cause before proposing a fix.

@terminal
@file [PATH/TO/FILE_IN_THE_STACK_TRACE]
@codebase [WHAT_THE_FAILING_FEATURE_DOES]

Symptom: [WHAT_YOU_EXPECTED] but [WHAT_ACTUALLY_HAPPENS].
Trigger: [STEPS_OR_COMMAND_THAT_PRODUCES_IT].

First explain the root cause in 2-3 sentences and which line is responsible.
Do NOT edit anything yet — wait for me to confirm the diagnosis.

Fix the bug where [BUG_DESCRIPTION].

Step 1 — Reproduce: write a failing test at [PATH/TO/TEST_FILE] that captures the wrong behavior ([INPUT] should give [EXPECTED] but gives [ACTUAL]). Run it and show me it fails for the right reason.

Step 2 — Fix: change only what is needed in @file [PATH/TO/SUSPECT_FILE] to make that test pass. Do not touch unrelated files.

Step 3 — Verify: run `[TEST_COMMAND]` (the full suite) and confirm nothing else broke. Show the diff.

Trace how [DATA_OR_VALUE] flows from [ENTRY_POINT] to [WHERE_IT_GOES_WRONG]. Read-only — do not change any code.

@codebase [FEATURE_OR_MODULE_NAME]
@function [FUNCTION_OR_SYMBOL_NAME]

For each hop, list: the file and line, what transforms the value, and any place it could become [WRONG_STATE: null / undefined / stale / duplicated].
End with the single most likely point of failure and why.

Refactor [WHAT: FUNCTION / MODULE / FILE] in @file [PATH/TO/FILE] to improve [READABILITY / DUPLICATION / NAMING / STRUCTURE].

Hard constraint: NO behavior change. Public API, inputs, and outputs stay identical.

Before starting, run `[TEST_COMMAND]` and confirm the suite is green.
After each change, run it again. If any test fails, revert that step.
Do not modify [DO_NOT_TOUCH_PATHS]. Show the diff and explain what improved and why it is behavior-preserving.

@file [PATH/TO/BIG_FILE] is too large / mixes concerns. Split it.

Extract [WHAT: the X logic / the Y helpers] into [NEW_PATH]. Keep [WHAT_STAYS] in the original.
Update all imports across the repo so nothing breaks — use @codebase to find every reference.

Constraints: no behavior change, no new dependencies, keep public exports working. Run `[TEST_COMMAND]` after and show the file-by-file diff.

Rename [OLD_NAME] to [NEW_NAME] everywhere it applies.

@codebase [OLD_NAME]

Cover: definitions, all usages, imports/exports, [OPTIONAL: strings, config keys, docs, test names]. Do NOT rename unrelated identifiers that merely contain the substring — only the intended [FUNCTION / CLASS / VARIABLE / FILE].

List every file you will change first. After renaming, run `[TEST_OR_TYPECHECK_COMMAND]` to confirm nothing dangles.

Write unit tests for @function [FUNCTION_OR_SYMBOL_NAME] in @file [PATH/TO/FILE].

Use [TEST_FRAMEWORK] and follow the patterns in @file [PATH/TO/EXISTING_TEST].
Cover: the happy path, [EDGE_CASE_1], [EDGE_CASE_2], and error/invalid input.
Put them at [PATH/TO/NEW_TEST_FILE].

Then run `[TEST_COMMAND]` and paste the results. If any fail, decide whether the test or the code is wrong, explain which, and fix accordingly.

Find the biggest test-coverage gaps in [PATH/TO/MODULE] and close them.

@folder [PATH/TO/MODULE]
@terminal   (I just ran the coverage report above)

List the untested branches/functions ranked by risk. Then write tests for the top [N] using [TEST_FRAMEWORK], run `[TEST_COMMAND]`, and report the new coverage. Do not change production code except to fix a genuine bug the new tests expose — flag any such bug separately.

We just fixed [BUG_DESCRIPTION] in @git (see the recent diff). Add a regression test so it can never silently return.

Write a test at [PATH/TO/TEST_FILE] that fails on the OLD behavior and passes on the current fix. Name it clearly for [BUG_ID_OR_DESCRIPTION].
Run `[TEST_COMMAND]` to confirm it passes now, then briefly confirm it would have caught the original bug.

Review my uncommitted changes as a senior reviewer. Read-only — do not edit.

@git

For each issue give: file:line, severity ([blocker / warning / nit]), the problem, and a concrete fix. Check specifically for: [BUGS / EDGE_CASES], [ERROR_HANDLING], [NAMING / READABILITY], [PERFORMANCE], and anything that violates our rules in @file [PATH/TO/.windsurfrules]. End with a go / no-go verdict.

Do a focused security review of @git (or @folder [PATH/TO/AREA]). Read-only.

Check for: injection ([SQL / command / XSS]), missing authn/authz on [ENDPOINTS_OR_ACTIONS], secrets or keys committed in code, unsafe deserialization, unvalidated [USER_INPUT], and insecure defaults.
For each finding: severity, exact location, exploit scenario in one line, and the minimal fix. Ignore style; security only.

Read my staged changes and draft release text.

@git

1. A [CONVENTIONAL_COMMITS?] commit message: a <=72-char subject plus a body explaining WHAT and WHY.
2. A PR description with sections: Summary, Changes, How to test, Risk/rollback, [LINKED_ISSUE].

Keep it factual to the diff — do not invent changes that are not there. Do not modify any code.

---
trigger: [always_on | manual | model_decision | glob]
# if trigger is glob:
globs: [PATTERN, e.g. src/**/*.ts]
# if trigger is model_decision, describe when to load:
description: [WHEN CASCADE SHOULD APPLY THIS RULE]
---

# [RULE_TITLE, e.g. TypeScript conventions]

- Language / framework: [STACK].
- Style: [FORMATTER / LINT RULES]; never [BANNED_PATTERN].
- Errors: [HOW ERRORS ARE HANDLED].
- Tests: put tests in [PATH]; run `[TEST_COMMAND]` before claiming done.
- Do not touch: [PROTECTED_PATHS].
- When unsure which files matter, use @codebase first.

---
description: [ONE LINE: what this workflow does, e.g. set up, test, and open a PR]
---

# /[workflow-name]

Follow these steps in order. Stop and report if any step fails.

1. [STEP_1, e.g. run `npm install` and `npm run build`].
2. [STEP_2, e.g. run `[TEST_COMMAND]`; if red, fix and re-run].
3. [STEP_3, e.g. update @file [CHANGELOG_PATH] with a one-line entry].
4. [STEP_4, e.g. draft a commit message from @git and show it].

Do not modify [PROTECTED_PATHS]. Summarize what you did at the end.

Create a memory: [SINGLE DURABLE FACT ABOUT THIS PROJECT].

Examples of the shape to fill in:
- "This project uses [PACKAGE_MANAGER]; the test command is `[TEST_COMMAND]`."
- "[MODULE] must never import from [OTHER_MODULE]."
- "Deploys go through [PROCESS]; never edit [GENERATED_PATH] by hand."

Keep it to one or two sentences so it stays cheap to load every session.