Failure Logging(失敗履歴の記録・参照)

📋 実行前チェック(必須)

このスキルを使うべきか?

• コマンドがエラーになった?
• 試したアプローチがうまくいかなかった?
• 同じ問題で2回以上つまずいた?
• 新しいアプローチを試そうとしている?
• /compact を実行した後?

前提条件

• claude_tmp/failure_log/ ディレクトリは存在するか?
• 現在の連番範囲のファイルを把握しているか?

禁止事項の確認

• 失敗を記録せずに次のアプローチに進もうとしていないか?
• 履歴を読まずに同じことを試そうとしていないか?
• 過去の失敗DBを無視していないか?

🚨 鉄則

失敗したら記録。新しいアプローチの前に履歴を読む。

記録タイミング

• コマンドがエラーになった時
• 試したアプローチがうまくいかなかった時
• 同じ問題で2回以上つまずいた時

記録する内容

claude_tmp/failure_log/[連番範囲]-fail.md に追記:

## [連番]
- 何をしようとしたか:
- 試した手法/コマンド:
- 結果(エラー内容):
- 原因(明確な場合のみ):

記録例

## 1
- 何をしようとしたか: npmパッケージのインストール
- 試した手法/コマンド: npm install axios
- 結果(エラー内容): EACCES permission denied
- 原因(明確な場合のみ): グローバルインストールに権限不足

## 2
- 何をしようとしたか: TypeScriptのコンパイル
- 試した手法/コマンド: tsc src/index.ts
- 結果(エラー内容): Cannot find module 'express'
- 原因(明確な場合のみ): @types/expressが未インストール

参照タイミング

• 新しいアプローチを試す前
• 同じ問題に再度取り組む時
• /compact 後(コンテキストがリセットされるため)

ファイル管理

ディレクトリ構造

claude_tmp/
└── failure_log/
    ├── 1-100-fail.md
    ├── 101-200-fail.md
    └── ...

運用ルール

• 100件ごとにファイルを分割
• ファイル名: [開始連番]-[終了連番]-fail.md
• 解決したら「解決済み」とマークしてよい
• 過去ファイルも必要に応じて参照する(失敗DBとして蓄積)

解決済みマークの例

## 3 ✅ 解決済み
- 何をしようとしたか: DB接続
- 試した手法/コマンド: psql -h localhost
- 結果(エラー内容): connection refused
- 原因(明確な場合のみ): PostgreSQLサービスが起動していなかった
- 解決方法: sudo systemctl start postgresql

失敗DBの価値

• 同じ失敗を繰り返さない
• プロジェクトをまたいで参考になる
• トラブルシューティングの知識が蓄積される
• 古いファイルほど価値がある(検証済みの解決策)

🚫 禁止事項まとめ

• 失敗を記録せずに次へ進む
• 履歴を読まずに同じアプローチを試す
• 過去の失敗DBを無視する
• 「覚えているから大丈夫」と記録をサボる