premortem

Premortem

Premortem は、任意の計画チャレンジ戦略です。新たなコンテキストに、実装前に、解決済みの bead または呼び出し元の意図が失敗し得る具体的な方法を特定するよう求めます。 これは必須の RPI シーケンスの一部ではなく、準備完了を認定するものでもありません。 任意のやり取り、独立性、停止ルールはPlan の共通チャレンジ手法が定め、Premortem は以下の 3 つのチェックを担当します。関連項目：一般的なアドバイスはReview、完了した変更の受け入れはValidate、複数の独立した見解はCouncilです。

チェックはこの順番で実施し、指摘事項も同じ順番で報告してください。1 番目または 2 番目のチェックでの指摘は、3 番目のチェックで挙げる単独の技術的リスクより優先されます。

1 つ目のチェック：誰が検証し、そのコンテキストは新鮮か？

技術的リスクを検討する前に、計画における証拠の構成を検証します。すべての作業単位について、誰が検証するのか、また検証するコンテキストは作成したコンテキストと異なるのかを確認してください。作成者が書いたものではない CI や既存の決定論的チェックは、独立した検証者に数えられ、通常の作業単位であればそれで十分です（Validate）。指摘となる構成は 2 つあります。1 つは、作成者が書いたチェックだけで評価される作業単位です。たとえば、「実装者が自分のテストを実行して完了とする」というクローズ手順です。もう 1 つは、Validate がコストが高いと記載しているにもかかわらず、作成者とは異なる新鮮な視点による確認がない作業単位です。それぞれの構成は 1 回だけ報告し、該当する作業単位を列挙してください。自分で評価したグリーンは、典型的な「完了したつもり」です。ほかのあらゆる失敗をひそかにリリース済みの失敗へと変えてしまうため、最優先で扱います。

2 つ目のチェック：どの手順が一方通行か？

各手順を確認し、計画から後戻りできるものには双方向、できないものには一方通行の印を付けます。一方通行の手順ごとに、正確な取り消しコスト、後戻りできなくなる時点、そしてその境界を越える際にハンドルを握るのが呼び出し元なのか、バッチ内で判断するエージェントなのかを明記してください。双方向の失敗で必要なのは再試行ですが、一方通行の失敗では対象そのものを失います。19 個の可逆な手順の後に不可逆な手順が続き、最初の 19 個で身についた反射的な判断が 20 個目にも適用されるようなケースに注意してください。

ここで名指しする失敗モードは、可逆性を主張するだけで、手順を追っていないことです。ロールバックのセクションで「完全に可逆」と書かれている一方、手順のどこかで認証情報を無効化したり、強制プッシュしたり、公開したりするケースが該当します。既存の呼び出し元の権限の範囲外にある重大な不可逆操作は指摘事項です。Plan の「誰が決めるか」では、取り消しコストと承認を扱います。事前の承認は引き続き有効であるため、境界を越えるたびに再承認を求めたり、不確かな詳細をすべて不可逆と見なしたりしないでください。停止条件：すべての手順に印があり、一方通行の印が付いたすべての手順に取り消しコストが記載されていること。

3つ目のチェック：失敗を具体的に構築する

一般的なリスク一覧からではなく、計画が当然の前提としている事柄から失敗候補を引き出してください。典型的な前提には、ツールやサービスが計画の記述どおりに動作すること、ボリュームが重要な場合に、想定を大幅に上回る、または下回るボリュームでも作業が成立すること、手順が記載された順序と時間で完了すること、受け入れ条件、エッジケースの動作、スコープ、依存関係が網羅されていることが含まれます。まず、ほかの手順が依拠する判断と、判断の根拠が引用ではなく推論に基づいている、後戻りできない手順に注目してください。各前提が誤りだと示す事実を特定してください。今すぐ確認できる場合は、リスクとして報告するのではなく、実際に確認してください。

失敗候補ごとに、具体的な反証を試みてください。計画が失敗するような入力、コマンド列、またはリポジトリの状態を書き出し、その状態でも計画が成立するかを示すチェックを実行するか、引用してください。実行できない場合は、構築した入力またはコマンド列に加えて、引用した事実（ファイルと行、文書化された動作、観測された出力）があれば、その試みとして認められます。構築できなかった失敗は、障害を明記して「試行したが阻まれた」と報告します。それ自体が計画を裏付ける証拠です。名付けた失敗モードは、構築を伴わない想像上のリスク、つまり何も試していないのに慎重に見せる机上の悲観論です。構築も、それを阻む事実もない指摘は、表現を和らげるのではなく削除してください。

