mstack-codex-review-workflow

mstack Codex レビューワークフロー

このスキルは Claude Code 固有のツールを使用するため、Claude Code でのみ実行できます。Codex を使用している場合は、ここで停止してユーザーに伝え、代わりに mstack-claude-review-workflow を使用してください。

あなたはコーディネーターです。サブエージェントがコードを作成します。あなたは作業を分割し、概要を伝え、レビューし、統合して、結果を報告します。Codex は読み取り専用のセカンドオピニオンとして、参照ファイルではクロスベンダーレビュアーと呼ばれています。成果物は、すべての作業項目を完了し、レビューと検証を済ませた単一の統合ブランチです。リポジトリがプルリクエストに対応している場合は、すべての項目が完了してから一度だけプッシュし、CI は一度に 1 回実行して、単一の PR として提出します。

リポジトリ独自のルール（AGENTS.md、CLAUDE.md、CONTRIBUTING、デリバリースキル）と、実行する計画のルールも引き続き適用されます。より厳しいルールがある場合は、このスキルより優先されます。

このスキルのファイル

以下の <skill-dir> は、このスキル自体のフォルダー、つまりホストがこのスキルを読み込んだ際に表示したベースディレクトリを指します。各レーンは別のワークツリーで実行されるため、すべての概要には絶対パスを使用してください。

ファイル	読む人	タイミング
references/working-style.md	あなたとすべてのレーン	作業を始める前に必ず
references/writing.md	あなたとすべてのレーン	ユーザーへのすべてのメッセージ、レーンの報告、PR 本文、コミット、トラッカーへのコメント、ドキュメントを作成する前
references/receiving-review.md	あなたとすべてのレーン	レビューに対応する前
references/grilling.md	あなた、設計の比重が大きいレーン	要件や設計が曖昧な場合、または妥当な答えが複数ある場合
references/external-facts.md	外部の不明点に直面したレーン、およびレーン横断の調査を行うあなた	答えがリポジトリ外の事実に左右される場合
references/web-ui.md	Web UI のレーン、UI 差分をレビューするあなた	Web またはフロントエンドの UI を変更する場合
references/plan-format.md	あなた	作業項目が mstack-plan フォルダーにある場合
scripts/check-required-skills.sh	あなた	事前確認

今すぐ working-style.md と writing.md を読んでください。これらは実行全体を規定します。これらのファイルのルールは、サードパーティ製スキルをもとにしており、そのクレジットはこのスキルの THIRD_PARTY_NOTICES.md に記載されています。

作業項目

作業項目とは、独自の受け入れ基準とステータステーブル上の項目を持つ、作業の単位です。実行は次のいずれかのソースから始まります。

ソース	例	受付時の確認方法	項目 ID
トラッカーの課題	GitHub の課題番号やリンク、課題のテーブルやスクリーンショット、別のトラッカーの課題	GitHub では、gh issue view <n> --json number,title,body,labels,comments,state を実行します。別のトラッカーでは、セッションに CLI または接続済みツールがあればそれを使い、なければ各課題を貼り付けるようユーザーに依頼します。テーブルやスクリーンショットは参照先の一覧にすぎません。要件となるのは課題本文とコメントです	トラッカー独自の ID（#41、PROJ-12）
計画	実行計画、タスクファイル、フェーズファイル、計画フォルダー	計画全体と、計画で参照されているすべてのファイルを読みます。各タスクまたはフェーズが 1 つの項目となり、計画に記載された受け入れ基準、ファイル一覧、順序、検証コマンドが要件になります	計画独自のタスク ID またはフェーズ ID
1 件のタスク	依頼で説明されている機能、リファクタリング、バグ	それぞれが独立して検証できる成果をもたらす最小単位の項目に分割し、確認ラウンドでユーザーに一覧を確認します	T1、T2 など

計画でステータス自体（チェックボックス、ステータス列、タスクファイルなど）を管理している場合、そのファイルの管理はあなたが担います。項目の状態が変わるたびに更新し、統合時にコミットします。レーンはそのファイルを編集しません。

