Windsurf Complete Mode Rule: Systematic Problem Solving

This article provides a production-ready Windsurf rule that implements the Complete Problem Solving framework directly in your Cascade conversations. Once installed, you can activate rigorous, multi-pass problem-solving on demand with a simple @complete-mode mention.

What This Rule Does

The Complete Mode rule transforms how Cascade approaches complex problems by:

Enforcing multi-pass discovery using different methods each pass
Requiring explicit acceptance gates before claiming completion
Mandating independent verification beyond primary proof
Maintaining a Problem Register with severity tracking
Creating an audit trail of all actions and decisions
Refusing early completion when issues remain

Installation

Step 1: Create the Rule File

Create this file in your repo:

.windsurf/rules/complete-mode.md

Step 2: Configure Activation

In the Windsurf Rules UI:

Activation Mode: Manual (primary) + optionally Model Decision
Globs: Leave blank for universal use, or add **/*.sh, **/*.ipynb for specific file types
Description (for Model Decision): "Use for end-to-end completion with explicit acceptance gates"

Step 3: Verify

Run @complete-mode in a Cascade conversation to test activation.

The Rule File

Copy this complete rule into .windsurf/rules/complete-mode.md:

# Universal Complete Problem Solving Mode

**Purpose**: Prevent early "one-and-done" fixes. Enforce multi-pass discovery, explicit acceptance gates, and an audit trail across *any* domain (software, ops, data, research/writing, product/UX, etc.).

**How to invoke (Manual)**: `@complete-mode`

**Model Decision hint (optional)**: Use when the ask implies end-to-end resolution with acceptance criteria or "find all causes / fix in order."

**Quick use steps (mid-thread)**

1. Call: `@complete-mode`  
2. Paste **Task** and **Context** (one or two lines each).  
3. Paste **one** of the **DONE overlays** (below) for your domain.  
4. (Optional) Add **toggles** like `scope:… depth:… risk_tolerance:… strict:on`.  
5. Let the loop run until **all gates** are proven *in-message*.

---

## Re-anchor — Universal Complete Problem Solving Mode

**Task** = `<what we're doing, in one sentence>`  
**Context** = `<where/who this affects; constraints/tools available>`

### Definition of DONE (Acceptance Gates — all required)

- **Objective met**: `<measurable outcome>`
- **Independent validation**: `<how to verify externally or by a second method>`
- **Zero criticals**: Problem Register has 0 P0/P1 items remaining (P2 allowed only with rationale)
- **Evidence pack**: attach links/snippets/artifacts with timestamps sufficient for audit/replay

### Operating Loop (repeat until DONE)

1. **Discover** → Append to **Problem Register** (ID, Severity P0–P2, Category, Evidence, Root Cause, Dependencies, Proposed Action, Confidence).  
2. **Plan** → Order by dependency/impact; select minimal, reversible next actions.  
3. **Execute** → Apply the action(s); capture exact commands/steps/decisions (diffs where applicable).  
4. **Verify (Primary)** → Show direct proof against the objective (metrics/logs/tests/results/screenshots/links).  
5. **Verify (Independent)** → Corroborate via a *different* method/source (alternate dataset/monitor, stakeholder confirmation, replication, counterfactual/simulation).  
6. **Re-scan** → Run a NEW discovery pass using at least **two different methods** than last pass (e.g., log analysis, static review, sampling, experiment, stakeholder interview, contract/spec reading, control-run/simulation).  
7. **Update Registers** → Mark statuses; add new items if found. **Do not claim DONE** unless all gates are satisfied.

### Registers & Outputs (strict)

- **Problem Register**: running list with statuses (Resolved / Partial / Blocked + explicit blocker).  
- **Action Log**: exact diffs/changes or decision notes, with before/after metrics.  
- **Final Status**: DONE or NOT DONE; if not, list blockers + next concrete steps.  
- **What to Watch**: residual risks (1–5 bullets) + monitoring plan.

