菜单
障害対応机上演習を開始・再開・進行するための人間向け唯一の入口。ステップ別skillとagentを調整し、中間ファイル、IPC、ポストモーテム生成を管理する必要があるときに使う。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
指定シナリオID（おすすめ選択や明示指定で決まったID）があればそれを採用し、無ければフォールバックとして演習済みシナリオIDを除外して未演習シナリオを無作為順に並べ、今回の主シナリオと内部状況ファイルを作るためのskill。
事前生成済みの SCENARIO-LIST.tsv を読み、シナリオIDと初動対応部署と最初の開示可能イベントを一覧表示するskill。所属部署キーワードが渡されれば、全体訓練では初動対応部署で、個別訓練では初動対応部署または受動対応部署で絞り込んでおすすめ候補を出す。シナリオ選択の判断材料に使う。表示する3列は開示可能情報のみなので参加者へ提示してもよい（受動対応部署列は表示しない）。
理想タイムラインとレビュー済み回答が準備できた後、最初に参加者へ見せてよい演習イベントだけをIPCへ送るskill。
質問・行動の処理と開示レビュー後に、現在タイムラインを次イベントへ進め、必要な能動通知だけを送るskill。
タイムライン進行後、演習を継続してIPC入力を待つか、終了してポストモーテム生成へ進むかを判定するskill。
障害対応手順書・インシデント表のいずれか1つを入力に、机上演習用のシナリオを1件追加するフロー外の保守スキル。SCENARIO.tsv 行・timelines/<ID>/ の3点・SCENARIO-LIST.tsv を整備する必要があるときに使う。
| name | 00-run-exercise |
| description | 障害対応机上演習を開始・再開・進行するための人間向け唯一の入口。ステップ別skillとagentを調整し、中間ファイル、IPC、ポストモーテム生成を管理する必要があるときに使う。 |
このskillは、演習を通常実行するための唯一の入口です。演習中、Coding Agentは人間へ直接質問・回答してはいけません。質問、回答、能動通知、ポストモーテムなど、人間に見せる内容は必ず ../../shared/references/ipc-protocol.md に従って会話用プロセスへ送ります。
人間に見せる質問、回答、通知、ポストモーテムは必ず日本語で書きます。内部メモ、ファイル名、固定フォーマットの識別子は、形式の安定性を優先して英語を使ってもかまいません。
SCENARIO.tsvtimelines/<scenario-id>/ 配下の事前生成データ（TIMELINE-1.tsv / QUESTIONS-1.tsv / ANSWERS-1.tsv）./ops から作成された観測情報一覧TSV./ref 配下の仕様・設計文書./ops 配下の障害対応手順書・監視手順・RunbookEVAL_CRITERIA.mddocs/SPEC.md.ai/runs/<run-id>/ 配下の中間ファイル.ai/runs/<run-id>/postmortem.md../../shared/references/data-formats.md を読む。../../shared/references/ipc-protocol.md を読む。ttx-ai-send、参加者入力の受信は ttx-ai-recv を使う。python・nc・直接の socket 実装で送受信してはいけない。socket は既定パスを 3 ツールで共有するため通常 --socket は不要。別パスにしたいときだけ全ツールへ同じ --socket（または環境変数 TTX_SOCKET）を指定する。対象は、最初の開示（ステップ9 06-disclose-first-event の ttx-ai-send）以降のライブ進行（質疑ループ＝ステップ10〜12 の ttx-ai-send／ttx-ai-recv を含む）。ここで終了コード2（IPC 障害）が返ったら、会話用プロセス（ttx-human または Slack ゲートウェイ）が終了し会話用 UDS が失われたとみなす。リトライしない。 接続喪失による中断として /abort 相当で即座に終了する: timeline_cursor.json を aborted にし、ポストモーテムを作らず、以後いっさい IPC 送受信を行わない（相手が存在しないため、中断通知も送らない）。切断を internal_log.jsonl に記録して演習プロセスを終了する。
例外1（起動前）: ステップ3(b) の起動確認ゲート、ステップ3.5 の設定質疑（ttx-ai-send --type question／ttx-ai-recv）、ステップ4冒頭の開始メッセージ送信は最初の開示より前であり、そこでの終了コード2 は「まだ ttx-human を起動していない／socket パス不一致」を意味する。ここでは中断ではなく、操作者へ再提示して起動を待つ（このセクションの対象外。ヘッドレスではゲートウェイがサーバを起動済みのため通常は成功する）。ただしステップ3.5 の設定質疑で ttx-ai-recv が**待機タイムアウト（終了コード5）**を返した場合は、参加者が規定時間応答しなかったということなので、最初の開示前ではあるが /abort 相当の中断として扱う（timeline_cursor.json を aborted にし、ポストモーテムは作らない。ヘッドレスではゲートウェイが終了文言を投稿するため中断通知は二重に送らない）。
例外2（終了処理）: 終了処理（ステップ13）の postmortem 送信が終了コード2 になった場合は別扱い。ポストモーテムは既に生成済みで状態も finished のため、カーソルを書き換えず・破棄せず、リトライもせず送信を諦めて終了する（中断＝aborted にはしない）。
対応者からの質問に答えるために必要な場合、./ref 配下の仕様・設計文書と ./ops 配下の障害対応手順書・監視手順・Runbook を参照してよいです。ただし参照は「ある情報が観測可能・開示可能か」を判断する目的に限り、開示してよいのは現在または過去のタイムライン上で観測可能な事実だけです。次に確認すべき手順・監視項目・調査方法といった"手がかり"は、手順書や仕様に載っていても開示しません（対応者自身に調べさせる）。
Slack ゲートウェイ（tools/ttx-slack）から codex exec で非対話起動された場合は、ヘッドレスモードで動きます。判定条件: 環境変数 TTX_SOCKET が設定済みで、起動プロンプトにヘッドレス実行の指示がある（会話用プロセスは既にゲートウェイが起動済み）。
ヘッドレスモードでは、物理画面前提の対話的セットアップだけを省略します。訓練モード選択とシナリオ選択（ステップ3.5）は省略せず、CLI と同じく IPC 経由で参加者へ尋ねます（Slack スレッドで @ttx への返信として行われる）。
install-ttx.sh。ゲートウェイ環境に導入済み前提）と、ステップ3（別窓起動・起動確認ゲート・画面隠しの理解確認・10秒カウントダウン）。これらは「操作者が画面を見ている」前提の手順で、Slack には該当しません（GM 側の物理画面が存在しない）。ステップ2の準備モードの内部決定とステップ3.5の設定質疑は省略しません。TTX_SOCKET のパスで会話用プロセス相当（ttxserver）を起動済みです。ttx-ai-send / ttx-ai-recv はこの TTX_SOCKET を使います（--socket 明示は不要）。ttx-ai-send --type question で尋ね、ttx-ai-recv で回答を受け取ります（CLI と同一）。起動プロンプトでシナリオID（例 SCN-007）が指定されていればシナリオ選択質問は省略してそのIDを採用しますが、訓練モードの質問は必ず行います（明示指定ショートカット）。ttx-ai-send --type postmortem がゲートウェイ側の終了検知トリガになります。ゲートウェイが先に落ちるなどで IPC が終了コード2（IPC 障害）になった場合は、「IPC 障害時の扱い」に従いリトライせず接続喪失中断で終了します。/abort を受けた場合、または ttx-ai-recv が待機タイムアウト（exit5）を返した場合、ゲートウェイが参加者向けに終了メッセージを投稿するため（GM 終了 → codex 終了をゲートウェイが検知して投稿）、ヘッドレスでは中断通知を二重に送らず、ポストモーテムを作らずに終了します。なお会話用プロセスはゲートウェイが起動するため、待機タイムアウトの長さはゲートウェイの --recv-timeout（既定30分）に従います。codex exec に -c model_reasoning_effort="low" を渡すため、ヘッドレスでは既定で低く設定済みです（ライブ進行のテンポ向け。GM 側で下げ直す必要はありません）。以降の「実行手順」は対話モードの記述です。ヘッドレスモードでは上記のとおり省略・自動化して読み替えてください。
scripts/install-ttx.sh を実行する。これは ttx-human / ttx-ai-send / ttx-ai-recv が未導入または古い場合だけ、GitHub Release のビルド済みバイナリを取得して PATH 上のディレクトリへ配置する冪等なスクリプトで、gh が無ければ導入を試み、未認証なら gh auth login を案内する。実行後 command -v ttx-human ttx-ai-send ttx-ai-recv で PATH 解決を確認する。スクリプトが失敗したら、標準エラーに出る原因と対処（例: gh auth login、Release 公開待ち）を操作者へそのまま提示し、先へ進まない。socket は省略すると既定パスを使い、3 ツールが同じ既定 socket を共有する（別パスにしたいときだけ全ツールへ同じ --socket か TTX_SOCKET を指定）。別窓での起動はステップ3で指示する。TIMELINE-1.tsv / QUESTIONS-1.tsv / ANSWERS-1.tsv）が timelines/<SCN>/ に揃っていれば再利用、無ければアドホック生成にする（再利用は自由度が低いが高速、アドホックは自由度が高いが低速）。準備モードは選ばれたシナリオが定まって初めて確定するので、ここでは方針だけを決めておき、実際の判定はステップ3.5・ステップ4（01a）で行う。SCN-007）が明示指定されていれば控えておく（CLI では操作者が起動時に指定、Slack では初回メンションで指定）。指定があればステップ3.5 のシナリオ選択質問を省略してそのIDを採用する（明示指定ショートカット＝01a の selection_method=specified）。ただし訓練モードの質問は指定の有無にかかわらず必ずステップ3.5 で行う。ttx-human を実行して、演習が終わるまでそのまま起動したままにしてください」と案内する。提示するコマンドは PATH 配置済みの素のコマンド ttx-human（scripts/install-ttx.sh が PATH 外へ配置した場合のみ、スクリプトが示した起動コマンドを使う）。socket は省略してよい（既定パス共有）。会話用プロセスは接続が閉じても終了しないので、演習中は1つ起動したままでよい。ttx-human を起動しましたか？ (Y/N)」と尋ねる。Y を受け取るまで先へ進まない（N や不明瞭なら (a) を再提示）。Y を受け取ったら裏取りとして ttx-ai-recv --no-wait を1回実行し、終了コードで起動を確認する: 4（接続済み・入力なし）または 0（接続済み。演習前の誤入力が1件返るだけなので破棄してよい）なら起動済みとみなす。2（接続失敗）なら未起動か、ttx-human と GM 側ツールで socket パスが食い違っている。まず (a) を再提示して起動を確認する。起動済みなのに 2 が続く場合は、別窓の ttx-human の先頭に表示されている listening on <パス> の行のパスを操作者に読み上げてもらい、そのパスを ttx-ai-recv / ttx-ai-send の --socket（または環境変数 TTX_SOCKET）へ同じ値で指定して揃える。SCENARIO.tsv・scenarios/・timelines/・./ref・./ops など）を読む前に、まず操作者へこれからやるべきことと、Y を押した後に起こることを予告したうえで確認する: 「これから演習を開始します。参加者から、ゲームマスター側（Claude Code / Cursor）の思考過程や内部情報が映る画面が見えないように隠す必要があります。準備ができたら Y を入力してください。Y を押すと 10秒のカウントダウンが始まり、その10秒の間に画面を隠していただきます（こちらからの完了確認はありません）。理解しましたか？ (Y/N)」。Y（理解した）を受け取るまで先へ進まない（N や不明瞭な応答なら同じ案内を再提示する）。Y を受け取ったら「10秒以内に画面を隠してください」と案内し、すぐフォアグラウンドで可視カウントダウンを実行する（例: for i in 10 9 8 7 6 5 4 3 2 1; do printf '残り %s 秒…\n' "$i"; sleep 1; done; printf '0 — 開始します\n'）。秒数は seq ではなく明示列挙にして移植性を確保する。このカウントダウンが完了するまで次へ進まない（フォアグラウンドでブロックするため、隠す10秒の間に隠し情報を読み始めないことが構造的に保証される）。なお Codex など一部の環境では数字が最後に一括表示されることがあるが、10秒の待機自体は成立するので問題ない。画面を隠せたか（完了）の確認は求めてはいけない（操作者が返信のため画面を見続けるのを避けるため、隠す動作自体は必ずタイマー方式にする）。これ以降は操作者（Codex 端末）へ選択肢や確認を提示しない。 判断が必要な場合はエージェントが最良と考える選択肢を自動で選び、選定理由は internal_log.jsonl にのみ記録する（操作者の入力を待たない）。操作者（Codex 端末）への選択・確認が必要なものはステップ1〜2と、この起動確認・理解確認で済ませてある。訓練モードとシナリオの選択は、この後ステップ3.5 で会話用プロセス（ttx-human／Slack）経由で参加者へ尋ねる（操作者端末ではなく IPC へ送るので画面隠し後でも矛盾しない。送るのは開示可能な情報だけ）。
3.5. 設定質疑フェーズ（IPC 経由）。 画面隠し後、最初の開示（ステップ9）より前に、訓練モードとシナリオを会話用プロセス経由で参加者へ尋ねる。各質問は ttx-ai-send --type question で送り、回答は ttx-ai-recv --wait で1件受け取る（回答は type:"input" で返るが、ここでは質問・行動ではなく設定回答として解釈する）。設定質疑は参加者の回答待ちなので --thinking は点けない（思考中表示は開始メッセージ＝ステップ4から点ける）。送ってよいのは開示可能な情報だけ（訓練モードの問い、01b の表示3列、参加者本人の所属部署名）で、シナリオ概要・受動対応部署名・未来イベントは送らない。question で尋ね、回答を受ける。曖昧・無回答や、明示指定シナリオだけが与えられて訓練モードが読み取れない場合は**全体訓練（既定）**とみなす。全体訓練は training_mode=whole、個別訓練は training_mode=individual。question で尋ね、回答を SCENARIO-LIST.tsv の部署表記へ正規化した1つを primary_department にする。全体訓練では自部門は尋ねない（primary_department は空）。question 提示し、「番号、またはシナリオID（例 SCN-007）で返信してください」と促す。
01a の無作為選定。所属部署で絞らない。個別訓練では 01a が自部門の関与するシナリオに絞る）。../01b-list-scenarios/SKILL.md の候補を絞り、その候補からGMが無作為に1つ選ぶ（参加者には一覧を見せず、選ばれたIDを明示指定として扱う）。個別訓練では (b) の自部門を使い、全体訓練ではこの場で所属部署キーワードを尋ねる。01b 一覧を絞り、表示3列（シナリオID・初動対応部署・最初の開示可能イベント）を question で提示してからIDを尋ねる（2往復）。個別訓練では自部門、全体訓練では所属部署キーワードを尋ねる。01b で全件の表示3列を question で提示してからIDを尋ねる（2往復）。01a の selection_method=specified）として扱う。01a の実行と situation.tsv 書き込み）はステップ4で行う。01a が situation.tsv に training_mode と primary_department を書き、06・07・10・12 はそれを読んでモードに応じて振る舞う（訓練モードは引数で逐次渡すのではなく situation.tsv を唯一の真実源とする）。準備モードはステップ2の方針に従い、選ばれたシナリオに事前生成3点が揃えば再利用、無ければアドホック生成にする（明示指定で事前生成が無い場合もアドホック生成を既定採用し internal_log.jsonl に記録する。画面隠し後は操作者へ確認できないため）。01b が全件一覧を出すので、別の所属部署キーワード・シナリオIDの明示指定・無作為選定のいずれにするかを question で参加者へ尋ね直す。SCENARIO.tsv に無い場合は 01a が検出するので、question で選び直しを促す（最初の開示前なので再質問してよい）。/abort（type:"control"）が来たら中断する（timeline_cursor.json を aborted、ポストモーテムなし、ステップ13の中断分岐）。/giveup はまだ演習が始まっていないので /abort と同様に中断する（ポストモーテムは作れない）。/claim は設定中には対象が無いので、question で「いまは演習開始前の設定中です」と短く返して設定質疑を続ける。ttx-ai-send --type notification --thinking --text '演習を開始します。最初のメッセージまで1〜2分ほどお待ちください。'。これは開示前のメッセージなので、ここで終了コード2（IPC 障害）が返っても中断（abort）ではなく「IPC 障害時の扱い」の例外1（起動前）と同じ扱いにする（対話モードでは未起動／socket 不一致として再提示し起動を待つ。ヘッドレスではゲートウェイがサーバを起動済みのため通常は成功する）。--thinking で点けた思考中表示は、ステップ9の最初のイベント開示（フラグなしの notification）の表示で自動的に解除されるので、明示的に消す送信は不要。その後 ../01a-select-scenario/SKILL.md にステップ3.5 で決めた訓練モード・自部門・シナリオID（または無作為指示）と準備モードを渡して状況を選び、最初の状況ファイルを書く（明示指定IDがあればそれを採用、無作為指示なら無作為選定。再利用モードでは事前生成3点が揃うシナリオに限定）。.ai/agents/02-build-ideal-timeline.md を使って理想タイムライン（TIMELINE-1.tsv）を用意する。アドホック生成モードなら新規生成、再利用モードなら timelines/<primary_scenario_id>/TIMELINE-1.tsv を読み込む。.ai/agents/03-build-expected-questions.md を使って、最新の現在タイムラインから想定質問集を作る（事前生成 QUESTIONS-1.tsv は参考資料）。.ai/agents/04-build-expected-answers.md を使って、最新の現在タイムラインから想定回答集を作る（事前生成 ANSWERS-1.tsv は参考資料）。.ai/agents/05-review-disclosure.md を使って、開示してはいけない情報が混ざっていないか確認する。../06-disclose-first-event/SKILL.md で最初の公開イベントをIPCへ送る。ttx-ai-recv --wait で参加者の入力を1件受け取り、.ai/agents/07-handle-question-or-action.md で扱う。（この最初の受信で ttx-ai-recv が終了コード2＝IPC 障害を返した場合は「IPC 障害時の扱い」に従い、リトライせず接続喪失中断する。）入力が /giveup（type:"control"）なら、07 が .ai/runs/<run-id>/timeline_cursor.json を finished にし、ステップ13へ進む。入力が /abort（type:"control"）なら、07 が timeline_cursor.json を aborted にし、ポストモーテムを作らずステップ13へ進む。入力が /claim（type:"control"）なら 07 が前提への異議申し立てとして扱う（本文なしなら awaiting_claim を真にして争点を尋ね、次の入力を主張として扱う。本文ありなら主張を CLAIMS.tsv に暫定採用記録し、直前の行動を新しい前提で再評価する。タイムラインが変われば以降は通常どおりステップ11へ流れる）。ttx-ai-recv が**終了コード 5（待機タイムアウト）**を返したら、規定時間（既定30分）参加者入力が来なかったということなので、入力としては扱わず /abort と同様に timeline_cursor.json を aborted にし、ポストモーテムを作らずステップ13へ進む（ホスト側のツールタイムアウトで recv を再実行している場合も、サーバが総アイドル時間で打ち切るので exit5 はいずれ返る）。.ai/agents/08-update-answer-set.md と .ai/agents/09-review-updated-disclosure.md を使って回答集を更新・再レビューする。../10-advance-timeline/SKILL.md と ../11-loop-or-finish/SKILL.md で次イベントへ進むか終了するかを決める。timeline_cursor.json のカーソル状態で分岐する。
finished（タイムライン終端または /giveup）: .ai/agents/12-build-postmortem.md でポストモーテムを作り、ttx-ai-send --type postmortem で参加者へ送る。aborted（/abort または ttx-ai-recv の待機タイムアウト=exit5）: ポストモーテムを作らない。 短い中断通知を ttx-ai-send --type notification で送り（送らないと会話用プロセスが応答待ち表示のまま残るため必ず送る。本文は /abort なら 演習を中断しました。ポストモーテムは作成しません。、待機タイムアウトなら 一定時間入力がなかったため演習を終了しました。ポストモーテムは作成しません。。ただしヘッドレスモードでは上記「ヘッドレスモード」節の指示が優先で、この中断通知は送らない＝ゲートウェイが終了文言を投稿するため二重送信しない）、IPC ではなく操作者へ直接、ライブループ用に下げた reasoning effort（low）を元に戻すリマインドを行う（12-build-postmortem.md のリマインドと同趣旨）。なお接続喪失（IPC 障害＝終了コード2）による中断は IPC 障害の時点で既に終了しており（「IPC 障害時の扱い」）、ここへは到達しない（相手が居ないため中断通知も送らない）。
どちらの場合も、その後は操作者が会話用プロセス（ttx-human）を終了してよい（stdin を閉じる、または Ctrl-C）。演習ごとに .ai/runs/<run-id>/ を作り、すべてのステップ出力を保存します。
タイムラインは TIMELINE-<N>.tsv で版管理します。バージョン1（TIMELINE-1.tsv）が理想タイムラインで、初期の現在タイムラインを兼ねます。対応者の行動でタイムラインが理想から変化すると TIMELINE-2.tsv, TIMELINE-3.tsv … と版が増え、最新版が現在タイムラインです。TIMELINE-1.tsv は上書きしません。命名の詳細は ../../shared/references/data-formats.md を参照します。
事前生成再利用モードでは、正本 timelines/<scenario-id>/{TIMELINE-1,QUESTIONS-1,ANSWERS-1}.tsv を入力・参考として使います。timelines/ は不変、.ai/runs/<run-id>/ は1回の演習の作業ディレクトリです。
既存runで互換性のある名前が使われていない限り、次のファイル名を使います。
situation.tsvTIMELINE-<N>.tsv（版1＝理想、最新＝現在タイムライン）QUESTIONS-1.tsv（想定質問集）ANSWERS-<N>.tsv（想定回答ドラフト）REVIEWED-ANSWERS-<N>.tsv（開示レビュー済み回答）DISCLOSURE-REVIEW-<N>.md（開示レビュー記録）timeline_cursor.jsonCLAIMS.tsv（/claim で暫定採用された主張の記録）public_log.jsonlinternal_log.jsonlpostmortem.md演習はテンポが重要です。応答が遅いと体験を損なうため、次の方針で速度を確保します。モデルは下げません。
low に設定する（例: /efforts で low を選ぶ）。low に下げるのはライブループに入ってからでよい。low へ下げた effort は演習終了後の通常作業では不適切なため、ポストモーテム生成（ステップ13）の後に元の effort へ戻すことを忘れない（ステップ13 の 12-build-postmortem.md でも操作者へリマインドする）。.ai/agents/07-handle-question-or-action.md の「応答方針（速度）」に従う。.ai/agents/07-handle-question-or-action.md「質問・行動への応答方針」に従う（判断フロー＋述べる/述べない）。要点: 推測・結論・状況の要約・聞かれていない上乗せ・関連性/優先度の枠付け・観測可能性/検証可能性の提示（「確認できます」「観測できます」「参照できます」等）・確認先の案内・設計説明はしない。尋ねられた観測値はシナリオ整合なら生成して述べてよい。確認先を明示しない曖昧な観測質問は聞き返す。1つのステップだけをデバッグする場合は、対応するskillまたはagentを、前段の出力ファイルを固定入力として再実行します。ユーザーが明示的に求めない限り、前段ファイルを作り直してはいけません。