post-mortem
作成者 alirezarezvanipost-mortem は、実行済みの意思決定を、事前に合意した成功指標、kill criteria、実行計画、保存された反対意見に照らしてレビューするための Strategic Planning スキルです。90日チェックポイント、kill triggers、方針転換、四半期レビューのタイミングで `/cs:post-mortem <decision-path>` を使用します。
このスキルの評価は76/100で、戦略的意思決定を構造的に振り返るワークフローを求めるディレクトリ利用者にとって、有力な掲載候補です。リポジトリ上の情報から、明確なトリガー、コマンド構文、実行タイミング、必須入力、出力記録の形式が確認できるため、汎用的な post-mortem プロンプトより少ない推測でエージェントが利用できます。主な制約は、より広い C-level 意思決定パイプラインの最終ステップとして設計されているように見えることと、補助ファイルやインストール手順がないことです。
- トリガーが明確です。description と SKILL.md で `/cs:post-mortem <decision-path>` の構文と実行タイミングが示されており、90日チェックポイント、kill criteria、方針転換、四半期レビューに対応します。
- 実務で使いやすい構成です。意思決定記録、実行計画、実際の結果といった必須入力を定義し、保存可能な post-mortem record を出力します。
- エージェント活用に向いています。事前に合意した成功基準と kill criteria に照らした評価、保存された反対意見の再確認を重視しており、一般的な振り返りプロンプトより強いレビューの枠組みを提供します。
- 最適に使うには、`/cs:decide` や `/cs:execute` など関連スキルで作成した事前成果物が前提になります。そのパイプラインがない場合、入力情報を手動で整える必要があります。
- リポジトリには `SKILL.md` のみがあり、補助ファイル、参考資料、スクリプト、README、インストールコマンドは用意されていません。そのため導入時の手がかりは限定的です。
post-mortem skillの概要
post-mortem skillでできること
post-mortem skillは、実行済みの意思決定を、意思決定前に記録しておいた成功指標、撤退基準、反対意見と照らし合わせて検証するための戦略的な振り返りワークフローです。一般的な「学びの整理」プロンプトではありません。主な役割は、計画時の前提と実際の結果を強制的に比較し、戦略計画のループをきちんと閉じることです。
Strategic Planningレビューに向いているケース
このpost-mortem skillは、すでに構造化されたリズムで意思決定を運用している創業者、経営陣、chiefs of staff、プロダクトリーダー、戦略担当者に向いています。特に、価格改定、市場参入、採用計画、プロダクト上の賭け、コスト削減といった意思決定が90日レビューのタイミングを迎えたとき、撤退基準に達したとき、または四半期レビューが必要になったときに有効です。
通常の振り返りと何が違うのか
大きな違いは、事前コミットメントにあります。このskillは、意思決定記録、実行計画、実際の結果を入力として受け取り、実行前に書かれた基準に対して結果を評価します。これにより、後知恵バイアスを抑え、チームが後から成功の定義を変えてしまうことを防ぎ、反対意見を政治的な雑音ではなく証拠として残せます。
インストール前に知っておくべきこと
リポジトリのパスはc-level-advisor/c-level-agents/skills/post-mortemで、このskillはSKILL.mdに含まれています。追加のスクリプト、参照資料、補助リソースはありません。そのためpost-mortemのインストールは軽量ですが、出力品質は提供する記録の質に大きく左右されます。元の前提、しきい値、実行メモがない場合でもskillは役立ちますが、レビューの厳密さは下がります。
post-mortem skillの使い方
post-mortemのインストールと最初に読むファイル
GitHubのskillリポジトリから次のコマンドでインストールします。
npx skills add alirezarezvani/claude-skills --skill post-mortem
インストール後は、まずSKILL.mdを読んでください。ここには、コマンドの形、実行すべきタイミング、必要な入力、保存される出力パスである~/.claude/postmortems/YYYY-MM-DD-<slug>.mdが定義されています。このskillには確認すべき個別のrules/、resources/、scripts/フォルダはありません。そのため、導入判断の中心は、チームが十分な入力証拠を用意できるかどうかです。
post-mortem skillに必要な入力
post-mortemを効果的に使うには、次の3種類の入力を準備します。
- 意思決定記録: 元の意思決定タイトル、日付、オーナー、却下した選択肢、前提、成功基準、撤退基準、反対意見。
- 実行計画: マイルストーン、担当チーム、予定していた介入、タイミング、制約。
- 実際の結果: 指標、インシデント、顧客からのシグナル、売上・コストへの影響、スケジュールのずれ、定性的な証拠。
弱い入力例: 「価格改定をレビューして。」
より強い入力例: 「Q2の価格改定について/cs:post-mortemを実行して。意思決定日: 2026-04-03。成功基準: 90日目までにnet revenue retentionが108%超。撤退基準: SMBのlogo churnが6%超。反対意見: salesは年間契約が停滞すると警告していた。実績: NRR 104%、SMB logo churn 7.2%、enterprise expansion 11%増、sales cycle length +18日。」
実務で使いやすいpost-mortemワークフロー
議論がまとまらないと感じたときではなく、意思決定がレビューすべきイベントに到達したときにこのskillを使います。良いトリガーとしては、90日チェックポイント、撤退基準の発動、大きな方針転換、戦略的な賭けの四半期レビューなどがあります。
実務上の流れは次のとおりです。
- 元の
/cs:decide出力、または同等の意思決定メモを集める。 /cs:execute計画、または最も近いプロジェクト計画を添付する。- 実績指標と重要な出来事を、まだ解釈せずに追加する。
- skillにステータスを
WIN、PARTIAL、LOSS、MIXEDで評価させる。 - 事前にコミットした基準と保存された反対意見に対する明示的な比較を求める。
- 結果をpostmortemアーカイブに保存し、今後の計画精度を調整する材料にする。
より良い結果を得るためのプロンプトパターン
有用なプロンプトでは、意思決定のパス、レビューのトリガー、証拠の基準を明示します。
/cs:post-mortem <decision-path>
続けて、次のような文脈を追加します。
「実行前に存在していた基準だけを使ってください。新しい成功指標を作らないでください。証拠が不足している場合はunknownとしてください。結果スコアリング、前提監査、反対意見レビュー、意思決定品質の学び、フォローアップアクションを分けてください。」
これが重要なのは、post-mortem skillが戦略上の説明責任のために設計されているからです。「何が起きたのかを整理して」と依頼すると、やわらかいストーリーになりがちです。名前付きのしきい値に照らして評価するよう依頼すると、経営判断に使いやすい成果物になります。
post-mortem skill FAQ
post-mortem skillは経営層専用ですか？
いいえ。パスとコマンドはC-level advisorワークフローの一部ですが、基礎にある考え方は、重要な意思決定を行うあらゆるチームで使えます。プロダクトマネージャー、オペレーション責任者、スタートアップ創業者、戦略チームも、実行前に意思決定を文書化していれば活用できます。
通常のレトロスペクティブより何が優れていますか？
通常のレトロスペクティブは、チームの感覚、プロセス上の課題、広い意味での学びに焦点が当たりがちです。このpost-mortemガイドは、意思決定の質に焦点を当てます。前提は正しかったのか、成功基準は成立したのか、撤退基準は発動したのか、反対意見は失敗モードを予測していたのかを検証します。そのため、Strategic Planningやポートフォリオレビューにより役立ちます。
このskillを使うべきではないのはどんなときですか？
まだ行っていない意思決定、ブレインストーミング、測定可能な意図した成果がないプロジェクトの最初のステップとしては使わないでください。/cs:post-mortemは、実行後に証拠が得られてから使います。選択肢の間で判断する必要がある場合は、まず意思決定またはboardroom型のワークフローを使い、その後でpost-mortemに戻ってください。
初心者にも使いやすいですか？
はい。ただし、初心者がこのskillには証拠が必要だと理解している場合に限ります。元の意思決定記録を魔法のように再構築してくれるわけではありません。新規ユーザーは、完了済みの意思決定を1つ選び、元の目標と実際の結果を提供するところから始めるとよいでしょう。skillに不足している基準を特定させれば、次回以降の意思決定をより良く文書化できます。
post-mortem skillを改善する方法
元の証拠を残してpost-mortemの質を高める
品質を大きく左右するのは、元の意思決定成果物を残しておくことです。実行を始める前に、成功のしきい値、撤退基準、想定リスク、反対意見を安定した意思決定記録として保存しておきます。post-mortem skillは、記憶ではなく既存のベースラインと実際の結果を比較できるときに、はるかに価値が高まります。
よくある失敗パターンを避ける
よくある失敗には、曖昧な指標、後付けの成功定義、反対意見の欠落、ひとつの目立つ結果への過度な偏りがあります。価格決定は売上を改善する一方で継続率を傷つけるかもしれません。採用計画はポジションを埋めても、デリバリーを遅くするかもしれません。きれいな勝ち負けの物語に無理やり押し込むのではなく、skillに混在した結果としてラベル付けさせてください。
指標と文脈でプロンプトを強くする
より良いプロンプトには、日付、しきい値、オーナー、意思決定の範囲、事業上の文脈、生の結果が含まれます。「ローンチは期待を下回った」と言う代わりに、「Activation目標は35%、実績は26%。paid conversionは4.1%から5.0%に改善。onboardingに関するsupport ticketsは倍増」と提供します。これによりskillは、前提の誤りと実行上の誤りを切り分けられます。
最初の出力後に反復する
最初のpost-mortemの後は、戦略的な学びを深めるフォローアップ質問をします。
- 「最も外れていた前提はどれですか？」
- 「どの反対意見を、今後の意思決定チェックリストに入れるべきですか？」
- 「撤退基準は遅すぎた、厳しすぎた、または無視されていましたか？」
- 「次の
/cs:decide記録では何を変えるべきですか？」
これにより、post-mortemは一度きりのレポートではなく、より良い戦略計画のためのフィードバックループになります。