パターンのインポート

パターンを取り入れる方法は2つあります。接続済みのAIアシスタントにトークンを貼り付けてPathruleにピースを適切なパスへ書き込ませる方法と、カタログからバンドルを手作業でコピーする方法です。

参照トークン

すべてのパターンには、次の形式の参照トークンがあります。

::pathrule:package:<slug>

たとえば、Next.js App Routerのパターンは::pathrule:package:nextjs-app-routerです。トークンは各カタログページに表示されており、そのままコピーできます。

::pathrule:プレフィックスは予約済みの名前空間です。::skill-nameによる呼び出しよりも先に照合されるため、パターントークンがスキルと誤認されることはなく、スキルの探索がトリガーされることもありません。この区別は、プロンプトフックでもコンテキストリクエストでも同じように保たれます。

トークンはプレーンテキストとして貼り付けてください。スキルの呼び出しと同様に、バッククォートやコードブロック内のトークンは引用されたコードとして扱われ、無視されます。1つのプロンプトに複数のトークンを含めることもでき、各パターンは1回だけ認識されます。

トークンによるインポート

パターンを追加するには、接続済みのワークスペースでプロンプトにトークンを貼り付けます。あとはPathruleが処理します。

1. トークンを認識します。 プロンプト用のコンテキストを構築する際に、Pathruleが::pathrule:package:<slug>マーカーを検出し、そのslugのインポート指示を提示します。
2. 書き込む前にプレビューします。 ドライランでパターンを解決し、そのバージョン、解決する課題、ピース、使用する予定のパスを返します。この時点では何も変更しません。プレビューにはパターンが宣言しているパス、スタック、依存関係も含まれるため、アシスタントは実際のプロジェクトとパターンを突き合わせることができます。
3. ツリーに合ったパスを選びます。 パターンは推奨パスを宣言していますが、実際のリポジトリの構成はさまざまです。アシスタントはレイアウトに合ったベースを選び、パターンのパスをその下に付け替えるので、ピースは本来あるべき場所に配置されます。モノレポでは、Next.jsパターンの/appのルールが/apps/web/appの下に配置されることがあります。
4. 一致しない場合は確認します。 プロジェクトで使われていないと思われるスタックを対象にしたパターン、たとえばExpoのないプロジェクトに対するReact Nativeのパターンの場合、アシスタントはやみくもにインポートせず、いったん止まって、追加するかどうかとどこに追加するかをあなたに確認します。
5. バンドルを書き込みます。 確認が取れると、各ピースが通常の書き込み経路で作成されます。メモリはメモリとして、ルールはスコープ種別と優先度を持つルールとして、スキルは由来するパターンのタグが付いた呼び出し可能なスキルとして作成されます。各パスの途中で不足しているノードは必要に応じて作成されます。

その後、アシスタントが1行の要約を伝えます。たとえば、インポートしたルール、メモリ、スキルの数、すでに存在していた数、失敗した数です。

インポート後のピースは、通常のワークスペースのコンテンツです。自分で書いたものと同じフックと検索を通じて提示され、編集方法も同じです。インポートされたルールは助言として扱われます。コンテキストとして添えられるだけで、人が実行可能な制約を承認しない限り編集をブロックしません（ガードレールとしてのルールを参照してください）。

インポートはあなたの権限で書き込まれます。各ピースはほかの書き込みと同じアクセスチェックを通るため、チームでは対象ワークスペースへの書き込み権限が必要です。Viewerはインポートできません。ロールと権限を参照してください。

手作業でのコピーによるインポート

パターンを使うのにトークンは必須ではありません。各カタログページには「Manual copy (full bundle)」アクションがあり、バンドル全体をプレーンなMarkdownとしてコピーできます。各ピースには種類と配置先パスが、各ルールにはスコープと優先度がラベルとして付いています。これをアシスタントや自分のメモに貼り付ければ、好きな場所にピースを作り直せます。セットアップもアカウントも不要です。

すべてのパターンは/patterns/<slug>/rawで生のMarkdownとしても公開されています。リンクからアシスタントにバンドル全体を読ませたいときに便利です。

