メニュー
計画や設計に着手する前に、それが失敗した未来を想定して原因を逆算で洗い出します。一方向で失敗シナリオを列挙し、対策を提案します。「pre-mortemして」「事前に失敗要因を出して」「失敗シナリオを洗い出して」「リスクを洗い出して」「計画の穴を探して」と要望された際に必ず使用します。計画ファイルや設計書が示されたとき、着手前にリスクを確認したいと感じたら積極的に提案してください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Gitコミットを適切な粒度に分割し、有用なメッセージを付けて作成するスキル。「コミットして」「commitして」「変更をコミット」「まとめてコミット」など、コミット操作を依頼されたら必ず使う。
指定したスキルを3回繰り返し適用します。レビュー・計画・実装など、ファイルを変更するスキルに使います。「iterateで<スキル名>して」「<スキル名>を繰り返し適用して」のように使います。
既存テストをレビューして改善するスキル。「テストをレビューして」「テストを改善して」「テスト名を直して」のように頼まれたら使う。新規にテストを書くのではなく、`.claude/docs/test-implementation.md` のルール（テスト名・AAA構造・アサーション設計・テストダブル・非決定性制御・テスト間独立性・Testing Library 等のフロントエンド固有ルールまで全観点）に既存テストが沿っているかを見直す。対象は `.test.ts` / `.test.tsx` / `.spec.ts` ファイルと、テストコードブロックを含む `.md` ドキュメントファイル。
作った成果物について、ユーザーがその振る舞いと目的を確実に理解できているかを問いかけで確認します。細かな実装ではなく、何をするものか・目的にかなうかに焦点を当て、あらゆる可能性を踏まえてエージェントが判断して問いを立てます。「理解できているか確認して」「振る舞いを確認して」「目的にかなっているか見て」「作ったあとのすり合わせをして」と要望された際に必ず使用します。実装や変更が一段落したとき、作ったものの理解をすり合わせたいと感じたら積極的に提案してください。
`/compact`で要約する前に、残したい情報をユーザーに選んでもらい`/compact`の引数を組み立てます。 「compact前に整理したい」「コンテキストを圧縮したい」「/compactの引数を作って」 「会話が長くなってきたので整理したい」「重要な情報を引き継ぎたい」のように使います。
マージ済みのローカル・リモートブランチを整理するスキル。「ブランチ掃除」「マージ済みブランチを削除」「ブランチ整理」「gh poiを実行」「不要なブランチを片付けて」「リモートのブランチも消したい」「mainだけ残して」のような依頼で必ず使う。gh-poi拡張がインストール済みであることを前提とする。mainなどベースブランチは絶対に削除しない。
| name | x-pre-mortem |
| description | 計画や設計に着手する前に、それが失敗した未来を想定して原因を逆算で洗い出します。一方向で失敗シナリオを列挙し、対策を提案します。「pre-mortemして」「事前に失敗要因を出して」「失敗シナリオを洗い出して」「リスクを洗い出して」「計画の穴を探して」と要望された際に必ず使用します。計画ファイルや設計書が示されたとき、着手前にリスクを確認したいと感じたら積極的に提案してください。 |
| allowed-tools | ["Read","Glob","Grep","TaskCreate","TaskUpdate","TaskList"] |
計画・設計が失敗した未来を仮定し、その原因を逆算で列挙します。
失敗したあとで「あのとき気づいていれば」と後悔するより、今ここで最悪のシナリオを想像して対策を決めるほうがはるかに低コストで済みます。このスキルはその思考を強制的に行います。
以下の3カテゴリすべてを検討し、該当するシナリオをすべて列挙します。各カテゴリで最低1件は挙げます。1件も思いつかない場合、それは見落としの可能性が高いため、「探したが見つからなかった」と根拠つきで明記します。
| カテゴリ | 対象とする失敗 |
|---|---|
| 技術的失敗 | 実装上の制約・性能・互換性により目的が達成できない |
| 運用的失敗 | デプロイ・監視・障害対応が回らない |
| 認知的失敗 | 関係者の認識ズレ・要件の取り違え・スコープ拡大 |
1行目に「〇〇が原因で計画は失敗した」と完了形で書きます（条件法では楽観バイアスが残るため）。続けて以下の3点を記します。
| 項目 | 内容 |
|---|---|
| 兆候 | その失敗が進行中であることを示す観測可能な現象 |
| 原因 | その失敗を引き起こす要因（複数ある場合はもっとも影響が大きいものを優先） |
| 予防策 | 着手前または着手中に取れる具体的な対策（兆候を観測する仕組みを含む） |
フローを開始する前に、全ステップをTaskCreateで登録します。各ステップを開始するときTaskUpdateでin_progressへ、完了したときcompletedへ更新します。
| # | subject | blockedBy |
|---|---|---|
| 1 | 対象の計画・設計ファイルを読み込む | — |
| 2 | 失敗シナリオを列挙する | 1 |
| 3 | シナリオを書式で展開する | 2 |
| 4 | 着手前に決めておくべき対策をまとめる | 3 |
## Pre-mortem: <対象の計画名>
### 技術的失敗
〇〇が原因で計画は失敗した
| 項目 | 内容 |
|------|------|
| 兆候 | ... |
| 原因 | ... |
| 予防策 | ... |
（1件以上）
### 運用的失敗
（同上）
### 認知的失敗
（同上）
---
### 着手前に決めておくべき対策
1. ...
2. ...