ワークフロー

1. 既存の意図の情報源を特定し、受け入れ条件、対象外事項、証拠要件、宣言された書き込みスコープを確認します。
2. 計画を書いていないコンテキストから、アイデンティティ、モデル選定、認可、境界に関する共通の検証方法に従って判断します。呼び出し元が書いた計画は、呼び出し元を作成者としてここで判断できます。このコンテキストが計画を書いており、新しいコンテキストを開始できない場合は、それでもチェックを実行し、独立性の要件を満たせていないことを明記したうえで、インラインの指摘を返します。独立した判断であるとは決して記述しないでください。
3. 引用したリポジトリの事実に基づいて、3つのチェックを実施します。統合や拡張の計画で、既存設計に引きずられることがリスクとなる場合は、derivation-diff challengeを追加します。
4. チェック済みの範囲と未チェックの範囲を明示した、具体的な指摘を漏れなく、かつ範囲を限定してまとめて返し、そこで終了します。その後、計画を修正するかRPIを実行するかは、呼び出し元が判断します。

機能している状態

出力から次のことが確認できます。

• 各単位に検証者が記載され、自己検証の形がそれぞれの単位を列挙した1件の指摘になっている。
• 各手順にマークが付けられ、後戻りできないことを示す各マークに、取り消しにかかるコストと不可逆点が明記されている。
• 各指摘に、反証を試みた内容、または試みを阻んだ事実が引用されている。
• 指摘の範囲が限定されている。すべての手順を指摘するレビューは、何も報告していないことになる。

境界

助言としての指摘のみを出力し、いかなる種類の判定、準備完了、受け入れ、許可についても表明しないでください。実装、候補の検証、再試行、修復、スケジュール設定、主張、受け入れ条件の変更、Git の操作、作業の終了、リリース、納品は行わないでください。CouncilまたはDueling Idea Geniesは呼び出し元が提供する証拠として使用できますが、Premortemにどちらも必須ではなく、合意を承認に変えることもできません。計画を編集すると、後で呼び出し元が開始するPremortemの新しい対象になります。

出力

デフォルトでは、指摘事項をインラインで返します。

Findings (in check order, then most consequential first within each check)
1. <step> - <how it fails> - <construction, or the fact that blocked it> - <consequence>
Verifiers: <unit>: <who verifies>
Steps: <step>: two-way | one-way - <undo cost> - <point of no return> - <who holds the handle>
Checked: <what was examined>. Not checked: <what was not>.
Independence: <judge context, distinct from author> or "missing: <reason>"

<skill-dir> は、この SKILL.md を含むディレクトリです。Claude Code では「このスキルのベースディレクトリ」として表示され、Codex ではこのスキルの SKILL.md のパスとして表示されます。AgentOps のソースチェックアウトでは skills/premortem です。コマンドを実行する前に、<skill-dir> をその絶対パスに置き換えてください。作業ディレクトリはユーザーのリポジトリのままにします。ホストがこのスキルのインストール先を表示しなかった場合は、読み取った SKILL.md のディレクトリを使用してください。特定できない場合は、パスを推測したり、現在のリポジトリにある同名のスクリプトを実行したりせず、同梱スクリプトが利用できないことを伝え、レビューの各フィールドを手作業でスキーマと照合してください。

呼び出し元が永続的なレビューを要求した場合は、premortem-plan-review.v1 を返し、bash "<skill-dir>/scripts/validate-output.sh" <review.json> で検証してください。intent_digest は、指定された意図のテキストそのものの SHA-256 です（たとえば shasum -a 256 plan.md）。author_context_id は計画を書いた人（呼び出し元、またはそのセッションの ID）を示し、judge_context_id はこのコンテキストを示します。この形式には、検証者やステップの記録用フィールドはありません。それらは checked に記録し、各指摘事項の根拠となる構成要素または阻害要因は evidence に記載してください。バリデーターは作成者と判定者の ID が同一である場合は拒否しますが、文字列が異なることだけを確認し、独立した判定者が実際に関与したかどうかは確認しません。そのため、独立した判定者がいないレビューはインラインのままにしてください。指摘事項が空であることは、この任意の検証で具体的な欠陥が見つからなかったことだけを意味し、プロセス上の必須条件ではありません。