### Anti-Shortcuts

- If only one issue is found in a pass, perform at least **two more** discovery passes before claiming DONE.  
- If access is missing (e.g., private logs, legal doc), state the **exact ask** and continue narrowing with what you have.  
- Never restate generic tips; every claim must be tied to **evidence or a cited source**.

### Mode Toggles (inline, anytime)

- `scope:<area>` (e.g., `scope:runtime` \| `scope:policy` \| `scope:analysis` \| `scope:ux`)  
- `depth:shallow|normal|deep`  
- `risk_tolerance:low|med|high`  
- `max_actions:<n>`  
- `strict:on` (refuse to claim success without all gates)

---

## Problem Register & Action Log templates

**Problem Register (copy once; keep updating):**

| ID | Sev | Category | Evidence (short) | Root Cause | Proposed Action | Status | Confidence |
| ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| P-01 | P0 |  | `<signal/log/metric>` |  |  | Resolved/Partial/Blocked | 0.0–1.0 |

**Action Log (append per pass):**

### Pass N — Action Log

- Change: `<diff/ref/command>`  
- Before → After: `<metric/log/test summary>`  
- Verification (Primary):  
- Verification (Independent):  
- New signals found? `<yes/no + notes>`

**Final Status stub:**

**FINAL STATUS:** DONE ✅ (all gates satisfied)  
**WHAT TO WATCH:** `<3–5 bullets>`  
**FOLLOW-UPS:** `<debt items, next iteration>`

---

## DONE overlay — Software/DevOps

Use for services, deploys, infra work.

- **Cloud health**: primary endpoint (e.g., `/healthz`) returns **200** for **≥30 minutes**; process has **0 unexpected restarts**.  
- **Logs clean**: last **2 minutes** of runtime logs show **no errors above INFO**.  
- **Local gates**: build **+** tests **+** type/lint pass with **0 failures**.  
- **Zero criticals**: Problem Register has 0 P0/P1 remaining.  
- **Evidence pack**: health URL/link/screenshot, log excerpt, test summary, commit/PR refs.

**Suggested toggles**: `scope:start-command`, `scope:db-migrations`, `scope:config`, `depth:deep`, `risk_tolerance:low`.

---

## DONE overlay — Data/Analytics

Use for analyses, pipelines, experiments.

- **Objective met**: target metric achieved (state exact threshold/OKR).  
- **Statistical validity**: effect validated (e.g., **p < 0.05** or CI excludes 0); sample sizes adequate.  
- **Reproducibility**: notebook/script + **dataset hash/snapshot** provided; re-run reproduces result.  
- **Zero criticals**: Problem Register has 0 P0/P1 remaining.  
- **Evidence pack**: plots/tables, stats summary, code path + data hash, dashboard link.

**Suggested toggles**: `scope:metrics`, `scope:experiment-design`, `scope:data-quality`, `depth:deep`.

---

## DONE overlay — Research/Writing

Use for briefs, memos, docs.

- **Claims supported**: ≥ **3 primary/authoritative sources** for key assertions; **quotes + citations** included.  
- **Counterevidence**: major counterarguments identified and addressed or scoped with rationale.  
- **Clarity/completeness**: executive summary + key takeaways + limitations present.  
- **Zero criticals**: Problem Register has 0 P0/P1 remaining (e.g., unverified claim = P1).  
- **Evidence pack**: bibliography with links, quoted snippets, notes on source reliability.

**Suggested toggles**: `scope:citations`, `scope:counterarguments`, `risk_tolerance:low`.

---

## DONE overlay — Product/UX

Use for prototypes, flows, usability.

- **Ship/prototype**: interactive artifact available (link or build); core flow implemented.  
- **Usability proof**: task success rate ≥ **target** on **N** users (state target & N) *or* validated heuristic checklist.  
- **Acceptance notes**: known limitations + next iteration scope documented.  
- **Zero criticals**: Problem Register has 0 P0/P1 remaining (blocking defects, broken nav).  
- **Evidence pack**: prototype link, task metrics/notes, decision log.

