mcpField
D
damage-control

damage-control

github.com/atholaエージェントワークフロー34383 回インストール1 日前に更新
リポジトリ

damage-control について

Damage Controlは、クラッシュやコンテキスト消失、Gitの競合、セッション状態の不整合に対処するエージェント向け復旧スキルです。障害に応じた手順へ案内し、状態の検証と作業の保全を重視します。必要に応じて人による確認にも引き継ぎます。

主な機能

  1. 014種類の障害の切り分け
  2. 02クラッシュ後の確認と安全な再開
  3. 03コンテキスト超過後の判断再構築
  4. 04Git競合の分類と解決
  5. 05タスク・ディスク・インデックス状態の照合
  6. 06人による確認へのエスカレーション

活用シーン

  1. 01エージェントのクラッシュ後にファイルを復旧
  2. 02コンテキスト消失後に判断内容を再構築
  3. 03マージやリベースの競合を解決
  4. 04タスク状況とファイル・Git状態を照合

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/athola/claude-night-market --skill damage-control

インストール後、Claude Code で/damage-controlを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

modules/
context-overflow.md
crash-recovery.md
merge-conflict-resolution.md
risk-assessment-checklist.md
state-reconciliation.md

詳細

Damage Control

概要

セッション中に状態が破損したエージェント向けに、復旧プロトコルを提供します。Damage Control では、4種類の障害に対応します。ディスク上に作業の一部を残したままエージェントがクラッシュした場合、コンテキストウィンドウのオーバーフローによって状態が失われた場合、マージコンフリクトによって作業の進行が妨げられた場合、そして状態の調整が必要な一般的なセッション状態の破損です。

このスキルは障害の発生を防ぐものではありません。障害がすでに発生した後に何をすべきかを定め、復旧に一貫性と監査可能性を持たせ、作業を気づかれないまま破棄しないようにします。

使用する場合

  • エージェントプロセスがクラッシュし、ファイルが不明な状態で残っている
  • セッションがコンテキストの上限に達し、以前の判断を読み込めない
  • git merge または git rebase で、エージェントが自動的に解決できないコンフリクトが発生した
  • 観測された状態（ディスク上のファイル、タスクリスト、git インデックス）が想定される状態と一致しない
  • 後続のエージェントから、本来は前段階で作成されているはずの成果物がないと報告された

使用しない場合

  • 作業開始前の予防的なリスク評価（代わりに Skill(leyline:risk-classification) を使用してください）
  • 障害発生後の戦略的なアーキテクチャ上の判断（代わりに Skill(attune:war-room) を使用してください）
  • 単一のツール呼び出し内での通常のエラー処理（代わりに Skill(leyline:error-patterns) を使用してください）

Damage Triage

適切なモジュールを選ぶには、次の判断ツリーを使用してください。

flowchart TD
    A[Failure detected] --> B{Agent process crashed\nor exited unexpectedly?}
    B -->|Yes| C[modules/crash-recovery.md]
    B -->|No| D{Context limit hit or\nprior decisions unavailable?}
    D -->|Yes| E[modules/context-overflow.md]
    D -->|No| F{git merge / rebase /\ncherry-pick conflicts?}
    F -->|Yes| G[modules/merge-conflict-resolution.md]
    F -->|No| H{State internally inconsistent?\ntask list vs disk vs git index}
    H -->|Yes| I[modules/state-reconciliation.md]
    H -->|No| J[No damage-control needed]

複数の障害種別が重なっている場合は、まず state-reconciliation.md を使って既知の基準状態を確立し、その後で 個別の障害種別に対処してください。

リスク評価チェックリスト

レベル 1 以上のタスクを実行する前に、 modules/risk-assessment-checklist.md のリスク評価チェックリストを完了してください。次の 5つの質問に回答します。

  1. 本番環境で何が失敗する可能性がありますか？ 具体的な障害 シナリオを挙げてください。
  2. どのようにすれば迅速に検知できますか？ 監視、アラート、 ログ。
  3. 最も迅速で安全なロールバック方法は何ですか？ 手順を 段階ごとに記載してください。
  4. この計画を無効にする可能性がある依存関係は何ですか？ 外部 依存関係。
  5. 最も確実性が低い前提は何ですか？ 計画の最も弱い部分。

レベル 1（監視）以上で必須です。テンプレート全体と 例については、modules/risk-assessment-checklist.md を参照してください。

モジュールの参照

  • crash-recovery.md：エージェントのクラッシュ後のトリアージ、チェックポイントの調査、安全な再開またはロールバック。
  • context-overflow.md：コンテキストウィンドウが上限に達した際に、判断に必要なコンテキストを再構築する手順。
  • merge-conflict-resolution.md：人によるレビューへのエスカレーションを含む、git コンフリクトの分類と解決方法。
  • state-reconciliation.md：タスクリスト、git インデックス、ディスク上の成果物の間で異なる状態を調整するためのプロトコル。
  • risk-assessment-checklist.md：レベル 1 以上のタスクを実行する前のチェックリスト。

統合パターン

# In your skill's frontmatter
dependencies: [leyline:damage-control]

障害種別を特定したら、該当するモジュールを呼び出します。

# Crash detected
Skill(leyline:damage-control) → modules/crash-recovery.md

# Context limit reached
Skill(leyline:damage-control) → modules/context-overflow.md

複数のエージェントを管理するオーケストレーターは、障害の有無にかかわらず、セッションの境界で state-reconciliation を呼び出してください。これにより、次の作業フェーズを開始する前に、検証済みのチェックポイントを確立できます。

終了条件

  • エージェントの状態が明確に把握されている（状態不明の部分的な書き込みがない）
  • git インデックスがクリーンであるか、すべてのコンフリクトが解決されている
  • タスクリストに、すべてのタスクの実際の完了状況が反映されている
  • 後続のエージェントが必要とするすべての成果物が存在し、検証されている
  • ロールバックを実施した場合、ロールバックがコミットされ、取り消した範囲がタスクリストに記録されている
  • 人によるレビューへのエスカレーションが必要だった場合、セッション終了前にエスカレーション記録が作成されている

コメント

Markdown 対応