Workflows は、サービスのデプロイや PR コメントへの対応といった反復作業に対し、Cascade を導くための一連の手順を定義できます。 これらの Workflows は markdown ファイルとして保存され、ユーザーやチームが主要なプロセスを簡単かつ確実に再実行できる形で運用できます。 保存後は、Cascade 内で /[name-of-workflow] という形式のスラッシュコマンドで呼び出せます。

​
仕組み

Rules は、プロンプトレベルで永続的かつ再利用可能なコンテキストを提供することで、一般に大規模言語モデルに指針を与えます。 Workflows はこの概念を拡張し、トラジェクトリレベルで一連の手順やプロンプトを構造化して提供することで、相互に関連するタスクやアクションの流れに沿って AI モデルを導きます。
Workflow を実行するには、Cascade で /[workflow-name] コマンドを呼び出すだけです。
Workflow の中から別の Workflow を呼び出すこともできます！

例えば、/workflow-1 に「/workflow-2 を呼び出す」「/workflow-3 を呼び出す」といった指示を含められます。
呼び出されると、Cascade は Workflow で定義された各ステップを順に処理し、指定どおりにアクションの実行や応答の生成を行います。

​
ワークフローの作成方法

Workflows を始めるには、Cascade の右上にあるスライダーメニューで Customizations アイコンをクリックし、Workflows パネルに移動します。ここで + Workflow ボタンをクリックすると、新しい Workflow を作成できます。 Workflows は .windsurf/workflows/ ディレクトリ内の Markdown ファイルとして保存され、タイトル、説明、そして Cascade が従うべき具体的な指示を含む一連の手順で構成されます。

​
ワークフローの検出

Windsurf は複数の場所からワークフローを自動的に検出し、柔軟に整理します:
  • 現在のワークスペースとサブディレクトリ: 現在のワークスペースおよびそのサブディレクトリ内のすべての .windsurf/workflows/ ディレクトリ
  • Git リポジトリ構造: Git リポジトリでは、親ディレクトリのワークフローを見つけるために Git のルートディレクトリまで遡って検索します
  • 複数ワークスペースのサポート: 同一ワークスペースで複数のフォルダーを開いている場合、ワークフローは重複を除外し、最短の相対パスで表示します

​
ワークフローの保存場所

ワークフローは次のいずれの場所にも保存できます:
  • 現在のワークスペース ディレクトリ内の .windsurf/workflows/
  • ワークスペース内の任意のサブディレクトリにある .windsurf/workflows/
  • 親ディレクトリ（Git リポジトリの場合は Git ルートまで）にある .windsurf/workflows/
新しいワークフローを作成すると、Git のルートではなく、現在のワークスペースの .windsurf/workflows/ ディレクトリに保存されます。 ワークフロー ファイルは、1 ファイルあたり 12,000 文字までです。

​
Cascade でワークフローを作成する

Cascade にワークフローの作成を依頼することもできます。特定の CLI ツールで、一連の手順から成るワークフローに特に適しています。

​
ワークフロー例

Workflows には多様なユースケースがあります。例えば次のとおりです:

/address-pr-comments

これは、PR コメントへの対応に社内で使用している Workflow です:
1. PR ブランチをチェックアウト: `gh pr checkout [id]`

2. PR のコメントを取得

 bash
 gh api --paginate repos/[owner]/[repo]/pulls/[id]/comments | jq '.[] | {user: .user.login, body, path, line, original_line, created_at, in_reply_to_id, pull_request_review_id, commit_id}'

3. 各コメントごとに以下を実施。必ず1つずつ順に対応すること。
 a. 次の形式で出力: 「(index). From [user] on [file]:[lines] — [body]」
 b. ファイルと該当行範囲を分析する。
 c. コメントの意図が不明な場合は変更しない。私に確認するか、私が実装できるよう依頼する。
 d. 変更できると判断したら、次のコメントへ進む前に必ず変更を行う。

4. すべてのコメントを処理したら、実施内容の要約と、ユーザー側の対応が必要なコメントをまとめる。

/git-workflows

あらかじめ定義した形式でコミットし、適切な CLI コマンドを使って、標準化されたタイトルと説明のプルリクエストを作成します。

/dependency-management

設定ファイル（例: requirements.txt、package.json）に基づいて、プロジェクトの依存関係のインストールや更新を自動化します。

/code-formatting

ファイル保存時やコミット前に、コードフォーマッタ（例: Prettier、Black）やリンター（例: ESLint、Flake8）を自動実行し、コードスタイルの維持と早期のエラー検出を行います。

/run-tests-and-fix

ユニットテストや E2E テストを実行・追加し、コミット、マージ、デプロイ前にコード品質を確保するため、エラーを自動修正します。

/deployment

必要な事前チェックやデプロイ後の検証を含め、アプリケーションを各環境（開発・ステージング・本番）へデプロイする手順を自動化します。

/security-scan

CI/CD パイプラインの一部として、またはオンデマンドで、コードベースのセキュリティ脆弱性スキャンを統合・実行します。