本文へスキップ

Windsurfユーザー向け

Windsurfはファイルを編集する。
Maguyvaはリポジトリを見る。

Windsurfはエディタで、Cascadeはエージェントです。モノレポの中では、エージェントにはどのファイルが重要かの地図がまだ必要です。Maguyvaはあなたのコードベースをインデックス化し、MCP経由で返します(セマンティック、AST、グラフ、テキスト)。だから「認証はどこで行われているか」と聞けば、7個のテストスタブではなく、実際の認証フローが返ってきます。

Freeプラン:リポジトリ3個, インデックス済みリポジトリ行数、最大5万行、カード不要。

Windsurfは、あなたが指し示したものを編集します。Maguyvaは、Cascadeにどのファイルを指し示すべきかを教えます。

各レイヤーの役割

4つのパーツ。それぞれに役割があります。

// エディタ

Windsurf

あなたとCascadeが実際に作業する場所。

// 手動のコンテキスト

@メンション + .windsurfrules

手動のコンテキストは、リポジトリが大きくなるまでは有効です。

// コードベース

Maguyva

MCP経由の、自動的なコードベースの事実。

// 支払うのは誰か

課金対象はワークスペース、シートではありません

エージェントはシート料金を払いません。料金を見る

Windsurfはエディタです。使いましょう。

IDEが問題なのではありません。Cascade、タブ補完、複数ファイル編集、そして.windsurfrulesはどれも優れていて、あなたはすでにこう使っているはずです:

  • 開いているファイルでのインライン提案とCascadeによる編集。
  • 変更がローカルな場合の複数ファイル編集。
  • リポジトリの規約やスタイルガードレールのための.windsurfrules
  • 特定のファイルをコンテキストに取り込むための@メンション。

それは続けてください。何ひとつなくなりません。

しかし、実際のモノレポ(ワークスペース依存を持つTypeScript、Pythonサービス、混在パッケージ)では、関連するファイルがまだCascadeのレーダーに入っていない瞬間、エージェントのコンテキストは崩れます。

すでに試した手動の対処法と、それが崩れる場所

4つの手動対処法と、それぞれの失敗モード。左 = 今あなたがしていること。右 = それが崩れる場所。

// the fix

// ファイルに言及する

重要だと思う3つのファイルを@メンションします。Cascadeはその中で綺麗に編集します。

// where it breaks

// 言及は推測に過ぎない

うまくいくのは、どのファイルが関わっているかをすでに知っている場合だけです。コンテキストツールの本質は、あなたが言及すべきだと知らなかったファイルを、表に出すことです。

// the fix

// スニペットを貼り付ける

別のパッケージから200行をCascadeに貼り付けて、十分なコンテキストを与えます。

// where it breaks

// 貼り付けたコードは古くなる

午前9時に貼り付けたスニペットは、午前11時にチームメイトが取り込んだリベースを反映していません。Cascadeは、パッケージの幻のバージョンに対して編集していることになります。

// the fix

// コンテキストドキュメントを書く

.windsurfrulesファイルやアーキテクチャのマークダウンを書きます。今日のところは正しい。

// where it breaks

// ドキュメントはコードより速く陳腐化する

手で書いたものは、すべて陳腐化していきます。信頼できる情報源はコードです。キューレイヤーを説明するドキュメントは、1週間は正しくても、その後はずっと間違ったままです。

// the fix

// ルールファイルを保持する

命名規則、lint、ビルドコマンドのために.windsurfrulesを追加します。振る舞いには最適です。

// where it breaks

// ルール ≠ インデックス

.windsurfrulesは「コミット前に必ずpnpm tsc -bを実行する」を書くのに適した場所です。しかし、モノレポ内のすべてのシンボル、ファイル、呼び出し箇所を問い合わせ可能にするインデックスではありません。

Maguyvaは、その下にあるレイヤーです

Windsurfの代替ではありません。CascadeのMCPサポートにぶら下がる、リポジトリコンテキストレイヤーです。

  • Semantic + AST + グラフ + テキスト 意味、構造、依存関係、あるいはリテラルで検索。すべての結果に、ファイルパスと行番号が付きます。
  • デフォルトでパッケージ横断 Cascadeが今開いているパッケージだけでなく、モノレポ内のすべてのパッケージにわたる呼び出し箇所とインポート元。
  • ブランチを認識 Maguyvaは、Cascadeが編集しているバージョンのコードを把握しています。
  • 補完的であり、競合ではない .windsurfrulesは引き続きその役割を果たします。@メンションも同様です。Maguyvaは、それらが埋められない隙間を埋めます。

Cascadeは、あなたが指し示したファイルを編集する。

Maguyvaは、エージェントにどのファイルを指し示すべきかを教える。

3つのモノレポワークフロー

パッケージ横断、言語横断。Cascadeのgrepではなく、実際のコールグラフに根ざしています。

// workflow 01

何にも言及せずに、パッケージ横断で認証フローを見つける

cascade> このモノレポではauthenticationはどこで行われていますか?

graph::query("authentication flow")
  packages/web/src/auth/session.ts:42       middleware
  packages/api/src/auth/jwt.ts:88           token verify
  packages/shared/src/auth/types.ts:12      AuthContext
  packages/admin/src/auth/admin-only.ts:31  rbac gate

 4つのパッケージにまたがる4つのエントリーポイント、呼び出し箇所の密度でランク付け。
[exit 0]

ファイルに言及しませんでした。スニペットも貼り付けませんでした。Cascadeは、重要な4つのファイルを正しいランキングで手にし、根拠のある編集ができます。

// workflow 02

テストスタブではなく、実際の実装を見つける

cascade> normalizePhoneNumberはE.164をどのように処理していますか?

semantic::query("normalize phone E.164")
  packages/shared/util/phone.ts:88     normalizePhoneNumber()  ← real impl
  packages/api/test/phone.spec.ts:14   jest.mock(...)          ← stub
[exit 0]

名前は嘘をつきます。モックは実際のコードを覆い隠します。Maguyvaは、すべてのパッケージにわたって、実際の実装をテストモックより上位にランク付けします。

// workflow 03

リファクタリングの前に、ブラストラディウスを確認する

cascade> モノレポ全体でQueueDispatcher.publishを呼び出しているのはどこですか?

graph::callers(QueueDispatcher.publish)
  3 in packages/billing/*
  1 in packages/audit/*
  1 in packages/notifications/*
  1 in services/python-worker/*  ← cross-language via gRPC stub
[exit 0]

パッケージ横断、そしてポリグロットなリポジトリでは言語横断でも、呼び出し箇所がインラインで表示されます。差分は、Cascadeのgrepではなく、実際のインポート元に根ざしています。

Windsurfでのセットアップ

3ステップ。Freeプラン:リポジトリ3個, インデックス済みリポジトリ行数、最大5万行、カード不要。

  1. // step 01

    maguyva.aiでリポジトリをインデックス化

    最もコンテキストの痛みを感じているモノレポを選びましょう。

  2. // step 02

    WindsurfのMCPサーバーにMaguyvaを追加

    // ~/.codeium/windsurf/mcp_config.json
    {
      "mcpServers": {
        "maguyva": {
          "serverUrl": "https://maguyva.tools/mcp",
          "headers": {
            "Authorization": "Bearer <your-key>"
          }
        }
      }
    }
  3. // step 03

    答えをすでに知っている質問をひとつ投げてみる

    会社全体から始めないでください。1つのリポジトリと、「パッケージ横断でformatInvoiceを呼び出しているのは何か?」のような、検証可能な質問1つから始めましょう。