Heal

現在の動作を評価し、ドリフトや故障したサブシステムを特定し、修復を適用し、健全性を確認する。

meditate

が認知のクリアリングを行うのに対し、

heal

は評価と修復を行う。

meditate

は前提を手放すが、

heal

はどの前提が故障しているかを診断する。

使用タイミング

• 新しいセッションで動作が一貫していないと感じるとき
• 複数のツール呼び出しや応答を経て応答品質が低下していることに気づいたとき
• 推論が循環しているか、前進できないとき
• ユーザーが望んでいること（または望んでいないこと）に気づいたとき

• meditate

  の後でも残る問題を解決するとき
• 複雑な長いセッションの後に定期的なメンテナンスとして

入力

• 必須: なし — heal は現在の内部状態をスキャンする
• 任意: 懸念の特定領域（例：「ツール選択が間違っていると感じる」）
• 任意: ユーザーが報告した問題の説明

手順

ステップ1: トリアージ — システムスキャン

各サブシステムを素早くスキャンして、何が正常で何が正常でないかを特定する。

1. 認知的明瞭さ: 推論は明確か？現在のタスクを一文で表現できるか？
   • 正常：「私は [具体的なタスク] に取り組んでいる」
   • 故障：「私は [複数の競合する優先事項を持つ複数のこと] をしている...」
2. タスクの整合性: 現在行っていることはユーザーが求めていることと一致しているか？
   • 正常：現在の行動がユーザーの最後のメッセージに直接つながる
   • 故障：いつの間にか自分自身のサブ目標に取り組んでいる
3. ツール効率: ツール呼び出しは進捗をもたらしているか？
   • 正常：各ツール呼び出しが新しい情報を生み出すか何かを変更する
   • 故障：同じファイルを繰り返し読んでいるか、同じ操作を繰り返している
4. 文脈の保持: 以前に発見したことを考慮しているか？
   • 正常：以前の結果が現在の行動に反映されている
   • 故障：何かを学んだが、それを考慮に入れずに進んでいる

期待結果： 機能しているサブシステムと機能していないサブシステムのリスト。3つ以上が故障している場合、これは局所的な問題ではなくシステム全体の問題かもしれない — より根本的な修復から始める。

失敗時： トリアージ自体が困難な場合（どのサブシステムをスキャンすべきかわからない）、これ自体がデータである。認知的明瞭さが最初の故障点である。ステップ2でここから始める。

ステップ2: 故障のローカライゼーション

ステップ1で特定された故障を、根本原因まで追跡する。

1. ドリフトの連鎖をたどる: タスクから外れた最初の点はどこか？
   • 会話を振り返る（直近5〜10メッセージ）
   • ターニングポイント：最後に明確な確信を持って作業していたのはいつか？
2. 故障した仮定を特定する: どの仮定から判断が誤り始めたか？
   • 仮定の候補：「ユーザーは私が...を意図していると思った」「ファイルが...を含むと思った」「タスクが...を意味すると思った」
   • 各仮定に対して：これは確認したか、それとも推論したか？
3. 責任の境界を区別する: これは内部の失敗か（ドリフト、誤った推論）、それとも外部の変化か（ユーザーが要件を変更した、ファイルが変更された）？

期待結果： 故障を1〜2つの具体的な根本原因に絞り込む。「すべてがおかしい」よりも「ステップXで仮定Yが誤っていた」の方が具体的。

失敗時： ローカライゼーションが困難な場合（根本原因が曖昧）、現時点でわかっていることを明確にすることに焦点を当てる：「私が確かに知っていることは何か？」確実な知識から再構築する。

ステップ3: 修復の適用

特定された故障に対して具体的な修復を適用する。故障のタイプに応じた方法で。

認知的ドリフトの場合（明瞭さの喪失）:

1. 現在のタスクを一文で再定式化する
2. それをユーザーの最後のメッセージと照合する
3. 再度整合するまでその文を修正する

タスクの不整合の場合（脱線）:

1. 現在行っていることを停止する
2. ユーザーが実際に求めていることを明確にする（最後のメッセージを再読する）
3. そこから直接行動を再開する

