majiayu000 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を無視する
- 「覚えているから大丈夫」と記録をサボる