mstack-plan フォルダー（plan.md、progress.md、execute-plan.md が含まれます）は references/plan-format.md に従うため、受付時にこのファイルを読み、再開と陳腐化のチェックを最初に実行します。各タスクが作業項目となり、そのタスク ID が項目 ID になります。Satisfies 行と仕様書の対応する要件が受け入れ基準、Files が予測されるファイル、Depends on 行とフェーズラウンドが依存関係、Done when が証拠となります。progress.md は計画のステータスファイルです。Executor 行をこのスキルに、Branch 行を統合ブランチに設定します。Closed のタスクは、その作業がブランチに含まれていることを確認してからスキップします（停止した実行で Closed になったものの、統合されていないタスクは取り込みます）。In progress のタスクはログ行をもとに再開し、項目の状態が変わるたびに、その証拠を記したログ行を追記してタスクの行を更新します。これらの更新は、ステータステーブルを表示するのと同じメッセージで行います。Closed の行には、統合前にタスクがクローズされるため、レーンのブランチ名と、承認済みのコミットを記載します。このようなフォルダーがない場合、実行はソースに応じた説明どおりに進めます。

ステータステーブル

すべての作業項目のステータスを、次の 3 つの状態だけを使って 1 つのテーブルに表示します。

状態	意味
Open	まだ開始していないか、ブロックされています。ブロック中の場合、注記に理由を記載します
In progress	レーン（または Single モードのあなた）が作業中であるか、レビュー中または修正ラウンド中です
Closed	作業が承認されています。レビューとセカンドオピニオンに合格し、指摘事項が解決され、検証が成功しています

| Item | Title | State | Lane | Note |
|---|---|---|---|---|
| #41 | Second save loses changes | In progress | A, sonnet | Codex review running |
| #42 | Reset to defaults button | Open | B, sonnet | Waits for lane A's store change |

1. 受付の最後に、すべての項目を Open としてテーブル全体を表示します。
2. 少なくとも 1 つの項目の状態が変わったメッセージでは、位置行の直後に、テーブル全体を再度表示します。状態に変化がなければ表示しません。
3. レビューで差し戻された項目は In progress のままです。ここで完了できない項目は Open のままとし、注記に理由を記載します。
4. これらはワークフロー上の状態であり、トラッカー上の項目の状態は変更しません。GitHub の課題は、それをクローズする PR がマージされたときにクローズされます。
5. 最終報告には同じテーブルを含めます。

0. 開始前に確認する

プリフライトやその他の作業を始める前に、ユーザーの目標と、それを満たす最小限の変更を言い換えたメッセージを1つ送信し（working-style.mdを参照）、同じメッセージ内でAskUserQuestionを使って質問します。項目は受付時に読み取り専用で確認するため、依頼内容から目標を言い換え、受付後に内容を詰めます。

1. Codex のレビューに使用するモデル。推奨回答としてgpt-6.1-sol、代替としてgpt-6-astraを提示し、ユーザーが入力するほかのモデル名も受け付けます。
2. Codex が使用する推論レベル。推奨回答としてhighを提示し、続いてmedium、xhigh、maxを提示します。また、ユーザーが入力するほかのレベルも受け付けます。
3. 実行するモード。予測されるファイルが重複しない項目が2つ以上ある場合はWorkflowモードを、それ以外の場合はSingleモードを推奨します。

ユーザーの依頼ですでに回答されている質問は省略します。mstack-planのexecute-plan.mdからの引き継ぎは依頼として扱うため、そこでユーザーが回答したレビュー担当モデル、推論レベル、コミットについての回答を、ここでもその質問への回答として扱います。Codex のモデルまたは推論レベルが指定されている依頼は、その質問への回答として扱います。「Fan out agents」、「parallel」、「workflow」はWorkflowモードを意味し、「one by one」、「single」、「no subagents」はSingleモードを意味します。Codex のサンドボックスは常にread-onlyであり、質問することはありません。

回答は<codex-model>および<codex-effort>として記録します。この実行中のCodexレビューでは、すべてこの値を使用するため、レビューごとに再度質問することはありません。この2つの回答は、codexスキルが尋ねるモデルと推論レベルの選択肢です。最初のCodex実行でモデルまたは推論レベルが拒否された場合は、質問1の代替モデル（または1段階低い推論レベル）で再実行し、実行の残りの部分でもその値を使用して、最終報告でその旨を伝えます。レビューのためにユーザーを待たせることはありません。

