context-drift

Context Drift

リポジトリ内の重要なコンテキストファイルに生じたずれを、詳細を失ったり、それぞれの境界を曖昧にしたりせずに監査または修復するには、このスキルを使用してください。

このスキルが読み込まれ、残りのターンに人が作成したタスク文が含まれていない場合（診断やコンテキストに関するメッセージなど、自動生成されたシステムまたはツールの通知だけが含まれている場合も含む）、対応すべきことが何もないと判断しないでください。スキルが読み込まれたこと自体が依頼です。このドキュメントの既定値を使って、現在のリポジトリを対象にステージ 1 を直ちに開始してください。待ったり、このスキルが利用可能であることを伝えるだけにとどめたり、何に取り組むかを尋ねたりしないでください。

権限モデル

このスキルはオーケストレーターであり、各ファイルに何が属するかを最終的に決定するものではありません。

ずれを判断する前に、対象となるファイルに対応するオーナースキルを呼び出すか読み込み、最初に適用してください。どの内容をどこに置くかの判断では、それぞれのスキルが定める関心事の分離ルール、ファイル固有のガードレール、ドキュメントの所有権に関するロジックを優先します。このスキルは、ファイル間の比較、情報を失わない移動計画、承認のループを調整します。独自にファイルの所有権を判断したうえで、最後になってオーナースキルを適用してはなりません。

2 つのオーナースキルの指針が異なる場合は、このスキルでどちらかを覆すのではなく、ユーザーにその矛盾を提示してください。

正規の所有権モデル

何かを冗長、配置違い、または古いと判断する前に、この所有権モデルをルーティングマップとして使用してください。これは各オーナースキルへの簡易インデックスであり、その判断に取って代わるものではありません。

ファイル	中心となる問い	ここに記載する内容	重要度	関連スキル
openspec/config.yaml	このプロジェクトとは何ですか？	プロジェクトの特性、技術スタックの情報、構造上のデフォルト、成果物のルール	重大	accelint-onboard-openspec
ARCHITECTURE.md	このシステムはどのように構築されていますか？	システム構造、コンポーネント、デプロイ、データフロー、技術的なトポロジー	重要	accelint-architecture-doc
AGENTS.md / CLAUDE.md	エージェントはここでどのように振る舞うべきですか？	エージェントのワークフロー、承認の境界、コミュニケーションルール、リポジトリ固有の作業規範	重大	accelint-onboard-agents
CONSTRAINTS.md	なぜ一部の選択肢は変更できないのですか？	コンプライアンス、セキュリティ、ステークホルダー、ベンダー、ホスティング、スコープの境界など、外部からの制約	重要	constraints-extractor
EPISTEMIC-MAP.md	どの程度確かな情報ですか？	検証済みの事実、未解決の疑問、前提、推測されるリスク	重要	epistemic-mapper
JARGON.md	これらの用語は何を意味しますか？	用語集の項目、頭字語、内部用語、略記の定義	補助	jargon-extractor
README.md	人間はどのように使い始めればよいですか？	人間向けのオンボーディング、インストール・実行・使用の基本、プロジェクトの対外向け紹介	重要	accelint-readme-writer

あるファイルから別のファイルへの短い参照は、多くの場合適切です。内容を完全に重複させるのは、たいてい適切ではありません。たとえば、AGENTS.md で、デプロイ作業の前にエージェントが ARCHITECTURE.md を読むよう指示できます。しかし、デプロイのトポロジー自体は AGENTS.md ではなく、ARCHITECTURE.md に記載します。

JARGON.md の役割は、他のファイルとは異なります。その役割は、プロジェクト全体で使われる用語を、辞書の項目のように短く簡潔に定義することだけです。したがって、JARGON.md と他のファイルの内容が多少重複するのは想定内であり、内容の逸脱ではありません。他の正規ファイルでは、そのファイル本来の役割に必要であれば、同じ用語を詳しく説明してかまいません。たとえば、JARGON.md が一行で定義する内容について、ARCHITECTURE.md で技術的な全体像を詳しく説明しても、それは重複ではありません。詳細なリファレンスと用語集の説明は、役割が異なるためです。この制約が適用されるのは JARGON.md に対してであり、他のファイルに対してではありません。つまり、JARGON.md 自体は簡潔なままにする必要があります。JARGON.md の項目が短い定義の範囲を超え、その詳細を実際に扱う正規ファイルと同じ深さの説明を含むようになったら、それが修正すべき逸脱です。修正するには、他のファイルを削るのではなく、JARGON.md の項目を短くします（必要に応じて、詳しい説明のある場所を示します）。

