本文へスキップ
Pathrule

pathrule.iodocs

Pathrule

ドキュメント

ドキュメントはじめる

ルールの書き方

アシスタントが守るべき制約を適切なスコープと優先度で表現し、コンテキストウィンドウを圧迫せずに確実に届ける方法を説明します。

このページの内容

ルールとは、あるスコープ内でアシスタントが守るべき制約です。ルールはPathruleのコンテンツの中で最も強い位置づけにあります。背景情報ではなく要件として届き、承認済みの実行可能な制約を持つルールは、一致する変更を反映前に止めることができます。

このページでは、ルールを書くべき場面、スコープと優先度の選び方、強制(enforcement)の意味、避けるべきパターンを説明します。

ルールを書くべき場面

コードベースの特定の部分で、アシスタントが絶対にしてはいけないこと、または必ずしなければならないことがあるなら、ルールを使います。

  • 「ブラウザ側のコードではservice role keyを決して使わない。」
  • 「金額はすべてセント単位の整数で保存する。浮動小数点数は決して使わない。」
  • 「マイグレーションは対応するコード変更より先に実行する。例外はない。」
  • 「apps/webのJSXファイルではTailwindのクラスのみを使う。CSS Modulesもインラインスタイルも使わない。」

「状況次第なので、アシスタントに考えてほしい」という内容なら、それはルールではなくメモリです。ルールは譲れないことのためのものです。

スコープの種類