• Workflowモードでは、セクション2〜6に記載のとおり、ライターのレーンをそれぞれ独自のワークツリーで並行して実行します。独立した項目が多い場合に最も速い一方、トークンとマシンリソースを多く消費します。
• Singleモードでは、分割案で示された順序に従って、1つのブランチ上で、項目を1つずつ自分で処理します。ライターのサブエージェントは使用しません。それ以外のすべての手順は引き続き適用されます。参照ファイル、ステータステーブル、アドバイザーとCodexによるレビューをreceiving-review.mdに従って処理すること、ローカルでの検証、1つのPR、CIの逐次実行が含まれます。読み取り専用のヘルパー（Codexレビューや、ログを簡易的に読むツールなど）は引き続き使用できます。自分が唯一のレーンとなるため、参照ファイルにあるレーンのルールは自分に適用され、レビューでの指摘は自分で修正します。レーンのコードにパッチを適用しないというルールは、Workflowモードでのみ適用されます。

回答を受け取った後、最初のメッセージと最終報告で、選択したモード、Codex のモデル、推論レベルを明示します。

事前確認：必須ツール

リポジトリのルートからチェッカーを実行します。対象が GitHub の issue、または PR の提出先が GitHub の場合は --github を追加します。対象に Web UI が含まれる場合は --web-ui を追加します。

bash <skill-dir>/scripts/check-required-skills.sh [--github] [--web-ui]

チェッカーはスキルファイルを見つけ、必要な CLI にログイン済みかどうかを確認します。また、各スキルがこのセッションで利用可能なスキルの一覧に表示されていることも確認してください。セッション開始後にインストールしたスキルは、新しいセッション（またはプラグインの場合は /reload-plugins の実行後）にのみ読み込まれます。mstack-diagnose:mstack-diagnose と skill-codex:codex（単独のスキルとしてインストールされている場合は codex）を探してください。OpenAI 独自の Codex プラグインに含まれる codex: スキルは別のプラグインのため、対象には含まれません。

常に必須：このマーケットプレイスの ponytail と mstack-diagnose、およびログイン済みの codex CLI を備えた skill-codex プラグインの codex スキル。GitHub の作業では、ログイン済みの gh が必須です。Web UI の作業では、ui-ux-pro-max と Python 3 が必須です。

不足しているものがある場合：

1. 不足している項目を具体的にユーザーに伝え、今すぐインストールするかどうかを尋ねます（AskUserQuestion）。
2. 同意された場合は、以下のコマンドでインストールし、チェッカーを再実行します。合格するまで作業を続けてはいけません。スキルの読み込みに新しいセッションが必要な場合は、その旨を伝えて停止します。
3. 同意されない場合は、不足している項目のインストール手順を以下のとおり表示して停止します。これらがないと、このワークフローで保証されるレビューとコードスタイルの確認が行われないままになります。

ユーザーが同意した場合は、同じやりとりの中で、スキルごとのインストール方法も AskUserQuestion で尋ねます。エージェントはスキル CLI の質問に回答できません。エージェントが実行すると、質問なしでインストールされるため、インストール方法を選べるのはユーザーだけです。

1. インストール経路：プラグインを提供している場合は、マーケットプレイスから更新できるためプラグインを推奨します。または、スキルフォルダーのみをインストールする skills CLI（npx skills）を選べます。
2. skills CLI を使う場合の適用範囲：すべてのプロジェクトに適用するグローバル（推奨）、またはこのリポジトリのみ（リポジトリ内の .agents/skills と .claude/skills にインストールされ、skills-lock.json に記録されます）。
3. skills CLI を使う場合の方法：シンボリックリンク（推奨。1つのコピーを npx skills update で更新）、またはコピー（独立したファイル。シンボリックリンクに対応していないファイルシステムや同期ツール向け）。
4. skills CLI を使う場合のエージェント：Claude Code のみ（推奨）、または Claude Code と Codex。

次に npx skills add <source> --skill <skill> -a <agents> -y を実行します。グローバルの場合は -g、コピーの場合は --copy を追加します。<agents> には claude-code、codex、または claude-code codex を指定します。セッション中にインストールしたスキルは、新しいセッションでのみ読み込まれます。

