Cascade Guide

Cascade is a task-collaboration interface rather than simply another chat panel. Its supported code/chat modes, terminal, preview, MCP, search and checkpoint tools can connect explanations with reviewable engineering changes.

#Where it helps

Examples include tracing authentication before fixing a related bug, diagnosing build/runtime errors, adding a specific page or loading state, or integrating an API. These tasks have a clear goal, a reviewable change and observable acceptance criteria.

#Expose the understanding first

1. Explain the current state.
2. List a plan.
3. Identify affected files.
4. Implement once the scope is understood and authorized.

textCopy
Add a billing settings page.
First explain the current settings flow.
Then list the files you plan to change.
Do not edit until I can review the plan.

This example makes assumptions about existing APIs, public props and folder structure visible before they become code.

#Supply precise context

Use @Files for known key files, @Code for a function or class, and @Terminal for current errors or test output where those features are supported. The aim is to narrow attention, especially in large repositories—not to supply everything indiscriminately.

#Tasks needing more definition

Undefined requirements, sensitive security/infrastructure changes and requests to “optimize the entire project” need a bounded plan and acceptance criteria first.

The ability to split work determines how useful the tool becomes. Clear engineering tasks make collaboration faster; broad untestable requests create expensive review work.

#Related pages

• Windsurf setup
• Autocomplete guide
• Windsurf overview