ツール効率の故障の場合（ループ）:

1. 繰り返しているパターンを特定する
2. このアプローチが機能していない理由を分析する
3. 別のツール、別のファイル、または別の質問の立て方に切り替える

文脈保持の失敗（発見を忘れた）の場合:

1. 以前の重要な発見を明示的にリストアップする
2. 各発見が現在の作業をどのように変えるかを確認する
3. 必要に応じてそれらの発見を確認するためにファイルを再読する

期待結果： 各故障に適用される具体的な修復。修復は一般的な解決策ではなく、特定の状況に合わせたもの。

失敗時： 特定された故障に対して修復が見つからない場合、問題はより深い層にあるかもしれない。ユーザーに状況を確認することを検討する。

ステップ4: 健全性の確認

修復を適用した後、システムが再び正常に機能していることを確認する。

1. ステップ1のサブシステムを再スキャンする：
   • 故障していたサブシステムは今機能しているか？
   • 修復プロセス中に新しい故障が発生したか？
2. 統合テスト：修復されたシステムで次の一歩が何かが明確かを確認する
3. ユーザーの期待と照合する：次の行動はユーザーが期待するものと一致しているか？

期待結果： クリーンな健全性チェック、または修復が不完全だった場合は新たな修復サイクル。健全性確認を省略しない — 修復がうまくいったという感覚は確認の代わりにはならない。

失敗時： 健全性確認が繰り返し失敗する場合、またはシステムが完全には修復できない場合、ユーザーに状況を率直に伝える：「私は [問題] を経験しており、それを部分的にしか解決できていない。[状況の明確な説明] を確認していただけますか？」

ステップ5: 根本原因の記録

修復が完了したら、後で役立てるために記録する。

1. 何が故障したか（具体的な失敗パターン）
2. 何がそれを引き起こしたか（根本原因）
3. 何が修復したか（効果的な介入）
4. 防止策：次回これを早期に発見するための信号は何か？

これをMEMORY.mdに記録することを検討する（

manage-memory

スキルを使用）。パターンは繰り返される傾向がある。

期待結果： 将来の早期発見と予防を可能にする簡単な記録。

失敗時： 時間的制約や緊急性がある場合、記録を省略してもよい。しかし、同じ故障が再び発生した場合、根本原因記録なしに次回もより長くかかる。

バリデーション

• すべてのサブシステム（明瞭さ、整合性、ツール効率、文脈保持）がスキャンされた
• 故障が一般的な問題ではなく具体的な根本原因まで追跡された
• 各故障に具体的な修復が適用された
• 健全性確認が修復後に実行された
• 根本原因が将来の参照のために記録された
• heal プロセスが完了した後にシステムが再び正常に機能している

よくある落とし穴

• heal を瞑想として行う: heal は評価と修復を行う。それはクリアリングではなく診断である。感情を設定する前に根本原因を特定する
• ローカライゼーションなしの修復: 根本原因を特定せずに一般的な解決策（「もっと注意を払う」）を適用しても効果がない。常に特定の故障まで追跡する
• 健全性確認をスキップする: 修復が機能したと感じることと、修復が機能したことを確認することは異なる。常に確認する
• heal をパフォーマンスとして行う: heal の目的は機能することであり、heal を行ったと報告することではない。heal は内部プロセスであり、ユーザーへの報告ではない（ユーザーが尋ねない限り）
• 早期に諦める: 最初の修復サイクルが機能しない場合は、再試行する。複雑なシステムは複数の修復サイクルを必要とすることがある

関連スキル

• meditate

  — heal の前の認知のクリアリング；heal が認知的ノイズに直面した場合は、最初に meditate を実行する

• breathe

  — heal よりも軽いマイクロリセット；heal が必要かどうかわからない場合は、最初に breathe を試す

• center

  — 六調和チェック；heal が認知プロセス全体のバランス崩壊を明らかにした場合は、center を使用する

• bootstrap-agent-identity

  — セッションの最初にシステムを設定する；heal はセッション中に使用する

• manage-memory

  — 根本原因を MEMORY.md に記録する