不足項目	インストール方法
ponytail	プラグイン：claude plugin marketplace add DietrichGebert/ponytail を実行し、続けて claude plugin install ponytail@ponytail を実行します。skills CLI：source DietrichGebert/ponytail、skill ponytail
mstack-diagnose	プラグイン：/plugin marketplace add mubeda/mstack を実行し、続けて /plugin install mstack-diagnose@mstack、さらに /reload-plugins を実行します。skills CLI：source mubeda/mstack、skill mstack-diagnose
codex スキル（skill-codex）	プラグイン：/plugin marketplace add skills-directory/skill-codex を実行し、続けて /plugin install skill-codex@skill-codex を実行します。skills CLI：source skills-directory/skill-codex、skill codex。以下の codex CLI が必要です
codex CLI	npm install -g @openai/codex を実行し、次に codex login を実行してから、codex --version で確認します
gh CLI	https://cli.github.com を参照し、gh auth login を実行します
ui-ux-pro-max	プラグイン：/plugin marketplace add nextlevelbuilder/ui-ux-pro-max-skill を実行し、続けて /plugin install ui-ux-pro-max@ui-ux-pro-max-skill を実行します。skills CLI：source nextlevelbuilder/ui-ux-pro-max-skill、skill ui-ux-pro-max。詳細は references/web-ui.md にあります
Python 3	システムのパッケージマネージャー、または https://www.python.org/downloads/ を利用します

インストールでは、これらの提供元のサードパーティコードが実行されます。そのため、スキルではなくユーザーが判断します。

1. 受付（サブエージェントではなく、あなたが担当）

このスキルはプロジェクトに依存しません。各リポジトリ固有のルール、ツール、チェック項目を推測せずに確認します。

1. 該当するすべての AGENTS.md、CLAUDE.md、CONTRIBUTING ファイルを読み、git status --short を実行し、作業前の手順（コードインデックスの同期、ドキュメントインデックス、セットアップ手順）に従います。レーンには Git worktree が必要なため、対象が Git リポジトリでない場合は作業を止めて、ユーザーに確認します。自分で git init を実行してはいけません。リポジトリのルールでコミット、ブランチ、プッシュが制限されている場合（たとえば、明示的な依頼がある場合に限りコミットする場合）は、ここで一度だけユーザーに確認し、このワークフローで作成するレーンブランチのコミット、統合ブランチ、PR を承認するか尋ね、その回答に従います。
2. 作業項目の表に記載されたソースを参照し、すべての作業項目を最後まで読みます。
3. 各項目について、受け入れ条件（項目に記載がない場合は推測した条件を記録し、推測であることを明記して、確認ラウンドで確定します）、種類（バグ、機能、ドキュメント、テスト、CI、測定）、担当パッケージ、他の項目への依存関係（計画上の順序も含む）、変更する可能性が最も高いファイルを記録します。リポジトリのコードインデックスまたは rg を使って対象ファイルを予測します。予測は大まかでも構いませんが、分担はこれに依存するため、記録してください。
4. 要件や必要な判断が曖昧な場合は、レーンの開始前にユーザーと確認ラウンド（grilling.md）を実施し、推測に基づいてレーンが作業を進めないようにします。事実関係は自分で確認します。ユーザーには判断のみを求めます。
5. エージェントで実行可能な検証（スクリプト、エンドツーエンドのドライバー、ローカル Docker 環境など）を優先します。項目が GUI やデバイスを使った人手でしか実施できず、リポジトリがエージェント管理の場合は、ユーザーに手動作業を依頼するのではなく、トラッカーの課題なら計画対象外としてクローズすることを提案します。
6. このマシンでは完了できない項目（別の OS、ハードウェア、人による測定、シークレットが必要なもの）に印を付けます。実施可能な範囲を計画し、残る作業を事前に伝えます。
7. Rust、C++、Xcode、Android など、ビルド負荷の高いターゲットをビルドするライターの作業波を始める前に、ディスク容量を確認します（df -h）。十分な余裕を確保し、同時に実行する高負荷ビルダーの数を制限します。
8. 作業開始元のブランチである <base> を記録します。ユーザーが指定したブランチがあればそれを、なければ現在のブランチを使います。
9. すべての項目を Open としたステータス表を出力します。

2. レーンへの分担

レーンとは、専用の Git worktree で作業し、ファイルセットを排他的に所有するライターサブエージェントです。目標は、編集の重複をゼロにしながら並列性を最大化することです。

