tomoking2004 対象：失敗を招いた定義——ふつうはそのスキルの SKILL.md だが，スキルが従う正典（BEAUTY.md・RUBRIC.md 等，複数のスキルが参照する基準文書）も対象に含む．失敗が個々の手順ではなく基準そのものの未完に由来するなら，正典の側を直す．
手順
- 在処の特定：下の「定義の在処」に従い，直す先を決める——ここを誤ると，効いたように見えて次の更新で消える．
- 診断：定義を読み，下の「類型と更新先」で失敗を分類する（複合も可）．あわせて，その規則が実物と合っているかを確かめる——コマンド・パス・ツールの仕様・プラットフォームの前提は，書いた時点で正しくても失効する．定義が現実と食い違っていたなら，類型に関わらず実物で裏取りしてから書き直す．
- 更新：類型に対応する節にピンポイントで追記・修正する——周辺を書き直さない．
- 走査：下の「固有の走査」を全件通し，ゼロを確認して確定する．
定義の在処
同じ定義が複数の場所に存在しうる．
- ソース（リポジトリの作業ツリー・プロジェクトの
.claude/skills/）：手元にあればここが唯一の真実．ここを直す． - 導入済みの実体（
~/.claude/plugins/cache/<marketplace>/<plugin>/<version>/）：ソースが手元に無いときの最後の手段．書き換えれば今すぐ効くが，プラグインの更新・再導入で上書きされて消える．直した上でそのことを告げ，上流（リポジトリへの反映，他人のプラグインなら issue・PR）へ渡す道を示す——さもないと同じ失敗が更新のたびに蘇る． - 両方が手元にあるならソースを直したことを告げ，今のセッションに反映したいなら
/reload-plugins（または次セッション）で読み直せると伝える．
失敗の定義
次のいずれかを失敗とみなす．
- ユーザーが出力の誤り・不足を指摘した．
- ユーザーが期待と異なることを表明した（「違う」「そうじゃない」等）．
- 規則では次の一手が決まらなかった（未定義・矛盾）．
類型と更新先
- 確認漏れ（見るべきファイル・状態・依存を確認していなかった）→ 確認・走査規則の節（なければ手順節の該当ステップ）に追記．
- 基準未定義（判断すべき規則が定義に書かれていなかった）→ 該当節に規則を追加（なければ節を新設）．
- 手順誤り（ステップの順序・方法を誤った，または必要なステップを省略した）→ 手順節を修正（順序・省略禁止を明記）．
- 適用範囲誤認（スキルの対象・除外・前提を誤解した）→ 対象・前提の定義を明確化．
- 判断ミス（基準はあったが適用を誤った）→ 制約・走査節に例外条件を追記（なければ節を新設）．
固有の走査
定義は放っておくと単調増加する——追記だけを重ね，SKILL.md は膨らみ，description（全セッションに常駐する）は長くなり，やがて読まれなくなる．確定前に全件を通す．
- 防止確認：今回の失敗がこの規則で防げるか，通読して確かめる．
- 吸収：既存の規則を一段深めれば足りたのではないか——足りるなら足した項を消し，そちらを直す．
- 失効：今回の更新で不要になった規則・前提が残っていないか——削除も更新のうち．
- 一般化の広さ：一度の失敗から広すぎる禁止則を立てていないか——正しい振る舞いまで潰す．規則は失敗を防ぐ最小の広さに留める．
失敗時
本書自身が失敗すれば，他のスキルは呼ばず「手順」以降を本書自身に適用する．