絶対にしてはいけないこと

• 移動先がわかる前に、コンテンツを削除してはいけません。 文があるファイルからなくなる場合は、正規の配置先に移すか、簡潔な案内に置き換えるか、そのまま残してください。
• 移動を簡単にするために、詳しい記述を曖昧な要約に変えてはいけません。 「損失がない」とは、運用上の意味が同程度の詳細さで保たれることです。
• 同じ概念が2つのファイルに記載されているというだけで、冗長と判断してはいけません。 CONSTRAINTS.md を参照する動作ルールは、制約そのものを再記述することとは異なります。
• 同じトピックを異なる詳細度で扱う2つのセクションを、重複と分類してはいけません。 すばやく全体を把握するための短い概要と、技術的な詳細を網羅した完全なリファレンスは、同じサブシステムを説明していても同じ情報ではありません。厳選された例は網羅的な表の重複ではなく、概念図は構造図の重複ではありません。完全一致または言い換えによる重複と判断する前に、隣接するトピックであるというだけでなく、情報として実際に等価であり、一方を変更するともう一方も古くなる、両ファイルの具体的な箇所を示してください。README.md は特に誤りやすいファイルです。ほかの場所にあるコンテンツを圧縮して紹介するのは、本来の役割であって、内容のずれを示す兆候ではありません。
• JARGON.md と別のファイルとの重なりを、最初から重複と見なしてはいけません。また、別の場所にある詳しい説明が問題だと決めつけてはいけません。 JARGON.md の役割は、簡潔な用語定義を一元管理することだけです。そのファイルで定義された用語をほかのファイルで参照することは、各ファイルの役割に必要であれば、詳しく説明する場合も含めて想定内であり、内容のずれではありません。制約が課されるのは逆方向です。JARGON.md 自体は簡潔に保つ必要があります。JARGON.md の項目と別ファイルの説明が同じ内容になってしまっている場合は、詳しい説明を担うべきファイルを短くするのではなく、JARGON.md の項目を簡潔な定義に戻してください。
• 関連するオーナースキルで判断できる場合、このスキルだけを根拠にファイルの所有権を決めてはいけません。 まずオーナースキルを読み込み、その基準を判断の根拠にしてください。
• 変更が機械的に見える場合でも、このスキルから直接編集して承認済みの変更を適用してはいけません。 承認された提案はすべて、該当するオーナースキルを通じて実行してください。
• ユーザーが提案ごとの承認を求めている場合、確認を挟まずに整理作業全体をまとめて適用してはいけません。 変更案を一つずつ提示し、承認／却下／相談の返答を待ってください。
• その場で新たな正規の配置先を作ってはいけません。 コンテンツは既存ファイルの目的に沿って配置するか、適切な配置先のファイルが存在しないことを明示してください。
• 監査範囲を黙って広げてはいけません。 ユーザーが5つのファイルについて依頼した場合、新しいファイルが明らかに必要であり、その理由を説明するまでは、最初の確認対象をその5つに限定してください。
• 都合を文書の所有権より優先してはいけません。 適切な配置先は、文を残しやすい場所ではなく、関連するオーナースキルに基づいて決めてください。
• 「監査して適用する」という既定の流れを、ステージ6のゲートを経ずにファイルへ書き込む許可と見なしてはいけません。 この既定の流れが決めるのは、課題一覧の作成後に変更計画の策定まで続けるかどうかだけです。差分プレビューを示し、明示的な承認を得ずに変更計画を書き込んでよいという意味ではありません。承認／却下／相談への返答が得られない場合は、ゲートの段階で停止してください。本人に代わって自己承認してはいけません。

監査の前に、デフォルトを適用する

ユーザーにこれらの質問をしてはいけません。各項目について、ユーザーがすでに回答を指定しているか確認してください。指定がない場合はデフォルトを適用して進めてください。