**Suggested toggles**: `scope:core-flow`, `scope:accessibility`, `depth:normal`.

---

### Suggested activation settings (set in Rules UI)

- **Activation**: Manual (primary). Optionally enable Model Decision with description: "Use for end-to-end completion with explicit acceptance gates."  
- **Globs**: leave blank (universal), or add selectively per repo (e.g., `**/*.sh`, `**/*.ipynb`) if you want auto-activation on certain artifacts.

How to Use the Rule

Basic Invocation

In any Cascade conversation:

@complete-mode

Task = Fix authentication timeout on production login
Context = Next.js app, Supabase auth, seeing 504s in last hour, Vercel deployment

[DONE overlay — Software/DevOps]
- Cloud health: /api/health returns 200 for ≥30 minutes; 0 restarts
- Logs clean: last 2 minutes show no errors
- Local gates: build + tests + lint = 0 failures
- Zero criticals
- Evidence pack: health URL, log excerpt, test summary, PR ref

scope:runtime  depth:deep  strict:on

Cascade will now:

Build a Problem Register starting with the 504 errors
Execute fixes and capture exact changes
Verify with primary method (health checks)
Verify independently (user request simulation)
Re-scan using different discovery methods (application logs, metrics)
Refuse to say DONE until all gates are proven

Domain-Specific Examples

For Data Analysis:

@complete-mode

Task = Validate user retention improved after onboarding redesign
Context = 2 weeks post-launch, 5K users, have Mixpanel + database access

[DONE overlay — Data/Analytics]
- Objective met: retention >baseline by ≥5pp with `p<0.05`
- Statistical validity: adequate sample size, CI excludes 0
- Reproducibility: SQL + Mixpanel query + screenshot provided
- Zero criticals
- Evidence pack: plots, stats, queries, dashboard link

depth:deep  scope:experiment-design

For Documentation:

@complete-mode

Task = Document API authentication flow for external developers
Context = REST API, OAuth2 + API keys supported, needs examples

[DONE overlay — Research/Writing]
- Claims supported: ≥3 references (auth spec, OAuth RFC, our code)
- Counterevidence: documented common errors and fixes
- Clarity: executive summary + code examples + troubleshooting
- Zero criticals
- Evidence pack: links to specs, code snippets, test requests

scope:citations  risk_tolerance:low

Customizing for Your Team

Add Team-Specific Gates

Extend the overlays with your standards:

## DONE overlay — Our Backend Services

- All Software/DevOps gates (above)
- **Load tested**: K6 scenario passes with p95 < 200ms
- **Security**: OWASP top-10 checks pass, secrets in vault
- **Observability**: Datadog dashboard created, alerts configured
- **Documentation**: README + runbook updated

Create Project-Specific Rules

For a specific repo, add project context:

## Project Context — E-Commerce Platform

Available tools:
- CircleCI for CI/CD
- DataDog for monitoring
- LaunchDarkly for feature flags
- Stripe for payments

Critical paths:
1. Checkout flow (checkout -> payment -> confirmation)
2. Inventory sync (updates every 15 min)
3. Email notifications (transactional via SendGrid)

When issues arise, always check these first.

Adjust Severity Definitions

Tune P0/P1/P2 to your risk profile:

### Severity Levels (adjust per domain)

- **P0 (Critical)**: Production down, data loss, security breach
- **P1 (High)**: Partial outage, wrong results, broken core feature
- **P2 (Medium)**: Degraded UX, edge case, technical debt

Integration Patterns

With Existing Workflows

Pull Request Reviews:

@complete-mode
Task = Review PR #847 for database migration safety
Context = Postgres, 100M rows, zero-downtime requirement
[Use Data/Analytics overlay, add scope:migrations]