すべてのルールには、どのパスやファイルに適用されるかを決めるスコープの種類があります。

  • folder。 ディレクトリのサブツリーに適用されます。apps/api/auth配下やservices/billing配下など、特定の領域に固有のルールに最適です。
  • file_type。 *.tsxや**/*.test.tsのようなglobに一致するファイルに適用されます。ディレクトリではなくファイルの種類に結びついた、横断的な関心事に最適です。
  • project。 ワークスペース全体に適用されます。使用は控えめにしてください。projectルールはすべてのプロンプトに付いて回ります。

アシスタントに何が見えるかは、スコープと、ルールが紐づけられたノードのパスの組み合わせで決まります。/apps/webに紐づけたfolderルールは、apps/web配下のすべてに適用されます。

優先度

優先度は、ルールをどれだけ積極的に表示するかを決めます。一致するスコープ内では、優先度の高いルールから先に考慮されます。

  • high。 違反するとバグ、セキュリティ上のリグレッション、コンプライアンス上の問題を引き起こすもの向けです。
  • medium。 デフォルトです。「ほぼ常に守るべきだが、致命的ではない」ものに使います。
  • low。 スタイル上のものです。余裕があり、話題が合致しているときに表示されます。好みや慣習に使います。

high優先度は限られた予算です。ルールの半分がhighなら、実質どれもhighではありません。本当に違反が許されないものだけを選んでください。

強制:advisoryとstrict

強制は優先度とは別の設定です。優先度はルールがどれだけ強く表示されるかの優先順位を決め、強制は違反時に何が起きるかを決めます。

  • advisory。 ルールはコンテキストとして扱われます。アシスタントがその重みを判断し、どう適用するかを決めます。CLIやVS Codeから書いたルール、およびアシスタントが書いたルールはadvisoryです。
  • strict。 人が承認した実行可能な制約、つまりimport、識別子、場所といった禁止すべき具体的な形を持つルールはstrictになります。これにより、pre-toolフックがそれに一致するファイルの編集や書き込みを反映前にブロックし、理由としてルールとその対処法を返せるようになります。アシスタントはルールを書くときや更新するとき(pathrule_write_rule、pathrule_update_rule)に制約案を添付できますが、案は案として保存されるだけで、人が承認するまでは何もブロックしません。アシスタントが自分の案を承認することはできません。詳しくはガードレールとしてのルールを参照してください。

ルールを書き換えても、強制の整合性は保たれます。 承認済みの制約は、その検証の根拠となったルール内の文に紐づいています。ルールを書き換えてその文がなくなると、制約は自動的に強制を停止します。そのため、ルールに書かれていない理由でブロックし続けることはありません。ルールの他の部分を編集したり段落を追加したりしても、影響を受けていない制約は有効なままです。

ブロックできるかどうかはクライアントによって異なります。Pathrule CLIはClaude Code、Codex、Cursor、GitHub Copilot向けにツールフックをインストールし、クライアントのpre-toolフックがその判定に従う環境でブロックが適用されます。Windsurfにはフックがなく、Remote MCPもフックをインストールしないため、これらの環境ではルールはコンテキストとしてのみ届きます。届けるだけでは何も強制されません。

構成

ルールは名前と本文で構成されます。本文は命令形で短く保ってください。

Name: No service role key in browser code

Body:
- Never import SUPABASE_SERVICE_ROLE_KEY in any file under apps/web.
- Use the anon key plus row level security.
- If you need server only access, do it from apps/api or a server action.

ターミナルからは、同じルールを1つのコマンドで作成できます。--bodyを指定しない場合、CLIは本文を入力するためにエディタを開きます。

pathrule rule add --path /apps/web --name "No service role key in browser code" --priority high --scope folder

VS CodeではNew Rule… を使います。アシスタントはpathrule_write_ruleでルールを書きます。

実際に最も効果的なのは、1つのルールに1つの制約を置き、本文を短い箇条書きにする形です。長い文章のルールは、人間にもアシスタントにも読み飛ばされがちです。

重複させずに再利用する

ルールは1つのパスに置かれ、その配下すべてに適用されるため、サブツリー全体に対して1つのルールで足ります。同じ制約が離れた2つのフォルダに当てはまる場合は、テキストをコピーして2つのルールにするのではなく、両者に最も近い共通のパスに置くか、globを指定したfile_typeスコープを使ってください。ルールが1つなら、制約が変わったときの編集も1回で済みます。

Pathruleはこの点をサポートします。ワークスペース内の既存ルールと名前が一致する新しいルールはデフォルトで拒否され、すでに存在するルールが書き込み結果で示されます。既存のルールを確認したうえで、意図的に上書きすることもできます(MCP経由のallow_duplicate)。ルールの置き場所を変えるには、別のパスに移動します(VS CodeのMove…、またはmove_to_pathを指定したpathrule_update_rule)。

バージョン管理と同時編集

ルールはメモリと同様にバージョントークンを持ちます。2人のチームメンバーが同じルールを同時に編集しても、互いに上書きすることはなく、衝突としてきちんと検出されます。VS Codeでは、衝突時にメモリの場合と同じ選択肢が表示されます:Reload、Copy My Version & Reload、Keep Mine (Overwrite)。

アシスタントへのルールの届き方

  • 一致するスコープ内のルールは、優先度とタスクとの関連度によって優先順位が付けられます。最も関連度の高いものは本文全体として届き、それ以外は名前だけが示されます。そのためアシスタントはそれらの存在を把握でき、必要に応じてpathrule_read_ruleで全文を読めます。
  • strictルールは、適用される場所では常に全文で届きます。名前だけではブロックの理由を説明できないためです。
  • ルールはコンパイルもされ、クライアントが読み込む指示ファイル（たとえばClaude CodeならCLAUDE.md、CodexならAGENTS.md）に含まれます。そのため、プロンプトフックを持たないクライアントでも、ルールを前提に作業を始められます。

ルールがアシスタントに情報を与えるだけでなく変更をブロックできるかどうかは、優先度ではなく強制モード（advisoryまたはstrict）で決まります。

アンチパターン

  • すべてをhigh優先度にする。 本当に重要なルールだけを選びます。残りはmediumにしてください。
  • メモリのように読めるルール。 「Xを好む傾向がある」はメモリです。「Yは決してしない」がルールです。
  • 重複するルール。 矛盾する表現を含む2つのhighルールは、明確な1つのルールより悪い結果になります。
  • デフォルトでprojectスコープを使う。 ほとんどのルールはフォルダ配下に置くべきものです。本当にどこにでも当てはまる場合に限り、ルールをprojectに引き上げてください。

ローカルとCloudでの作成

このページのターミナルでのaddの例は、Cloudワークスペース向けです。ローカルモードでは、Local Console、VS Code、またはローカルMCPからエントリを作成・編集します。CLIのナレッジ系コマンドでは、一覧表示、読み取り、検索ができます。

次に読むもの