1. 監査のみか、監査して適用するか？
   • ユーザーが「今回は確認だけ」などと述べている場合は、問題一覧の提示後に終了します。
   • デフォルト：監査して適用します。ここでいう「適用」とは、問題一覧の提示後も Stage 5 の変更計画と Stage 6 の差分プレビューまで進むことです。Stage 6 の承認／却下／協議のゲートで実際に回答を得る前にファイルを書き込むことではありません。このゲートは省略できず、ユーザーが一つずつ進める手順を求めているかどうかにも左右されません。
2. 対象範囲を指定するか、デフォルトの標準セットを使うか？
   • ユーザーが特定のファイルを指定した場合は、そのファイルを対象にします。
   • デフォルトのセット：AGENTS.md、CLAUDE.md、ARCHITECTURE.md、CONSTRAINTS.md、JARGON.md、EPISTEMIC-MAP.md、README.md、openspec/config.yaml
3. 情報を損なわない移動のみか、より広範な整理も行うか？
   • ユーザーがより広範な整理を求めた場合は、その要望に従います。
   • デフォルト：情報を損なわない移動のみです。
4. 移動先の文書がない場合、報告のみとするか、作成／更新も行うか？
   • ユーザーが文書の作成または更新を明示的に求めた場合は、その要望に従います。
   • デフォルト：まず報告し、承認を得た場合にのみ作成します。

ユーザーが回答していない項目について、適用するデフォルトを明示してください。作業を始める前に、前提が分かるようにします。

ワークフロー

以下のステージを順番に進めてください。

Stage 1: 対象範囲を定め、実際のソースを読む

1. 上記のデフォルトを適用し、ユーザーがすでに指定した対象範囲があれば反映して、対象ファイルを決定します。確認のためにユーザーへ質問して作業を止めてはいけません。
2. 重複を判断する前に、対象となるすべてのファイルを最後まで読みます。
3. AGENTS.md と CLAUDE.md の両方がある場合は、独立した情報源として扱う前に、片方がもう片方へのポインタースタブかどうかを確認します。
4. ファイルが存在しないこと自体を情報のずれとみなしてはいけません。別のファイルに明らかにそのファイルに属する内容が含まれている場合にのみ、関連事項となります。
5. 監査対象のファイルセットを明示します。

Stage 2: オーナースキルのレビューにサブエージェントを使用する

サブエージェントを利用できる場合は、ここが最初に活用すべき重要な場面です。

対象範囲内のオーナーとファイルの組み合わせごとに、サブエージェントを1つ起動します。各サブエージェントは次の作業を行います。

1. 該当するオーナースキルを読み込む
2. 担当ファイルを最後まで読む
3. オーナースキル独自の文書所有権とガードレールの基準に従って、そのファイルを評価する
4. 長い文章の記録ではなく、簡潔で構造化された指摘だけを返す

最低限、レビュー対象の各ファイルについて、オーナースキルによるレビューを1回実施します。内容の移動先となる可能性が高いファイルについては、その移動先のオーナースキルもレビューに含めます。

以下については、これらのオーナースキルのサブエージェントを権威ある判断元として扱ってください。

• 各文書に属する内容
• 適切なポインター動作と不適切な重複の区別
• 情報を損なわない移動で維持すべき詳細度
• 移動する内容を移動先文書のどこに置くべきか

ルーティングマップは、起動するオーナースキルを決める目的に限って使用してください。このスキルの概要表を、オーナースキル自身の判断の代わりにしてはいけません。

親コンテキストは簡潔に保ってください。各レビューサブエージェントから返す内容は、後続のステージで必要なものだけにしてください。

• 指摘 ID またはローカル指摘 ID
• 現在のファイルと場所
• 情報のずれの疑いがある種類
• 正規の配置先候補
• 根拠となる短い抜粋
• 指摘の根拠となるオーナースキルのルールまたは境界についての短い説明
• 他のオーナースキルとの不確実性や競合

同じ指摘をまとめ直すだけの第2波の整理用サブエージェントを起動してはいけません。簡潔な指摘セットは、親コンテキスト内で統合してください。

サブエージェントを利用できない場合は、オーナースキルをインラインで呼び出すか読み込みます。ただし、同じ手順を守り、情報のずれを判断する前にオーナースキルを参照し、後続のステージには簡潔な指摘のみを引き継いでください。

ステージ 3：ドリフトの種類を特定する

各オーナースキルの判断に基づき、編集を提案する前に各問題を分類します。