購読ではなく初期投入

パターンのインポートは1回限りの初期投入です。ワークスペース内のコピーはその時点からあなたのものになり、カタログとのリンクは保たれず、知らないうちに変わることもありません。Pathruleはどのバージョンをインポートしたかを記録せず、新しいバージョンが公開されても通知しないため、すでに手を加えたコンテンツが同期で上書きされることは一切ありません。

インポート後にパターンが更新されたかどうかを知るには、カタログページのバージョンと更新日を比較し、公開されているパッケージの変更履歴を確認してください。再インポートでは変更は取り込まれません。同じタイトルがすでに存在するピースはすべてスキップされるためです。新しいバージョンを取り込むには、バンドルを削除して再度インポートします。ただし、インポートしたピースへの編集はこれによって置き換えられます。改善されたピースを1つだけ取り込みたい場合は、カタログページから手作業でコピーしてください。

再インポートと削除

• 再インポートで重複することはありません。 同じインポートを再度実行すると、同じタイトルがすでに存在するピースはすべてスキップされ、追加されたものとすでに存在していたものが報告されます。メモリは、そのパスに同じタイトルのメモリがあれば存在しているとみなされます。ルールやスキルは、ワークスペース内のどこかに同じ名前のものがあれば存在しているとみなされます。スキップされたピースは、編集も含めてそのまま残ります。インポート後に名前を変更したピースは認識されなくなるため、再インポートすると再び追加されます。
• 削除は1ステップです。 パターンの定義はタイトルとパスからなる独自のマニフェストなので、アシスタントにパターンの削除を依頼すれば、1回の呼び出しでバンドル全体を取り消せます。ベースパスを指定してインポートした場合は、削除時にも同じベースを指定してください。そこで見つからないピースはエラーとしては扱われず、見つからなかったものとして報告されます。

削除の影響範囲

削除では、インポート時に作成したものを記憶しているのではなく、各ピースをそのパス上のタイトルで探します。そのため、実行する前に知っておくべき影響が3つあります。

• 編集済みのピースも削除されます。 インポート後に編集したメモリ、ルール、スキルも、タイトルとパスが変わっていなければ、編集内容ごと削除されます。
• 同じタイトルの自作の項目も削除されます。 パターンのピースと同じタイトルのメモリ、ルール、スキルを同じパスに自分で書いていた場合、それも削除されます。タイトルの比較では大文字と小文字は区別されません。
• 名前の変更や移動をしたピースは残ります。 ピースの名前を変えたり別のパスに移動したりすると、削除の対象から外れます。これを使えば、1つのピースだけを残して残りを削除できます。

削除された項目は消去されるのではなくアーカイブされます。Cloudワークスペースでは、完全に削除されるまでワークスペースのアーカイブに残り、オーナーまたは管理者がWebコンソールの設定のWorkspace、Archiveから復元できます。

対応環境

トークンによるインポートと削除はローカルのstdio MCPツールを使用します。このランタイムをCloudワークスペースに接続している場合も同様です。Remote MCPではこれらの補助機能は提供されません。リモートクライアントは生のバンドルを読み込み、利用可能なナレッジツールで選んだ項目を作成できます。

インポートは、Pathrule CLIまたはVS Code拡張機能で接続したClaude Code、Codex、Cursor、Windsurf、GitHub Copilotで同じように動作します。インポートと削除は、ローカルワークスペースでもPathrule Cloudのワークスペースでも同じように機能します。Claude CodeとCodexでは、エージェントが動く前にプロンプトフックがトークンを検出します。Cursor、GitHub Copilot、Windsurfにはプロンプトフックがないため、アシスタントはコンテキストリクエストと指示ファイル内のプロトコルガイダンスから、同じインポートと削除の手順を把握します。

次に読むもの

• 全体像についてはパターンの概要を参照してください。
• バンドルの中身とバージョン管理の仕組みについてはパターンの構成を参照してください。
• インポートしたピースがワークスペースに入った後どのように届けられるかについてはフックの仕組みを参照してください。