oops について
ユーザープロジェクトと Noodle 内部のインフラ障害を調べるスキルです。再現、診断、修正、検証、コミットの順に進め、コードより先に状態と環境を確認します。
主な機能
- 01障害の再現とエラー記録
- 02プロジェクト状態と設定の確認
- 03環境と永続ファイルの調査
- 04根本原因への対処
- 05修正と関連テストの検証
- 06根本原因を示すコミット
活用シーン
- 01停止したタスクキューの診断
- 02古い状態や設定に起因する障害の追跡
- 03インフラ修正の検証
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/oopsを入力して読み込まれたか確認します。
詳細
Oops
インフラの障害を修正します。ユーザープロジェクトのコードと Noodle 内部の状態の両方に適用されます。
修正の流れ
再現 -> 診断 -> 修正 -> 検証 -> コミット
1. 再現
失敗するコマンドを実行します。エラー出力を正確に記録します。断続的に発生する場合は、複数回実行して確認します。
2. 診断
コードより先に状態を疑います。 次の順番で確認します。
- Noodle の状態 —
.noodle/ファイル、キューの整合性、設定の妥当性 - 環境 — Go のバージョン、不足している依存関係、古いキャッシュ、tmux セッションの健全性
- 設定 —
.noodle.toml（プロジェクトルート）、.agents/skills/の構造、brain/の整合性 - 永続ファイル — ロックファイル、一時ファイル、不完全な書き込み
- コード — 状態と環境の問題を除外した後に限る
原則
- [[fix-root-causes]]
- [[prove-it-works]]
Noodle 内部のチェックリスト：
.noodle/の状態ファイル：破損、古さ、または不整合がないか？- キューの状態：孤立したタスク、停止したセッションがないか？
- 設定：TOML は有効か、参照先のパスは存在するか？
- tmux セッション：ゾンビプロセス、デタッチされたセッションがないか？
3. 修正
根本原因を突き止めます。症状を取り繕ってはいけません。
修正後、同じパターンをほかの箇所でも grep します。同じバグが複数の場所に存在する可能性があります。
4. 検証
最初に失敗したコマンドを実行します。成功することを確認します。関連するテストを実行して、リグレッションがないか確認します。
5. コミット
コミットメッセージには、症状ではなく根本原因を記述します。
# Good: fix(queue): stale lock file prevented task dequeue after crash
# Bad: fix: tasks not running
コメント
Markdown 対応