• 予測したファイルセットが重複する項目は、同じレーンにまとめて（1 人のエージェントが順番に作業する）、または後の項目を先行レーンの完了まで待たせます。一方の項目が、もう一方の項目が呼び出す、または依存するコード（ストア、API、共有型など）を変更する場合や、計画で順序が指定されている場合も同様です。同じレーンにまとめるか、順序を設定して、後続レーンのベースに先行レーンのブランチを指定します。共有の変更頻度が高いファイル（ロックファイル、変更履歴、生成されたスキーマ、共有ドキュメントインデックス、CI ワークフロー、計画のステータスファイル）は、1 つのレーンだけが担当するか、統合作業であなたが対応します。
• 変更履歴とリリースノートの行はレーンから報告してもらい、統合作業時にあなたが記入します。複数のレーンが同じファイルを編集することはありません。
• レーン表は working-style.md に記載されたスループットチェックポイントから始めます。その後、エージェントを起動する前に、レーン、項目、担当ファイルとディレクトリ、変更禁止ファイル、モデル、作業量、参照ファイル、検証コマンドを記載した表を作成します。
• 少数の大きなレーンより、小規模なレーンを多くすることを優先します。ただし、1 つの項目を複数のライターに分割してはいけません。

3. レーンごとにモデルと作業量を選ぶ

難易度に応じてトークンを使います。この表は、他のモデルや作業量に関する既定の指定よりも優先されます。

タスクの種類	モデル	作業量
ドキュメント、README、コピー、機械的な編集、ログや CI アーティファクトの読み取り、対象を絞った再確認	haiku または sonnet	低〜中
明確な基準があり、1 つのパッケージ内で完結する UI またはテスト作業	sonnet	中
根本原因のバグ、並行処理、永続化やプロトコルの変更、パッケージをまたぐ設計	opus	最大でも中

サブエージェントには fable を使用しないでください。Opus サブエージェントに中を超える作業量を指定しないでください。すべてのスポーンで model と effort を明示的に設定し、各レーンに Opus が必要な理由をレーン表に記載してください。

4. 参照ファイルとスキルを指定する

すべてのブリーフでは、作業を始める前に各レーンが絶対パスで全文を読む必要のあるファイルを指定します。

条件	ファイル
すべてのレーン	working-style.md、writing.md、receiving-review.md
mstack-plan フォルダーのタスク	タスクとそのフェーズの「Read first」に記載された項目、および「Skills」の行に記載されたスキル。プランではプラグインの接頭辞なしでスキル名が指定されるため、このホスト上で表示される名前を使ってブリーフに各スキルを記載します。このホストにないスキルはスキップし、レポートに記載します
バグ、リグレッション、不安定なテスト、クラッシュ、ハング、リーク、パフォーマンス問題、本番インシデント	mstack-diagnose スキル。レーンはこれを読み込むか、その SKILL.md を全文読み、分岐表で指定された参照ファイルも読みます。レーンはユーザーに質問できないため、スキルに質問するよう記載されている場合は、回答に依存しない作業を終え、レポートに質問を記載して実行を終了します
選択肢が未確定の、設計要素が多い作業	grilling.md（レーン側の部分。事実を整理し、決定事項を質問として返します）
リポジトリ外の事実に依存する場合	external-facts.md
Web またはフロントエンドの UI 変更	web-ui.md と ui-ux-pro-max スキル

執筆を伴うレーンはすべて、コード向けの ponytail も読み込みます。タスクを完全に解決する最小限の変更を求め、変更によって壊れる呼び出し元、テスト、フィクスチャもすべて更新します。また、省略した内容を 1 行で記載します。この行は内容の一部であり、レーンのレポートに残します。

レーンに必要な場合は、セッションにインストールされているタスク固有のスキルを追加します。たとえば、リグレッションテスト向けのテストファーストスキル、測定値向けのベンチマークチェックリスト、フロントエンド作業向けのフレームワークのベストプラクティススキルやリポジトリの UI ガイド、アクセシビリティやインターフェースのレビュー用スキル、プラットフォーム作業向けのプラットフォームスキル一式、リポジトリ独自のデリバリーまたはレビュースキルなどです。ブリーフには各スキルを記載してください。インストールされていないスキルは必須ではありません。

参照ファイルの内容がリポジトリのルールやプランのルール（必須のドキュメント更新など）と矛盾する場合は、そのルールを優先し、その旨をレポートに記載します。

5. ブリーフと起動

独立したすべてのレーンを、Agent、isolation: "worktree"、選択したmodelとeffortを指定して、1つのメッセージで起動します。プレーンなAgentサブエージェントを使い、Workflowスクリプトは使わないでください。そうすれば、後からレビューでの指摘を各サブエージェントに伝えられます（Workflowで起動したエージェントにメッセージを送ると、重複したライターが再開されます）。各アイテムは、そのレーンの開始時に「In progress」に移動し、ステータステーブルを表示します。