ドリフトの種類	意味	典型的な修正
完全な重複	異なる役割もないのに、同じ情報が 2 か所に記載されています	正式な記載を残し、もう一方は参照先に置き換えるか、移動後に削除します
言い換えによる重複	同じ内容が、表現を少し変えて繰り返されています	正式な記載にまとめ、他の場所には動作に影響する参照だけを残します
不適切な配置	記述が誤ったドキュメント階層にあります	適切なファイルに移動し、必要に応じて簡潔な参照を残します
矛盾	2 つのファイルで、同じ事実について互いに両立しない内容が記載されています	両方を提示し、ひそかに一方を選ばないでください。編集前に確認するか、検証を依頼します
配置先の欠落候補	あるファイルに、正しい配置先となるファイルがまだ存在しない内容が記載されています	該当内容を報告し、正式なファイルを新規作成または更新するか確認します
参照の欠落	あるファイルでは、正式なドキュメントの内容を繰り返すのではなく、そのドキュメントを参照する必要があります	元の内容を重複させず、参照を追加します

完全な重複または言い換えによる重複と判定する前に、各ファイルの重複する箇所を引用し、左右に並べてください。一方が、要約対象となる完全なリファレンスに対する簡潔な概要（例が少ない、図が単純、集計数が示されているなど）である場合、これは重複ではありません。同じサブシステムを扱っていることと、同じ情報を含んでいることは別です。2 つの箇所を常に連動して変更する必要がある場合に限り、重複と分類してください。

ステージ 4：検証のみの調査結果を先に提示する

ユーザーが検証のみを依頼した場合は、ここで終了します。

問題を簡潔な箇条書きで、次の項目とともに報告します。

• 問題 ID
• 現在の場所
• 正式な配置先の提案（該当するオーナースキルに基づく）
• ドリフトの種類
• ドリフトである理由
• 正確な抜粋または範囲を絞った要約

この段階では、修正を指示せず、記述に徹してください。目的は、修正方法を決める前に、何が問題なのかを示すことです。現在の配置がドリフトに当たる根拠となるオーナースキルの境界またはルールを明確にしてください。

ステージ 5：情報を損なわない変更計画にまとめる

各問題について、オーナースキルに裏付けられた調査結果を具体的な移動内容に落とし込みます。

次の形式を使用します。

提案	操作	移動元	移動先	情報保持の確認
P1	移動／統合／参照／変更なし	元のファイル + セクション	移動先のファイル + セクション	変更後に同じ詳細がどこに記載されるかを説明します

削除または短縮する場合は、残す内容をどこに置くのかを必ず明記してください。その配置先を示せない場合、変更はまだ情報を損なわないものとはいえません。

ステージ 6：差分プレビューを使って提案を 1 件ずつ確認する

このステージは、監査と適用のどちらを既定とするかにかかわらず、またユーザーが 1 件ずつ確認するよう明示的に依頼したかどうかにかかわらず、すべてのモード、すべての提案で必須です。調査結果からファイル編集に直接進める提案はありません。ユーザーが提案を 1 件ずつ確認するよう依頼した場合も、ここに記載された手順で進めます。次の提案に進む前に、1 件ずつ提示し、判断を待ちます。

このターン中に以下のプロンプトに応答できる人がいない場合（たとえば、スキルが追加のタスク指示なしで呼び出された場合）、提案と差分プレビューを提示し、承認／拒否／相談のプロンプトで終えて、そこで停止します。人から応答がないことを承認とみなしてはいけません。

各提案について、次の手順に従います。

1. 根拠を 1 段落で説明します。
2. 影響を受けるすべてのファイルについて、git diff 形式のプレビューを示します。
3. はっきりとしたプロンプト 承認／拒否／相談 で終えます。
4. 次の提案に進む前に、応答を待ちます。

次のようなプレビューを使用します。

--- AGENTS.md
- Deployment topology: API runs in ECS behind ALB, worker runs on Fargate...
+ Read `ARCHITECTURE.md` before changing deployment-related code.

--- ARCHITECTURE.md
+ Deployment topology: API runs in ECS behind ALB, worker runs on Fargate...

提案が参照の追加だけの場合は、そのファイルのみを示します。3 つのファイルを変更する場合は、移動によって情報が本当に損なわれないことをユーザーが確認できるよう、3 つすべてをまとめてプレビューします。

ステージ 7：適用パスでサブエージェントを使用する

サブエージェントを利用できる場合、ここが2つ目の主な活用場面です。

