WindsurfはCodeiumが開発するAIコーディングエディタです。ファイルの読み取り、ターミナルコマンドの実行、コードベース全体への変更が可能なマルチステップ型エージェントAI「Cascade」を搭載しています。このCascadeがプロジェクト内でどのように振る舞うかを制御するファイルが .windsurfrules です。
Cursorで .cursorrules を使ったことがあれば、概念はまったく同じです。Claude Codeで CLAUDE.md を使ったことがあれば類似していますが、構造的に重要な違いがあります。このガイドでは .windsurfrules とは何か、どのように機能するか、効果的なルールの書き方、そして主要なプロジェクトタイプ向けのすぐに使えるテンプレートを解説します。
.windsurfrules とは
.windsurfrules はプロジェクトのルートに置くプレーンテキストファイルです。Cascadeがそのディレクトリ（またはサブディレクトリ）のファイルを扱う際、このルールファイルを読み込んでプロジェクト内のすべての作業に指示を適用します。
ルールは自由形式のテキストです。スキーマを埋めたりメニューから選んだりするものではなく、新しいチームメンバーの初日に自分のプロジェクトを説明するように自然言語で書きます。どのスタックを使っているか、どのような規約に従っているか、AIが確認なしに絶対にやってはいけないことは何か。
CascadeはシステムコンテキストとしてこのファイルをCascadeに統合するため、セッション全体を通じて指示が持続します。プロンプトのたびに繰り返す必要はありません。
グローバルルールとプロジェクトルール
Windsurfにはルールの2つのレベルがあります。
グローバルルール — すべてのプロジェクト、すべてのセッションで適用されます。WindsurfのSettings →「Cascade」→「Custom Instructions」で設定します。常に当てはまる個人的な好みを書きます: 好きな言語、コメントのスタイル、デバッグのやり方など。
プロジェクトルール (.windsurfrules) — 現在のプロジェクトだけに適用されます。チームの規約、フレームワーク固有の動作、プロジェクト固有の制約がここに入ります。リポジトリにコミットしてすべてのチームメンバーが同じ動作を得られるようにしましょう。
両方が存在する場合、Windsurfはマージします。グローバルルールとプロジェクトルールが競合した場合はプロジェクトルールが優先されます。
.windsurfrules と .cursorrules・CLAUDE.md の違い
3つのフォーマットは同じ根本的な目的——AIにプロジェクトについての継続的なコンテキストを与える——のために設計されていますが、設計は異なります。
| 機能 | .windsurfrules | .cursorrules | CLAUDE.md |
|---|---|---|---|
| フォーマット | 自由形式テキスト | 自由形式テキスト | Markdown |
| スコープ | プロジェクト単位 | プロジェクト単位 | プロジェクト単位またはディレクトリ単位 |
| 複数ファイル | 不可（プロジェクトルートに1つ） | 不可 | 可（入れ子・階層型） |
| サブエージェント対応 | あり（Cascadeエージェント） | なし | あり（Claudeサブエージェント） |
| シェルコマンド | なし | なし | あり（フック経由） |
| グローバル設定 | あり（Windsurf設定） | あり（.cursorrules global） | なし |
.windsurfrules と CLAUDE.md の最も実用的な違いは階層構造です。Claude Codeではサブディレクトリにも CLAUDE.md を置けて、それぞれのディレクトリ内だけに適用されます。Windsurfは現在のところプロジェクトルートに1つの .windsurfrules しか使えません。フロントエンドとバックエンドで規約が異なるモノリポの場合、1つのファイルで処理する必要があります。
.windsurfrules と .cursorrules の実用的な違いは主にAIモデルです。.cursorrules はCursorのモデルと話します。.windsurfrules はCascadeと話します。ルール作成の原則は同じですが、Cascadeはマルチステップのエージェントタスクが特に得意なため、タスク完了と検証に関するルールがより重要になります。
効果的な .windsurfrules の書き方
すべてのAIルールファイルで共通する失敗パターンは、聞こえは良いが動作を変えない「理想を語る指示」を書いてしまうことです。「クリーンなコードを書く」は何もしません。「驚き最小の法則に従う」はコンテキストなしでは意味がありません。実際に機能するルールは、具体的で、検証可能で、実際のプロジェクトに根ざしたものです。
機能するパターンを紹介します。
1. 指示の前に事実を述べる
どうしてほしいかではなく、プロジェクトについて何が真実かから書き始めます。AIは事実のコンテキストを使ってより良い判断を下します。
このプロジェクトはNext.js 15（App Router）、TypeScript strict mode、
Tailwind CSS、DrizzleORM + PostgreSQLを使用しています。
パッケージマネージャはpnpmです。このコンテキストだけで、12の間違った動作を暗黙的に防げます——npmをpnpmの代わりに使う、TypeScriptの代わりにJavaScriptを書く、Pages Routerを使う、Drizzleなのにprismaを勧める、など。
2. 変更前に何を確認すべきかを明示する
Cascadeは素早く大きな変更を加えられます。一歩立ち止まって先に確認すべきタイミングを明示しましょう。
関数をリファクタリングする前に、その関数がexportされて
2つ以上のファイルで使われていないか確認してください。
使われている場合は変更前に影響するコール箇所をリストアップしてください。3. テストの契約を明記する
プロジェクトにテストがある場合、どのテストがあり、変更後の期待状態は何かをAIに伝えましょう。
コードを変更したら必ず `pnpm test` を実行してください。
タスクを完了とみなす前にすべてのテストがパスしなければなりません。
あなたの変更前にパスしていたテストが失敗した場合は、
次に進む前にそれを修正してください。4. 実際に使っているパターンを名前で指定する
「関数型パターンを使う」のような一般的なルールはAIによって解釈が異なります。コードベースが実際に使っているパターンを名前で指定してください。
データアクセスにはリポジトリパターンを使います。
データベースへのクエリはすべて /src/repositories/ に入ります。
サービスはリポジトリを呼び出します。サービスがデータベースに
直接クエリすることはありません。5. 破壊的なアクションのガードレールを設定する
Cascadeはターミナルコマンドを実行できます。確認が必要なものを決めておきましょう。
`DROP TABLE` や `DELETE FROM` を実行する前に、
必ずクエリを見せて私の明示的な承認を得てください。
データベースマイグレーションを自動的に実行しないでください。
`drizzle-kit push` を実行する前にマイグレーションファイルを
見せて内容を説明してください。すぐに使える12の .windsurfrules テンプレート
1. Next.js 15（App Router）
プロジェクト: App Router、TypeScript strict mode、Tailwind CSS、
shadcn/ui、DrizzleORM + PostgreSQLを使ったNext.js 15アプリ。
パッケージマネージャ: pnpm。
規約:
- 新しいページはApp Routerの規約に従い /src/app/ に作成します。
- デフォルトはServer Component。「use client」は本当に必要な場合のみ
(イベントハンドラ、ブラウザAPI、フック)。コメントで理由を書いてください。
- データ取得はServer ComponentかServer Actionで行います。
代替手段がない限りクライアントからフェッチしないでください。
- 条件付きTailwindクラスには @/lib/utils の cn() ユーティリティを使います。
- shadcn/uiコンポーネントは /src/components/ui/ にあります。変更しないでください。
カスタムコンポーネントは /src/components/ に置きます。
- データベースクエリは /src/db/queries/ に入ります。サービスはクエリを呼び出します。
コンポーネントに直接 db をインポートしないでください。
- 環境変数: サーバー専用変数は .env.local に。クライアントに公開する変数は
必ず NEXT_PUBLIC_ プレフィックスをつけてください。
テスト:
変更後は必ず `pnpm test` を実行します。完了とみなす前にすべてのテストをパスさせてください。
新しいルートやServer Actionを追加した場合はそのテストも追加してください。
禁止:
- Pages Routerの使用。
- なぜかを説明するコメントなしに TypeScript で `any` を使うこと。
- 事前確認なしに新しいパッケージをインストールすること。2. Python FastAPIサービス
プロジェクト: Python 3.12、Pydantic v2、SQLAlchemy 2.0、
PostgreSQL を使ったFastAPIサービス。依存性注入はFastAPIの Depends() で行います。
規約:
- すべてのルートハンドラは /src/routers/ に入ります。
- ビジネスロジックは /src/services/ に入ります。ルーターはサービスを呼び出します。
サービスはルーターからインポートしません。
- データベースモデルは /src/models/、Pydanticスキーマは /src/schemas/ に入ります。
SQLAlchemyモデルとPydanticスキーマを混在させないでください。
- 全体的にasync/awaitを使います。同期的なデータベース呼び出しは禁止です。
- 適切なステータスコードでHTTPExceptionを発生させてください。
例外をクライアントに未処理のまま伝播させないでください。
- Pydantic v2の構文（class Configではなくmodel_config）を使います。
テスト:
変更後は必ず `pytest -x` を実行します。-xフラグは最初の失敗で停止します。
タスクを完了とみなす前にすべてのテストをパスさせてください。
データベース:
生のSQLは書かないでください。SQLAlchemy ORMかCore表現を使います。
スキーマ変更には常にAlembicを使います。データベーススキーマを
直接変更しないでください。実行前にマイグレーションファイルを見せてください。3. React Native（Expo）
プロジェクト: TypeScript、NativeWind（RN向けTailwind）、
Expo Router、データ取得にReact QueryのExpo 52アプリ。
iOSとAndroidの両方をターゲットにします。
規約:
- Expoのファイルベースルーティングを使います。スクリーンは /app/ に入ります。
- スタイリングにはNativeWindを使います。NativeWindで対応できない
ユースケース以外はStyleSheet.create()を使わないでください。
- すべてのサーバーステートにReact Queryを使います。
useState + useEffectでのデータ取得は禁止です。
- 共有コンポーネントは /components/、スクリーン固有のコンポーネントは
スクリーンと同じディレクトリに入ります。
- プラットフォーム固有のコードには .ios.tsx / .android.tsx 拡張子パターンを使います。
禁止:
- 事前確認なしにExpo互換性のないライブラリを使うこと。
- Expoからのejectを事前議論なしに行うこと。
- プロダクションコードでconsole.logを使うこと（代わりにloggerユーティリティを使う）。4. Django REST API
プロジェクト: Django 5.1、Django REST Framework、psycopg3経由のPostgreSQL、
非同期タスクにCeleryを使います。
規約:
- アプリは機能ベース（例: /accounts/, /orders/, /notifications/）です。
各アプリはmodels.py、serializers.py、views.py、urls.pyを持ちます。
- クラスベースビューを使います（ViewSet優先）。関数ベースビューは
本当にシンプルな場合のみ使います。
- バリデーションはシリアライザで行います。ビューでバリデーションしないでください。
- 関連モデルをクエリする際は常にselect_related()とprefetch_related()を使います。
追加する際は回避しているN+1問題を説明してください。
- Celeryタスクは各アプリの /tasks.py に入ります。タスクはべき等でなければなりません。
テスト:
変更後は必ず `python manage.py test` を実行します。
DBテストにはDjangoのTestCase、エンドポイントテストにはAPITestCaseを使います。
データベース:
マージコンフリクト修正以外はマイグレーションファイルを手動編集しないでください。
`makemigrations --check` を実行してモデルとマイグレーションが一致しているか確認します。5. CLIツール（Node.js）
プロジェクト: TypeScript、Commander.js、ターミナルUIにInkライブラリを使った
Node.js CLIツール。npmで配布します。Node.jsバージョン: 20 LTS。
規約:
- エントリーポイント: /src/cli.ts。最小限に保つ——引数のパースとコマンド呼び出しのみ。
- コマンドは /src/commands/ に入ります。各コマンドは別のファイルです。
- 共有ユーティリティは /src/utils/ に入ります。
- インタラクティブまたはフォーマットされたターミナル出力にはInkコンポーネントを使います。
コマンドハンドラでconsole.logを避けてください。
- エラーはトップレベルに投げるのではなく、Inkのエラーコンポーネントで
キャッチして表示してください。
パッケージ:
- package.jsonの `bin` フィールドは /dist/ のコンパイル済み出力を指します。
- ローカルテストのために `npm link` する前に `npm run build` を実行します。
- `npm publish` を直接使わないでください。まず `npm publish --dry-run` を
実行して出力を見せてください。6. Goマイクロサービス
プロジェクト: 標準ライブラリHTTP（net/http）、PostgreSQLにpgx、
構造化ログにzeroLogを使ったGo 1.23マイクロサービス。
規約:
- フォルダ構造: mainパッケージは /cmd/、すべてのアプリケーションコードは /internal/ に。
/internal/ 内のものは外部からインポートしないでください。
- HTTPルーティングには標準ライブラリを使います（Go 1.22以上のパターンマッチング）。
プロジェクトにすでにルーターフレームワークがある場合を除き、追加しません。
- すべてのエラーは fmt.Errorf("...: %w", err) でコンテキストと一緒にラップします。
_ でエラーを破棄しないでください。
- ログ: zeroLogを使います。すべてのログエントリに "component" フィールドが必要です。
log.Error().Err(err).Str("component", "...").Msg("...") パターンを使います。
- データベースクエリは /internal/repository/ に入ります。ハンドラやサービスで
pgxを直接呼び出さないでください。
テスト:
変更後は必ず `go test ./...` を実行します。すべてのテストをパスさせてください。
複数の入力ケースを持つ関数にはテーブル駆動テストを使います。7. データサイエンス / Jupyter
プロジェクト: Python 3.11、pandas 2.x、scikit-learn、
Jupyterノートブックを使ったデータサイエンスプロジェクト。再現性が最重要です。
規約:
- ノートブックは探索と発表専用です。再利用可能なコードは
/src/ のPythonモジュールに入ります。
- ノートブックにファイルパスをハードコードしないでください。
プロジェクトルートからのpathlibと相対パスを使います。
- requirements.txtにすべての依存関係を正確なバージョンで固定します。
ライブラリを追加する際は現在のバージョンをrequirements.txtに追加してください。
- 可能な場所ではpandasチェーニングスタイルを使います。
DataFrameをその場で変更しないでください。
- 乱数シード: 再現性のために常にnp.random.seed()を設定し、
sklearn関数にrandom_state=を渡します。
データ:
1MBを超えるデータファイルをgitにコミットしないでください。
大きなデータセットは .gitignore に入っている /data/raw/ に置きます。
データソースとダウンロード手順を /data/README.md に文書化してください。8. Chrome拡張機能（Manifest V3）
プロジェクト: Manifest V3、TypeScript、ビルドツールにViteを使ったChrome拡張機能。
フレームワークなし（バニラTypeScript）。
規約:
- バックグラウンドスクリプト: /src/background/。Service Workerとして動作します。
DOM APIは使えません。
- コンテンツスクリプト: /src/content/。ページのDOMにアクセスできます。
chrome.storageに直接アクセスできません——メッセージパッシングを使います。
- ポップアップ: /src/popup/。Chrome APIにアクセスできる標準DOMです。
- コンテキスト間の通信はすべてchrome.runtime.sendMessage()を使います。
TypeScript型でメッセージの形を文書化してください。
- 状態はchrome.storage.localに保存します。
暗号化なしに機密データ（トークン、パスワード）をストレージに保存しないでください。
ビルド:
コンパイルには `pnpm build` を実行します。テスト用に /dist/ をアンパック済み拡張として読み込みます。
manifest.jsonに変更を加えた場合は教えてください——chrome://extensions で
拡張を再読み込みする必要があります。
権限:
manifest.jsonに新しい権限を追加する前に必ず確認してください。
その権限が何のために必要で、どのユーザーデータにアクセスするかを説明してください。9. モノリポ（Turborepo）
プロジェクト: 3つのパッケージを持つTurborepoモノリポ:
- /apps/web — Next.js 15フロントエンド
- /apps/api — Fastify API
- /packages/ui — 共有Reactコンポーネント
- /packages/types — 共有TypeScript型
規約:
- 共有型は /packages/types/ に入ります。両アプリはそこからインポートします。
- 共有UIコンポーネントは /packages/ui/ に入ります。webアプリはそこからインポートします。
- /apps/web と /apps/api は互いにインポートしないでください。
- 依存関係グラフを尊重するために、個別パッケージのビルドではなく
`turbo run build` を実行します。
- すべてのパッケージは同じTypeScript設定ベース /tsconfig.base.json を使います。
変更を加える際:
- 変更前にどのパッケージが影響を受けるか特定してください。
- /packages/types の変更が両アプリに影響する場合はその旨を指摘してください。
- クロスパッケージの問題を検出するために変更後に `turbo run test` を実行します。10. Infrastructure as Code（Terraform）
プロジェクト: AWS向けTerraform設定。
Terraformバージョン: 1.9以上。バックエンド: S3 + DynamoDBステートロック。
規約:
- 環境: /environments/dev/ と /environments/prod/ にルートモジュールがあります。
/modules/ には再利用可能なモジュールが入ります。
- すべてのリソースにNameタグとEnvironmentタグが必要です。
コードベースにすでにある local.common_tags パターンを使います。
- 変数はvariables.tfに、出力はoutputs.tfに、
メインリソース定義はmain.tfに入れます。分離を維持してください。
- 既存リソースの参照にはハードコードされたIDではなくデータソースを使います。
安全ルール:
`terraform apply` を直接実行しないでください。まず `terraform plan` を実行し、
特に「destroy」アクションのプラン出力を見せてください。
プランにリソースの削除が含まれる場合は、処理を進める前に
影響を説明して止めてください。
terraform.tfvarsにシークレットを保存しないでください。
AWS Secrets Managerまたは環境変数を使います。11. オープンソースライブラリ
プロジェクト: npmで公開するオープンソースTypeScriptユーティリティライブラリ。
Node.js 18以上、ブラウザ、Deno環境をサポートします。
ランタイム依存関係ゼロ。
規約:
- 公開APIは /src/index.ts で定義します。
APIデザインを先に議論せずにエクスポートを追加しないでください。
- すべての公開関数には @param、@returns、@example セクション付きの
JSDocコメントが必要です。
- 依存関係なし。追加したい場合は先に承認が必要です。
- ビルド出力: ESM (/dist/esm/)、CommonJS (/dist/cjs/)、型定義 (/dist/types/)。
破壊的変更:
エクスポート関数のシグネチャを変更したりエクスポートを削除したりすることは
破壊的変更です。実行前に必ず指摘してください。
メジャーバージョンアップが必要かどうかはわたしが判断します。
テスト:
変更のたびに `pnpm test` を実行します。テストカバレッジを減らさないでください。
新しいエクスポート関数を追加する場合は完了前にそのテストも追加してください。12. ドキュメントサイト（Astro）
プロジェクト: Astro 5、Starlightテーマ、コンテンツにMDX、
Cloudflare Pagesにホストするドキュメントサイト。
規約:
- ドキュメントコンテンツは /src/content/docs/ に入ります。
- すべてのページのフロントマターにtitleとdescriptionが必要です。
- よくあるパターンにはカスタムコンポーネントを作成するのではなく、
Starlightの組み込みコンポーネント（Aside、Tabs、Stepsなど）を使います。
- コード例は完全で実行可能なものにします。疑似コードは禁止です。
すべてのコードブロックにシンタックスハイライト用の言語を指定します。
- 内部リンクには相対パスを使います。外部リンクはフルURLを含め、
rel="noopener" でnewタブで開きます。
新しいページを追加する際:
- /astro.config.mjs のサイドバーに追加します。
- 他のページから少なくとも1本のリンクが貼られているか確認します。
- `pnpm build` を実行してリンク切れがないことを確認します。避けるべきよくあるミス
実際のコードベースと矛盾するルール。 ルールに「関数型コンポーネントのみ使う」と書いてあるのにコードベースにクラスコンポーネントがある場合、Cascadeは矛盾したシグナルを受け取ります。ルールは理想ではなく、現時点での真実を記述すべきです。理想を語るルールはCONTRIBUTING.mdやADRに書きましょう。
誰も破らないルールを詰め込む。 「読みやすいコードを書く」「わかりやすい変数名を使う」はノイズです。Cascadeはすでにそうしています。ルールがその場所を占める価値があるのは、指示がなければ間違った動作をするものを変える場合です。
なぜを説明しないルール。 「データ取得にuseEffectを使わない」は良いです。「データ取得にuseEffectを使わない——キャッシュレイヤーがReact Queryに依存しているのでReact Queryを使う」はさらに良いです。理由があることで、想定外のエッジケースでもCascadeが適切な判断を下せます。
ファイルをコミットし忘れる。 .windsurfrules はバージョン管理すべきです。.gitignore に入っていたら、チームメンバーがその恩恵を受けられません。
.windsurfrules と他のAIルールファイルの組み合わせ
チームが複数のAIツールを使っている場合、Windsurf用の .windsurfrules とClaude Code用の CLAUDE.md（またはCursor用の .cursorrules）の両方を持つことがあります。これは正常で問題ありません——各AIツールは自分用のルールファイルだけを読みます。
リスクはドリフトです。一方を更新したとき、もう一方を更新し忘れることがあります。機能するアプローチの1つ: リポジトリにシングルソースとなる AI_RULES.md を作り、リリースプロセスの一部としてその内容をツール固有のファイルに同期させます。シンプルなシェルスクリプトで実現できます。
#!/bin/bash
# sync-ai-rules.sh
# 正規のAIルールをツール固有のファイルにコピーする
SOURCE="AI_RULES.md"
cp "$SOURCE" ".windsurfrules"
cp "$SOURCE" "CLAUDE.md"
cp "$SOURCE" ".cursorrules"
echo "AIルールをすべてのツール固有ファイルに同期しました。"これは意図的な簡略化です——各ツールにはツール固有の指示が効果的な独自機能があります——しかし、どのAIツールにも当てはまるルールの80%については、同期することで一貫性を保てます。
ルールが機能しているか確認する
.windsurfrules を書いたらテストしましょう。ルールが制御するはずのことをCascadeに依頼して、従うかどうか確認します。確認すべきこと:
- ファイルの配置: 新しいコンポーネントを追加するようCascadeに依頼します。正しいディレクトリに配置しますか？
- パッケージマネージャ: ライブラリをインストールするようCascadeに依頼します。正しいパッケージマネージャを使いますか？
- テスト: 小さな変更を加えて、完了の確認をCascadeに依頼します。テストを実行しますか？
- ガードレール: ルールで禁止していること（マイグレーションの実行など）をCascadeに依頼します。止まって確認を求めますか？
何かが機能していない場合は、ルールをより明示的にします。曖昧な指示はAIが好意的に解釈します。具体的な指示は正確に従われます。
AIコーディング体験の質は、ルールの質に直接比例します。よく書かれた .windsurfrules があれば、Cascadeはあなたのプロジェクトを熟知したシニア開発者のように動きます——推測を繰り返す汎用アシスタントではなく。上のテンプレートは出発点です。実際のコードベースに合わせて編集すれば、最初から大幅に良い結果が得られます。
FAQ
Q1. .windsurfrules は .cursorrules と同じですか？
同じではありませんが、概念的に似ています。どちらもそれぞれのエディタ（Windsurf vs Cursor）でAIの動作をカスタマイズするファイルです。フォーマットと構文はほぼ同じですが、Cursorは2025年に .cursor/rules/*.mdc に移行しています。Windsurfは2026年時点でもプロジェクトルートのフラットな .windsurfrules を使い続けています。
Q2. .windsurfrules と .cursorrules を同じプロジェクトで使えますか？
はい。各ファイルは対応するエディタのみが読み込みます。チームがWindsurfとCursorの両方を使っている場合、両方のファイルを並行して管理できます。多くのチームはシムリンクを使うか、一方からもう一方を生成して同期させています。
Q3. Windsurf Cascadeは CLAUDE.md や AGENTS.md を読みますか？
2026年時点では、Windsurf Cascadeは主に .windsurfrules を読み込み、AGENTS.md（クロスツール標準）のサポートは実験的です。CLAUDE.mdはネイティブでは読み込みません。複数ツールが混在するチームでは、AGENTS.mdが最良の共通基準です。
Q4. .windsurfrules はどこに置くべきですか？
プロジェクトルート（package.json や README.md と同じ階層）に置きます。プロジェクトを開くとCascadeが読み込みます。2026年時点でサブディレクトリへのネストされた .windsurfrules はネイティブサポートされていません——代わりにディレクトリごとの明示的なルールをルートファイルに書いてください。
Q5. .windsurfrules はどのくらいの長さにできますか？
Cascadeがコンテキストをトランケートするまでのほぼかな文字数制限は8,000〜12,000文字です。本番の .windsurfrules のほとんどは2,000〜5,000文字です。長いルールはモデルの注意を分散させます。重要なルールは上部に置き、オプションのコンテキストはCascadeがオンデマンドで取得できる別のドキュメントに分けてください。
Q6. .windsurfrules から他のファイルやリモートURLを参照できますか？
できません。Cascadeは .windsurfrules を静的テキストとして読み込みます。大きなリファレンス資料（スタイルガイド、APIドキュメントなど）が必要な場合は、ルールファイルにすべてインライン化しようとせず、ワークフロー内でCascadeのウェブフェッチ機能を使ってください。
Q7. .windsurfrules が適用されているかどうかどうやって確認しますか？
ルールの1つで答えるべき自由な質問をCascadeに聞きます（「これをインストールするときにどのパッケージマネージャを使うべきですか？」など）。ルールに従った答えが返れば適用されています。Cascadeが一般的な回答をした場合、ルールがないか、曖昧か、ファイルの上の方にある何かで上書きされています。
関連記事
- CLAUDE.mdとAGENTS.md完全ガイド — Claude Code向けのルールファイル設計の考え方
- .cursorrules vs CLAUDE.md vs AGENTS.md 完全比較（2026年版） — ツールごとの使い分けと選択基準
- ルールギャラリーを見る