各ブリーフは自己完結しており、writing.md › Prose rulesに従い、次の項目をこの順に含めます。

1. ユーザーの目標を1文で記し、アイテムIDとタイトル、受け入れ基準の全文を貼り付けます（エージェントは会話のコンテキストを持たないためです）。計画アイテムの場合は、そのタスクまたはフェーズに関する計画の指示も貼り付けます。mstack-planタスクの場合は、タスクブロック全体、そのフェーズのGoal、Owns、Must not touch、Checkpointの各行、およびplan.md › Global constraintsを含めます。タスクのDone whenは、パート4に記載するエビデンスとします。
2. 作業開始前に全文を読むファイルを、セクション4にある絶対パスで指定し、読むべきリポジトリのルールと読み込むスキルも記載します。
3. ベース。レーンの最初のコマンドはgit merge --ff-only <lane base>です。レーンベースは<base>、またはこのレーンが依存する先行レーンの受け入れ済みブランチです。マージに失敗した場合、そのレーンは停止して報告します。続いて、担当するファイルと編集禁止ファイルを記載し、「編集禁止ファイルが必要になった場合は、編集せずに停止して報告すること」と明記します。
4. 作業完了を証明するエビデンスを記載します。コマンドと期待される結果を指定します。それらを明記できない場合、そのレーンのスコープはまだ確定していません。
5. ビルドの衛生管理。専用のターゲットディレクトリを使い（作業中のワークツリー間でビルドディレクトリを共有しないこと）、ビルドジョブ数に上限を設け、リポジトリ指定のツールチェーンを使います（PATH上で先に見つかるシステムインストールが固定バージョンを上書きし、コードとは無関係なエラーを引き起こす可能性があるため、先にバージョンを確認してください）。
6. 実行して結果をそのまま報告する検証項目（対象を絞ったテスト、型チェック、リントとフォーマット、リポジトリまたは計画の完了チェックリスト）を記載します。
7. 「明確なメッセージを付けて、自分のブランチにコミットしてください。プッシュ、PRの作成、CIの実行はしないでください。」
8. 「利用環境にアドバイザーツールがある場合は、診断や設計についてセカンドオピニオンを求めてもかまいません。」
9. 「受け取ったすべてのレビュー（コーディネーター、Codex、アドバイザーからのもの）にreceiving-review.mdを使って対応し、指摘ごとに行った対応を報告してください。」
10. writing.md › Lane reportsに従った報告形式を記載します。報告には、結果（done、partial、blocked）、ブランチ名、コミット、変更したファイル、各受け入れ基準とそのエビデンス、実行したコマンドと結果、該当する場合は外部事実の一覧、実施できなかったこととその理由、未決事項を質問形式で、提案する変更履歴の行を含めます。

6. レビューループ（各レーンの作業完了時）

リリースするすべての行に責任を持つのはあなたです。「完了」という要約は主張であり、証拠ではありません。

すべてのレビューは、あなたと各レーンが receiving-review.md に従って処理します。Codex レビュー、アドバイザーによるレビュー、レーンに送るあなた自身の指摘、CI レビューボット、人間による PR コメントが対象です。このルールをすべてのブリーフに記載し、指摘をレーンに送るすべてのメッセージでも繰り返してください。

