ルール

ルールは、セッション開始時または作業が適用対象のファイルに触れた時点でモデルに渡される Markdown ファイルです。ルールは .qwen/rules/ に配置され、paths: フィールドによって後者の種類が可能になります。React コンポーネントに関するガイダンスは、Makefile を編集している間はプロンプトに含まれる必要はありません。

これらはコンテキストファイル（QWEN.md）の低コストな代替手段です。コンテキストファイルはすべてのセッションのすべてのリクエストに付帯します。Resident Context Cost を参照してください。

ルールの配置場所

それらのディレクトリ以下のすべての .md ファイルは、サブディレクトリを含め、決定論的な順序で検出されます。

ベースラインルールと条件付きルール

---
description: How we write React components
paths:
  - 'src/**/*.tsx'
  - 'src/**/*.jsx'
---
 
Components are function components. Co-locate the test beside the component.
Never reach for a global store for state one screen owns.

• paths: あり — 条件付き ルール。ツール呼び出しが glob のいずれかに一致するファイルを読み取りまたは編集するまでプロンプトに含まれず、その後セッションの残りの期間に一度だけ挿入されます。
• paths: なし — ベースライン ルール。最初のリクエストからシステムプロンプトの一部となり、コンテキストファイルとまったく同じように、すべてのターンで同じコストがかかります。

どちらのフィールドもオプションであり、frontmatter がまったくないルールはベースラインルールです。

知っておくべき詳細:

• Glob はプロジェクトルートからの相対パスに対してマッチングされ、すべてのプラットフォームでフォワードスラッシュが使用され、dotfile にもマッチします。
• シンボリックリンクは解決されるため、ツール呼び出しがリンクを使用した場合でも実パスを使用した場合でもルールはマッチします。
• 条件付きルールはセッションごとに一度だけ挿入されます。2 つ目以降のマッチするファイルで再挿入されることはありません。
• HTML コメントは送信前にルールの本文から削除されます。

拡張機能のルール

拡張機能は rules/ ディレクトリを提供でき、そのルールは条件付きでなければなりません。paths: のないルールはスキップされ、起動時にそのルール名を含む警告が表示されます。この制限がまさにその目的です。拡張機能のコンテキストファイル（contextFileName）は、拡張機能が有効なすべてのセッションのすべてのリクエストに、関連性のゲーティングなしに連結されます。ある計測セッションでは、9 つの拡張機能のコンテキストファイルが合計 9,989 トークンに達し、そのセッションが持つ常時オンコンテキストの 65% を占めました。ベースラインの拡張機能ルールは、まさにそれを別の仕組みで再現することになります。

拡張機能のルールはプロンプト内で所有者によってラベル付けされます。プロジェクト外へ上がるパスではなく charts:rules/charting.md のように表記されるため、トランスクリプトを見ればどのルールが起動したかが分かります。

これらはプロジェクトのルールとは異なり、ワークスペースの信頼に基づいてゲーティングされません。拡張機能のインストールはすでに明示的な操作であり、同じ拡張機能が MCP サーバー、コマンド、スキル、ゲーティングなしのコンテキストファイルを提供する可能性があります。コンテキストファイルよりも狭く低コストなこの仕組みに対してのみ信頼を要求することは、作成者を高コストの選択肢に押し戻すだけです。

拡張機能を作成する場合、以下の移行を行ってください:

ルール、スキル、コンテキストファイル

スキルは、モデルが選択して従う手順を置くのに適した場所です。条件付きルールは、モデルがそれに気づいていなくても、コードベースの特定の領域に適用される制約を置くのに適した場所です。スキルも paths: でゲーティングでき、関連性があるまでリストのエントリさえもプロンプトから除外されます。

関連項目

• Resident Context Cost — プレフィックスのコストを測定する方法と、その他のレバー。
• スキル
• メモリ