ステージ 7 は、ステージ 6 で提案が実際に承認された後にのみ開始します。「監査して適用」だけの指示を直接引き継いで開始してはいけません。このスキルから直接編集して、承認済みの提案を適用しないでください。変更が機械的に見える場合も同様です。

影響を受けるファイルごとに、該当するオーナースキルのサブエージェントを起動し、承認済みの提案、保持すべき正確な内容、他のファイルに必要なポインターや削除の動作を渡します。承認された範囲を保ちながら、自身の正規ドキュメントに変更を反映する方法は、オーナースキルのサブエージェントに判断させます。

1つの提案が複数のファイルに影響する場合、その提案に必要なオーナースキルのサブエージェントをすべて起動します。承認された移動内容をそれらの間で同期し、どのサブエージェントにも承認済みの範囲をひそかに広げさせないでください。

承認ループとファイルオーナーの適用サブエージェントの間に、提案を再構成したり適用内容を絞り込んだりするサブエージェントを追加で挟まないでください。ユーザーが提案を承認したら、親の承認状態から該当するオーナースキルの適用サブエージェントへ直ちに進みます。

サブエージェントを利用できない場合は、オーナースキルをインラインで呼び出し、それでもオーナースキルが変更を適用するというルールを守ります。オーケストレーター自身が単独で適用してはいけません。

例：

Invoke the accelint-onboard-agents skill.

Apply the approved change below to AGENTS.md only.
Remove the architecture detail from AGENTS.md, keep a short behavior-level pointer, and preserve the original meaning without widening scope.

Invoke the accelint-architecture-doc skill.

Add the approved deployment-detail block into ARCHITECTURE.md at the correct architectural section. Preserve the existing structure and keep the imported detail at the same level of specificity.

次のルーティング表を使用します。

• AGENTS.md / CLAUDE.md → accelint-onboard-agents
• openspec/config.yaml → accelint-onboard-openspec
• ARCHITECTURE.md → accelint-architecture-doc
• CONSTRAINTS.md → constraints-extractor
• EPISTEMIC-MAP.md → epistemic-mapper
• JARGON.md → jargon-extractor
• README.md → accelint-readme-writer

ステージ 8：変更内容と、引き続き対応が必要な事項を要約する

承認済みの変更を適用した後、次の内容を報告します。

• 承認、却下、または未決の各提案
• 変更されたファイル
• 未解決のドリフト問題
• 作成が必要な正規ファイルがまだあるかどうか

出力モード

リクエストに合う最も軽いモードを選択します。

1. 監査モード

ユーザーが「確認」「検証」「監査」「問題の一覧表示」と述べた場合に使用します。

出力：

• 対象ファイル一覧
• 問題の一覧のみ
• 編集なし

2. 変更計画モード

ユーザーが「X を Y から Z に移動」のような項目別のガイダンスを求めている場合に使用します。

出力：

• 問題の一覧
• 提案表
• まだ編集しない

3. 対話型適用モード

ユーザーが変更を一つずつ承認したい場合に使用します。

出力：

• 提案ごとの差分プレビュー
• 承認／却下／相談のループ
• 承認された提案のみを適用

重要な注意事項

• 該当するオーナースキルは、調査結果をまとめてからではなく、タスクの早い段階で読み込みます。
• サブエージェントを利用できる場合、オーナースキルによるレビューと、オーナースキルによる適用の2か所でのみ使用します。
• 同じ調査結果を不要な整理役や提案作成サブエージェントに渡し直さないよう、ステージ 3 からステージ 6 までは親のコンテキストで進めます。
• このスキルはドキュメント間の比較と承認を調整するものであり、ファイル固有の判断においてオーナースキルに取って代わるものではありません。
• ファイルの読者の行動を変えるだけでよい場合は、重複よりポインターを優先します。
• 妥当な移動のうち最小のものを優先します。ドキュメント間のドリフト確認を、大幅な書き換えの口実にしてはいけません。
• 2つのファイルで事実が食い違っている場合は、整理の機会ではなく、解決すべき矛盾として扱います。
• ユーザーが AGENTS.md、ARCHITECTURE.md、openspec/config.yaml のように対象を限定した場合、推論モデルはそのままに、監査対象だけをその範囲に絞ります。
• ユーザーが変更の完全な保持を求めた場合、表現が変わっても、同じ運用上の詳細を維持します。