動かせない制約に当たったら、まずそれが指示階層のどこで注入されたものかを一次情報で特定してから打ち手を決める。典型的な優先順位は、ホストが注入するdeveloper instruction > リポジトリの設定/AGENTS > 個別スキル、で、下位の層から上位の層は上書きできない。したがって上位で課された要件を、下位のスキルやリポジトリ設定に一文を足して解除しようとしても効かない。

根本原因の取り違えにも注意する。ある要件を『製品仕様の不足』と分類していても、実体は上位ホストの運用ルールとの衝突であることがある。切り分けの手順は、(1)公開マニュアルに載る製品仕様なのか、それともこのセッションに実際に注入された指示なのかを分ける、(2)その指示がどの層に属するかを確認する、(3)リポジトリ層で解除可能か判定する。解除不能なら、対処は縮退運用に留め、根治は上位層のルール変更が必要という結論に正しく分類する。誤分類すると誤った打ち手(効かない設定変更や見当違いの機能要望)に進んでしまう。