Incident Response:

@complete-mode
Task = Resolve P0: API 500s spiking in last 10 minutes
Context = Production, 5K req/min normally, now 80% errors
[Use Software/DevOps overlay, add risk_tolerance:low strict:on]

Research Spikes:

@complete-mode
Task = Evaluate GraphQL vs tRPC for new API
Context = TypeScript monorepo, team of 6, React frontend
[Use Research/Writing overlay, add depth:deep]

With Other Rules

Complete Mode stacks with other Windsurf rules:

@complete-mode @security-first
Task = Implement password reset flow
[Activates both Complete Mode + your security rule]

Troubleshooting

Issue: Cascade finishes too quickly despite strict:on

Solution: Add explicit pass requirement:

strict:on  require_passes=3  stop_reason:explain

Issue: Too verbose, drowning in detail

Solution: Adjust depth and scope:

depth:shallow  scope:runtime  max_actions:2

Issue: Can't access required verification resource

Solution: The rule handles this—state the exact blocker:

"Cannot verify production metrics—need Datadog access. 
Continued with staging metrics + manual test. 
Blocker: Prod access for final gate."

Advanced: Multiple Domain Passes

For cross-domain problems, chain overlays:

@complete-mode

Task = Launch new feature with marketing campaign
Context = Feature ready, email + social scheduled, metrics defined

Pass 1 — Technical:
[DONE overlay — Software/DevOps]
[... gates ...]

Pass 2 — Analytics:
[DONE overlay — Data/Analytics]  
[... gates for tracking validation ...]

Pass 3 — Content:
[DONE overlay — Research/Writing]
[... gates for launch copy ...]

Run all three passes sequentially, blocking on each.

Why This Works in Windsurf

Windsurf's rule system is designed for exactly this pattern:

Rules are first-class context — Cascade treats them as part of your request
Manual activation is explicit — No surprise behavior changes
Workspace-scoped — Different projects can have different overlays
Character limit is generous — 12K chars accommodates full framework
Stacks with other rules — Compose with security, style, testing rules

Measuring Impact

Track these metrics before/after adopting Complete Mode:

Issue recurrence rate: % of "fixed" issues that reappear within 2 weeks
Discovery depth: Average # of issues found per problem-solving session
Verification coverage: % of fixes with ≥2 verification methods
Time to resolution: Compare initial fix vs. actual completion
Handoff quality: Can someone else understand your solution from the registers?

Typical improvements: 60-80% reduction in recurrence, 3x more issues discovered, but 1.5-2x longer initial resolution (which saves 10x time avoiding rework).

Next Steps

Install the rule in your primary repo's .windsurf/rules/ directory
Try a low-stakes problem to get comfortable with the flow
Customize the overlays with your team's standards
Share with teammates and establish when to use Complete Mode
Collect examples of problems it caught that would have slipped through

The Complete Mode rule transforms Cascade from a helpful assistant into a systematic problem-solving partner that refuses to accept superficial solutions.

Complete Problem Solving Mode Framework — Full conceptual guide
Windsurf Rules Documentation — Official Windsurf rules guide
Problem Register Template — Copy-paste starting point
Domain-specific overlay articles (Software, Data, Research, Product)

Windsurf Complete Mode Rule: Systematic Problem Solving

Windsurf Complete Mode Rule: Systematic Problem Solving

What This Rule Does

Installation

Step 1: Create the Rule File

Step 2: Configure Activation

Step 3: Verify

The Rule File

How to Use the Rule

Basic Invocation

Domain-Specific Examples

Customizing for Your Team

Add Team-Specific Gates

Create Project-Specific Rules

Adjust Severity Definitions

Integration Patterns

With Existing Workflows

With Other Rules

Troubleshooting

Advanced: Multiple Domain Passes

Why This Works in Windsurf

Measuring Impact

Next Steps

Related Resources