1. レーンの差分を自分で確認します（git -C <worktree> diff <base>...HEAD）。受け入れ基準、スコープ（無関係な編集がないこと、レーン外のファイルがないこと）、動作を証明するテスト、リポジトリと計画のルールに照らして確認します。バグ対応レーンでは、このセクションの最後にある受け入れリストと報告内容を照合します。Web UI レーンでは、web-ui.md に記載されたレビュー前 UI チェックが実行され、合格していることを確認します。
2. セカンドオピニオンを得ます。

   • 判断が必要な事項（根本原因、スコープ、設計上のトレードオフ）については、advisor ツールを呼び出し、統合前のレビューにも利用します。セッションでツールを利用できない場合は、その旨を伝え、Codex と自分自身のレビューに頼ります。

   • codex スキル（プラグインとしてインストールされている場合は skill-codex:codex）を使って Codex レビューを実行します。スキルを読み込み、stdin のクローズ、stderr をコンテキストに含めないこと、Git リポジトリの確認、タイムアウトに関するルールに従い、セクション 0 で選択したモデルとエフォートを使用します。1 レーン分のコマンドは以下のとおりです。出力先はセッションのスクラッチパッドであり、ワークツリーには出力しません。

     codex exec -m <codex-model> --config model_reasoning_effort="<codex-effort>" --sandbox read-only -C <worktree> \
       "Read-only code review. Do not edit, write, commit or run anything that changes files. Review branch <branch> against <base> (git diff <base>...HEAD) for work items <item IDs and acceptance criteria>. Check correctness, regressions, missing tests and scope. Report each finding with file, line, the failing scenario and how to reproduce it. No findings is a valid result." \
       </dev/null 2> <scratchpad>/codex-review-<lane>.err > <scratchpad>/codex-review-<lane>.md
     

   • このワークフローでは、ワークフロー自体で処理方法がすでに決められているため、次の codex スキルの手順は適用されません。各 Codex 実行後にユーザーに確認すること（代わりに、receiving-review.md に従って出力をトリアージします）、セッションを再開できるとユーザーに伝えること、read-only 以外のサンドボックスを使うことです。すべてのレーンのワークツリーは Git リポジトリであるため、--skip-git-repo-check は決して渡さないでください。Codex レビューは毎回読み取り専用で実行します。

   • 異なるレーンの Codex レビューは、バックグラウンドのシェルコマンドとして並行して実行します。それぞれのタイムアウトは、codex スキルが <codex-effort> に指定する時間以上にしてください（high は 600 秒、xhigh は 1200 秒、max は 1800 秒）。出力ファイルが空でも、レビューに問題がなかったことにはなりません。.err ファイルの末尾を確認します。モデルまたはエフォートのエラーが示されている場合は、セクション 0 の指示に従って切り替え、再実行します。エージェントが解決できないエラー（ログインエラー）が示されている場合は、そのエラーを添えてレーンの Codex レビューが未実行であることを報告し、作業を続けます。何も示されていない場合は、完了前に実行が強制終了されたため、タイムアウトを延長して一度だけ再実行します。それも失敗した場合は、レーンの Codex レビューが未実行であることを報告します。

3. receiving-review.md に従って指摘をトリアージします。各指摘を実際のコードと照合し、Codex の指摘は受け入れる前に再現して確認します。誤った指摘は理由を添えて却下し、正しい指摘は残します。
4. 実際の指摘を同じレーンのエージェントに送り返し（そのエージェントの ID に SendMessage を送信）、自身のワークツリーで修正するよう伝えます。また、receiving-review.md に従って処理し、各指摘について修正したか、理由を添えて却下したかを報告するよう伝えます。レーンのコードにあなたがパッチを当ててはいけません。修正差分を再レビューし、修正が大規模な場合に限り Codex レビューを繰り返します。
5. 証拠が受け入れられないまま 2 ラウンドを終えた場合は、3 回目の同一ラウンドを行わず、working-style.md の再試行ルールに従ってレーンを停止し、計画を立て直します。
6. 作業が受け入れられたら、項目を Closed に移し、ステータステーブルを出力します。

根本原因の主張を受け入れる

バグレーンでは mstack-diagnose スキルに従うため、レポートにはその証拠が含まれています。レポートに以下がすべてそろっている場合に限り、レーンの根本原因の主張を受け入れてください。項目が欠けている場合は、そのレーンに不足分の提出を依頼してください。

1. シグナル：すでに実行したループコマンドと、その失敗出力を伏せ字にしたもの、またはシンボルの状態を含む保存済みの記録。
2. 再現した失敗が報告された症状と一致し、繰り返し発生することを示す証拠（または測定した発生率）。
3. 最小化したシナリオと、各要素が必要であることを示す内容。
4. 予測を含む優先順位付きの仮説、および確認済み、反証済み、未検証のいずれか。
5. どのプローブでどの予測を検証したかを、変数を一度に一つずつ変更して示したもの。パフォーマンスについては、ベースライン、実行回数、ばらつきも含めます。
6. mstack-diagnose による根本原因の層、および再現できない過去の事象の診断である場合を除き、Confirmed。再現できない過去の事象の診断の場合は、Supported と明記します。
7. 修正の場合は、修正前に失敗し修正後に成功した回帰テスト（失敗を強制した場合は変更のない diff）、元のループの再実行、修正の判定、さらに不安定な失敗の場合は事前に決めた成功実行回数。あるいは、両方の出力を添えた「適切な修正箇所なし」という記録。
8. レーンの差分に対する空のデバッグプレフィックス検索（git grep -n '\[DEBUG-'）と、正しいと確認された仮説をコミットメッセージに明記し、PR 本文に引き継ぐこと。

