基本概念

Pathruleのデータモデルは意図的に小さく設計されています。3種類のコンテンツ、ノードのツリー、そしてパスに基づくスコープです。この形を頭に入れておけば、Pathruleのそれ以外の部分は自然に理解できます。

このページを読む際に押さえておいてほしい点があります。以下の3種類のコンテンツは作成の対象です。人が書き、編集し、議論するものであり、あくまで入力です。エージェントが受け取るのはタスクに応じた内容で、目の前の作業に該当するエントリだけが、優先順位を付けられ、タスクに合わせて調整された形で渡されます。その側面はアーキテクチャの概要で扱い、このページでは書く内容について説明します。

ワークスペースツリー

ワークスペースはノードのツリーです。ルートはワークスペースそのものです。子ノードはフォルダまたはファイルで、チームがナレッジを書き残すリポジトリ内の各部分に対応します。

/                            workspace root
  /apps                      folder node
    /apps/web                folder node
      /apps/web/auth         folder node
        /apps/web/auth/login.tsx   file node

ツリーを手作業で作る必要はありません。/apps/web/authにメモリを書くと、Pathruleが必要に応じて一連のノードを作成します。空のノードにコストはかからず、そのパスが役に立たなくなったら後から簡単に削除できます。

メモリ

メモリは、アシスタントが後で読めるようにチームメンバーが書き残す短いMarkdownドキュメントです。

• 事実: スキーマに関するメモ、設計上の判断、ハマりどころ。
• ポストモーテム: 何が壊れたか、何を学んだか、どう修正したか。
• 規約: このチームが好む物事の進め方。

メモリはデフォルトでは助言として扱われます。アシスタントが作業しているパスに関連するとフックが判断したときに、アシスタントのコンテキストに表示されます。

ほとんどのメモリは、人か、人と一緒に作業するアシスタントが書きます。Cloudのワークスペースでは、Pathruleが独自にいくつか追加することもあります。エージェントが初めて詳細なコンテキストを要求した際に、ファイル名から認識した技術に関する短いメモ（「TypeScript project」や「Docker containerization」など）をワークスペースのルートに追加します。これらは通常のメモリなので、ほかのメモリと同じように編集や削除ができます。

ルール

ルールは、あるスコープ内でアシスタントが従わなければならない制約です。

ルールには次の要素があります。

• スコープ種別。folderはディレクトリ配下にルールを適用します。file_typeは*.tsxのようなファイルのglobに適用します。projectはワークスペース全体に適用します。
• 優先度。最も重要な制約にはhigh、一般的なガイダンスにはmedium、スタイル上の好みにはlowを使います。優先度が左右するのはルールがどれだけ強く表示されるかであり、ブロックするかどうかではありません。
• 強制モード。advisoryルールはコンテキストとして添えられ、どう適用するかはアシスタントが判断します。strictルールは人が承認した実行可能な制約を持ち、ツール呼び出しの前にフックが実行されるクライアントでは、該当する変更が反映される前にブロックできます。
• 本文。短い命令形の箇条書きが最も効果的です。

スコープが現在のパスに一致する場合、優先度の高いルールから先に表示されます。優先度の低いルールは、役に立つ可能性が高いときに表示されます。

スキル

スキルは、アシスタントが毎回手順を導き直す代わりに呼び出せる、名前付きの手順です。

例：

• replay-stripe-webhook: 正確なCLIコマンドと、実行前の安全確認手順を含むチェックリスト。
• regenerate-fixtures: スクリプトのパス、入力、期待される出力。
• release-check: チームが常にアシスタントに順を追って確認させたい、リリース前のチェックリスト。

スキルは名前で見つけられます。アシスタントは現在のパスに紐づくスキルをPathruleに問い合わせ、タスクに合うものを選べます。

パススコープ

すべてのメモリ、ルール、スキルはノードのパスに置かれます。そのパスが、どこで表示されるかを決めます。

• /apps/webにあるメモリは、apps/web配下のあらゆる作業に関連します。
• /にあるメモリは、あらゆる場所で関連します。
• /services/billingにあるスキルは、課金サービス内で作業が行われるときにアシスタントに提示されます。

パススコープによって、アシスタントのコンテキストウィンドウを小さく保てます。apps/web/dashboardでのUIの微調整に、データベースマイグレーションに関するルールは必要ありません。

優先度と強制

優先度と強制は、互いに独立した2つの設定です。

• 優先度（high、medium、low）は、ルールがどれだけ強く表示されるかの優先順位を決めます。highは最も重要な制約に限り、控えめに使ってください。
• 強制（advisoryまたはstrict）は、違反時に何が起きるかを決めます。advisoryルールはコンテキストとして表示され、どう適用するかはアシスタントが判断します。新しいルールはすべてadvisoryから始まります。エージェントはルールに対して実行可能な制約を提案できますが、それは提案として保存されるだけで、強制はされません。人が承認すると、ローカルのフックが該当する編集を反映前にチェックし、変更をブロックしたうえで、そのルールを理由として表示できるようになります。

Pathrule CLIとVS Code拡張機能は、Claude Code、Codex、Cursor、GitHub Copilotで利用可能なフックを登録します。ブロックが適用されるのは、クライアントのフックがツール呼び出しを止められる場合です。Windsurfにはフックがなく、Remote MCPはフックをインストールしません。どちらもルールをコンテキストとして受け取るだけで、Pathruleによる書き込み前のブロックは発生しません。

次に読むもの

• Pathruleが計算するものでは、これら3種類の書かれたコンテンツを取り巻く派生レイヤーについて説明しています。
• フックの仕組みでは、ランタイムが送信する内容をどのように選ぶかを説明しています。
• MCPの概要では、アシスタントがノードの読み書きに使うツールを一覧にしています。
• クイックスタートは、このモデルが実際に動く様子を確認する最も手早い方法です。