Workflows は、サービスのデプロイや PR コメントへの対応など、繰り返し発生するタスクに対して、Cascade を導く一連の手順を定義できます。 これらの Workflows は markdown ファイルとして保存され、ユーザーやチームが重要なプロセスを簡単かつ再現可能な形で実行できるようにします。 保存すると、Workflows は Cascade 内で /[name-of-workflow] という形式のスラッシュコマンドから呼び出せます。

仕組み

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

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

Workflow を作成する方法

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

ワークフローの検出

Windsurf は柔軟に整理できるよう、複数の場所からワークフローを自動検出します:
  • 現在のワークスペースとサブディレクトリ: 現在のワークスペースおよびそのサブディレクトリ内にある .windsurf/workflows/ ディレクトリすべて
  • Git リポジトリ構造: Git リポジトリの場合、Windsurf は親ディレクトリ内のワークフローを見つけるために、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 パイプラインの一部として、またはオンデマンドで、コードベースに対するセキュリティ脆弱性スキャンを統合して実行します。