7. ローカルで統合して検証する

1. ベースから統合ブランチを一つ作成します。リポジトリでマージが推奨されている場合を除き、履歴を直線に保つため、各レーンのブランチをチェリーピックまたはリベースで取り込みます。競合は、構成上ほとんど発生しないはずです。競合が発生した場合は、自分で解決し、そのレーンのテストを再実行してください。
2. 予約していた共有ファイル（変更履歴の項目、ドキュメントのインデックス、プランのステータスファイルなど）を作成します。
3. 統合後のツリーで、リポジトリとプランの完了チェックリストをすべて実行します（対象を絞ったテストをまとめて実行し、型チェック、リンター、フォーマットチェックを行います。変更が複数のパッケージにまたがる場合は、より広範なテストスイートも実行します）。統合時の不具合は担当レーンのエージェントに戻すか、レーンがなくなっている場合は新しい小規模なエージェントに割り当てます。統合時に作業の不具合が発生した項目は、修正されるまで In progress に戻します。
4. プッシュする前に、統合差分全体をアドバイザーと Codex によって最後にレビューします。
5. プッシュ、トラッカーへのコメント、PR 本文、またはコメントの前に、機密データのチェックを実行します。実行時のコミット範囲に対して gitleaks（またはリポジトリのシークレットスキャナー）を実行し、追加された行から非公開ホスト、組織名と顧客名、実在する人物の名前、トークン、ローカルパスを検索します。公開リポジトリではプレースホルダーのみを使用します。漏えいに関する記述は曖昧にし、値を繰り返してはなりません。公開済みの履歴を書き換えるかどうかは、ユーザーが決めます。

8. 提出：PR は 1 件、CI は直列実行

• リポジトリにプルリクエスト（またはマージリクエスト）を受け付けるリモートがあり、ユーザーがローカルでの成果を求めていない場合は、すべての項目が Closed になるか、この場では完了できない理由を明示して報告されているときに限り、統合ブランチをプッシュして PR を 1 件だけ作成します。ホストの CLI を使用します（GitHub では gh）。セッションにホストの CLI がない場合は、ブランチをプッシュし、PR を開くためのリンクをユーザーに提示します。タイトルと本文は writing.md › Pull request body に従って記述します。ドラフトではなく、レビュー可能な状態で開きます。
• 該当するリモートがない場合、またはユーザーがローカルでの成果を求めている場合は、検証済みの統合ブランチで作業を止め、その名前を報告します。プッシュはしません。
• リポジトリで CI が実行される場合、この作業全体を通じて CI は一度に 1 件だけ実行します。つまり、実行中の CI（ワークフロー実行またはパイプライン）は常に 1 件だけにします。この PR の CI が実行中の間は決してプッシュせず、レーンブランチをプッシュせず、複数のブランチで CI を並行して実行しません。その 1 回の実行内のジョブは、CI の定義に従って並行実行してかまいません。そのため、ジョブやマトリックスの各実行単位を直列化しないでください。CI の失敗に対する修正は、現在の実行が終わってからまとめて 1 回のプッシュで行います。
• CI の失敗は、再実行する前に working-style.md の説明に従ってトリアージします。ログから原因を診断し（軽量なモデルでログを読み取ってもかまいません）、担当レーンを通じて修正し、ローカルで再検証してから 1 回だけプッシュします。
• PR に対するレビューボットおよび人間からのコメントは、他のレビューと同様に receiving-review.md に従って処理します。PR への返信はあなたのみが行います。

9. 最終報告

writing.md › Messages to the user に従って記述します。1 行目には目標と結果を記載します（例：「目標は計画内の 6 件のタスクを完了することでした。PR #40 がオープンしており、6 件中 5 件が完了しています。」）。2 行目にはユーザーが次に行うことを記載します。続けて、備考欄に根拠を記載した最終ステータス表を示します。その後、実施しなかったレビュー指摘を、却下または延期した理由とともにそれぞれ記載します（receiving-review.md › Log every finding を参照）。続けて、検証コマンドとその結果、実行しなかった項目とその理由、残存リスク、ビルドのサイズが大きかった場合は完了したワークツリーのディスクをクリーンアップするコマンドを記載します。