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