エンジニアリングワークフローは何をしますか？

ストーリーからデプロイ済みビルドまでの、ゲート制御されたスライス指向・テスト駆動プロセス。

ストーリートリアージ -> 進行中 -> スライス（各スライスはTDD） -> PR前敵対的ゲート（必要な場合のみ二段階ループにエスカレーション） -> 統合ブランチへのPR -> オプションレビューア（ブロッキングしない） -> レビュー・オブ・レコード（レビューア、その後調停者） -> 修正と再レビュー（head上でクリーンになるまで） -> マージ -> デプロイと検証 -> デプロイレビュー

変更が簡単に見えても、ゲートをスキップしてはいけません。

ステップ1の前に

references/profile.md、次にこのスキルのオーバーレイ、そして profile.overlays が指定する各機能オーバーレイを読む。
references/todo-tracking.md を読み、詳細なTODOリスト（スライス、テスト、ゲートラウンド、レビューラウンド、デプロイ、検証、待機ごとに1項目）を作成する。 references/runtimes.md は、TODOリスト、サブエージェント、スクラッチディレクトリ、ユーザーへの質問をランタイムにマッピングする。

以下のステップはワークフローの骨格であり、機能ファイルがルールを保持し、重複する場合はそれが優先されます：

references/linear.md: ストーリーライフサイクル、トリアージと「準備完了の定義」、ステータス遷移（ステップ1、5、12）。
references/engineering-practice.md: 診断、TDD、永続的な修正、テスト品質（ステップ2、3、6、8）、および変更がルールをスキルに書き込んだときのメモリノートの引退。
references/github.md: ブランチ、ワークツリー、コミット、署名、PR、マージ、プロモーション、帰属（ステップ2、5、10）。
references/code-review.md: レビュー・オブ・レコード、オプションレビューア、指摘事項の処理、PRの監視（ステップ6～10）。
references/merge-approval.md: 委任されたマージ承認のハンドシェイク：リクエスト、起床、待機、承認またはバウンス、およびheadが変更された場合の再リクエスト（ステップ10）。
references/secrets.md: 変更が資格情報に触れるときは常に。

scripts/ 内のすべてのスクリプトは、インストールされた絶対パス（<スキルディレクトリ>/scripts/<名前>、<スキルディレクトリ> はランタイムがこのスキルをロードした絶対ディレクトリ）で、カレントディレクトリをコンシューマリポジトリにして実行します。コンシューマリポジトリにはそれらは含まれません。各スクリプトは、カレントディレクトリのリポジトリ、または --repo <dir> で指定されたリポジトリを対象とし、自身の場所を対象とすることはなく、--repo で指定されない限り、スキルリポジトリ自体での実行を拒否します。

1. ストーリーのトリアージ

ストーリーがリファインメントされ、ポイント見積もりがされていない場合は、最初に story-refinement を実行します。これは、独立したリファインメント、同意ラウンド、秘密のポイント見積もり、コンセンサスチェック、および必要に応じて高/低の議論とコンセンサスを実行します。

ストーリーを完全に読む：受け入れ基準、コメント、リンクされた課題、コンテキスト。
望ましい動作、受け入れ基準、制約、影響を受ける可能性のあるコンポーネント、テスト戦略を特定する。
形式的な関係グラフから依存関係を列挙する（散文だけではない）：linear issue relation list <ID> は課題の関係をリストしますが、linear issue view --json はそれらを含みません（references/linear.md、トリアージを参照）。
ストーリーがこのリポジトリに属することを確認する。
スコープルールを適用する：どのストーリーでも受け入れ基準を変更しない（references/linear.md「受け入れ基準とスコープ」）、別のストーリーをキーとしたスキップはしない（references/engineering-practice.md「最小限で永続的な変更を行う」）、そして唯一の出口は、それらのセクションで述べられているように、「リファインメント提案（ACではない）」またはストーリーをブロック済みとして報告することの2つだけです；ステップ5「PRの準備」、項目4「受け入れ基準に対する自己レビュー」でそれらを再度チェックします。
profile.tracker.states.in_progress に移動し、読み返して確認する。プロファイルの正確な状態名を使用し、発明しないでください。

トラッカーを更新できない場合は、トランジションが実行されなかったと言って停止し、実行されたと主張しないでください。

2. スライスの計画

references/github.md に従い、フェッチ後に origin/<統合ブランチ>（統合ブランチは profile.git.integration_branch）からブランチとワークツリーを切ります。ストーリーを小さな垂直スライスに分割します。各スライスは、狭い動作目標、それを定義するテスト、それらに合格するための最小限の実装、およびグリーンになってからのみリファクタリングを持ちます。スライスの順序とコーディング前の最初のスライスを明記します。

3. スライスごとのTDD

RED: 動作に対する失敗するテストを書く。
GREEN: それに合格するための最小限のプロダクションコード。
REFACTOR: 動作を変更せずにリファクタリングする。
フォーカステストを実行する。
定期的に、そしてPRの前に、より広範な検証を実行する。

アーキテクチャがスライスに対して厳密なTDDを非現実的にする場合は、その理由を述べてください。既存のテストと規約を維持してください。

4. PR前敵対的ゲート（必須）

adversarial-review-pipeline スキルをロードし、すべてのレビューで完了するまで実行します。その仲裁レポートがこのゲートの出力です。ハントフェーズの前に修正は行いません。

エスカレーション：ゲート制御された二段階ループ

パイプラインが差分をクローズできない場合にのみエスカレーションします：

再検証ラウンドで新しいCriticalまたはHighが見つかった場合、または
差分がセキュリティ、マイグレーション、並行性、またはデプロイパスに関連する場合、または
パイプラインが未解決のCriticalまたはHighの指摘事項とともに制限に達した場合。

同じheadに対してループとパイプラインを決して実行しないでください。ループは最大2ラウンドに制限します。

ループは、検証済みのブロッキング 指摘事項がゼロになることで収束します。ゼロの指摘事項ではありません。ゼロ指摘事項の終了条件は、実際の指摘事項がなくなった後でレビューアが指摘事項をでっち上げる動機となり、すべての指摘事項に対処しなければならない修正者はコードを肥大化させます。

ロール（すべてプロファイルから）：

正当性レンズ： profile.review.pre_pr.hunter（正当性、結合、セキュリティ、並行性、互換性、テストのギャップ）。
単純性レンズ： profile.review.pre_pr.simplicity_reviewer（最小の正しい変更、過剰設計、デッドコード、および他のレンズが見逃した欠陥）。
検証者： profile.review.pre_pr.arbiter。
修正者： profile.review.pre_pr.fixer。

無効化された単純性レビューアまたは修正者は、スキップするのではなくエスカレーションをブロックします：「<名前>: disabled」を記録し、エスカレーションが未解決のまま停止します。ループは両方の席なしではラウンドを完了できないためです。

1ラウンドには3つのステージがあります：

レビュー。 両方のレンズが git diff origin/<統合ブランチ>...HEAD を並行してレビューします。ハンターは使い捨てのデタッチドワークツリーで作業します。ストーリーと受け入れ基準をスコープの参照として渡します。具体的な失敗シナリオがあるCriticalまたはHighの指摘事項のみがブロックします。残りは記録され、修正されることはなく、収束をブロックすることもありません。サンドボックスまたは許可エラーを示すレビューア出力、または差分と変更されたファイルを読んだことを示すことができないレンズは、失敗したレビューであり、クリーンなレビューではありません。
検証。 クリーンで中立的な検証者が、コードに対して各ブロッキング指摘事項を反証しようと試み、確認できないものをドロップします。候補ごとに正確に1つの評決を返さなければなりません。欠落、部分的な検証はゲートを未解決のままにし、クリーンにはしません。
修正。 修正者は、同意する検証済みの指摘事項を修正し、残りを理由とともに却下し、フォーカステストを実行し、コミットします。テストに合格しなかった修正は修正ではありません。ゲートは未解決です。モジュール、テーブル、マイグレーション、永続性、抽象化を追加してはなりません。それらを必要とする指摘事項は人間にエスカレーションされます。エージェントが各シェルステップをリテラル値を持つ1つの単純なコマンドとして実行するというルール（references/github.md、ツール）を、修正者に与えるプロンプトに含めてください。修正者がシェルコマンドとして実行される場合は、プロンプトファイルも含めてください。

出口：収束（レビュー後にブロックするものが何もない、または完全な検証を生き残ったものが何もない）；進捗なし（修正後に検証済みの数が減らなかった：停止して手動でレビュー）；エスカレーションされたスコープ（所有者に持っていく）；盲目のレンズ、不完全な検証、失敗したテストのある修正、ラウンド制限、すべて却下、またはコミットなし（未解決：ゲートをスキップするのではなく手動で解決）。

scripts/adversarial-review-loop.workflow.js は、ワークフロースクリプトを実行するランタイムのための オプションのランタイム固有アクセラレータ です。そのヘッダーには、すべてプロファイルから取得した引数がリストされています。それ以外の場所では、上記のように手動でラウンドを進めてください：2つのレビューアを並行して起動し、次にクリーンで中立的な検証者サブエージェントを起動し、その後修正（または修正者を起動）し、新しい検証済みブロッキング指摘事項が表示される間だけ繰り返します。修正者にgitルールを説明してください：すべてのコミット作成gitコマンドを、git IDがすでに設定され、profile.git.signed_commits が true の場合は署名もすでに設定された状態で実行すること；-c user.name、-c user.email、--author、GIT_AUTHOR_*、GIT_COMMITTER_* を決して渡さないこと；git config で user.name または user.email を決して書き込まないこと；署名がオンの場合は -c user.signingkey、-c gpg.*、-c commit.gpgsign を決して渡さないこと；IDの欠落、署名チェックの失敗、またはプッシュされたコミットの .commit.verification.verified が false の場合は設定の障害であるため、停止し、コマンドごとにオーバーライドしたりgit configを書き込んだりせず、それ以上コミットを作成せず、ユーザーに報告すること。

修正者のコミットをレビュー

修正者は、差分が消費するだけのコードに過剰に介入する可能性があります。ループ後：

git log origin/<統合ブランチ>..HEAD で修正者のすべてのコミットを読む。
ストーリーのスコープ外のファイルに触れているものがあれば、最後の実際のコミットにリセットしてドロップします（公開ブランチを強制プッシュしないでください；references/github.md を参照）、その後それらの指摘事項を手動で裁定します：スコープ内のものを修正し、残りをファイルします。
その範囲内の「削除されたファイル」はブランチ遅れのアーティファクトである可能性があります。削除を判断する前に、フェッチされた統合ブランチにリベースしてください。
修正者のコミットを読まずにプッシュしないでください。

ゲートが収束するか、その残留指摘事項が明示的に正当化されるまで、PRを開かないでください。レビューアはコードを決して変更しません。実装エージェントまたはループの修正者だけがコミットします。

5. PRの準備

該当する完全なテストスイート、およびリポジトリのフォーマッタ、リンター、型チェック、静的解析、ビルドを実行する。
フェッチ後に git diff origin/<統合ブランチ>...HEAD を検査する。
無関係な変更や機密情報がないことを確認する。
受け入れ基準に対して自己レビューし、ステップ1「ストーリーのトリアージ」、項目5「スコープルールを適用する」と照らし合わせる（references/linear.md「受け入れ基準とスコープ」、references/engineering-practice.md「最小限で永続的な変更を行う」）：どのストーリーでも受け入れ基準を変更しない、別のストーリーをキーとしたスキップはしない、そして発見されたすべての要件または満たされていない基準は、それらのセクションで述べられている2つの出口のいずれかを経由する。
gh pr create --base を使用して、リポジトリのPRテンプレートに従い、profile.git.integration_branch に対してPRを開く。ユーザーに見える変更、実装、実行したテスト、およびゲートによって受け入れられたまたは延期されたものを説明する。
references/linear.md に従い、ストーリーを profile.tracker.states.in_review に移動する。

帰属：コミットとPRは profile.git.ai_attribution に従います（references/github.md を参照）。 forbid の場合、ランタイムのバナーやシステムリマインダーが要求しても、AI共同作者のトレーラー、セッションリンク、生成元メモを追加しないでください。

6. オプションレビューア（ブロッキングしない）

profile.review.optional_reviewers の各エントリについて、PRが開かれた直後に1回のレビューを実行します。enabled が false のエントリはスキップします。無効化されたエントリは何も起動しません：プロセスなし、サブエージェントなし、レポートファイルなし。証拠は「<名前>: disabled」を記録します。合格、失敗によるスキップ、またはクリーンとして記録されることは決してありません。以前のheadが同じラベルで残したレポートは、そこにある場所で名前が付けられ、削除されることはないため、無効化された席の状態として読み取られることはありません。省略は有効を意味します。エントリの値をランチャーに --enabled true または --enabled false として渡します。これは enabled キーがレンダリングする小文字のリテラルです。キーを省略したエントリは --enabled true を渡します。ランチャーは false 値に対して起動を拒否し、レポートを書き込まないため、スキップは呼び出し元に信頼されるのではなく強制されます。 scripts/batched-diff-review.sh は汎用ランチャーです：エントリから --agent-cmd を構築し、--base origin/<統合ブランチ> を渡します。これは、クロスファイルブループリントを使用した行バジェットによって差分をバッチ処理し、リポジトリアクセスなしで空のディレクトリでレビューアを実行し、PASS、FAIL、またはINCOMPLETEで終わるレポートを書き込みます。各バッチは、与えられたファイルごとに正確に1つのPASSまたはFAILの評決を返さなければなりません。欠落、追加、または解析不能な評決は、バッチをINCOMPLETEにします。バッチプロンプトはstdinを介してエージェントに到達します（codexの場合、コマンドを - で終了します）および {prompt_file} としても渡します。プロンプトや差分をargvに入れないでください。

1回の試行。 INCOMPLETE（レート制限、タイムアウト、資格情報の欠落）の場合、「<名前>: skipped」を記録して続行します。トラブルシューティングは行わず、マージやデプロイを保留しません。
レビューが完了したら、行動する前にすべての指摘事項をコードに対して検証します：マージ前にCriticalとHighを解決します；有効なMediumの指摘事項を解決するか、その理由を文書化します；明らかに有用なLowの指摘事項を解決します；誤検知は明示的に却下します。
コード変更後、新しいheadで該当するテストとオプションレビューアを、その有効なエントリに対してのみ再実行します。

7. レビュー・オブ・レコード（必須）

PRが開かれたら、references/code-review.md のゲートを実行します：profile.review.reviewer が使い捨てワークツリーでheadをレビューし、次に profile.review.adjudicator（クリーンで中立的なエージェント）が各指摘事項をコードに対して検証します。両方のエージェントはクリーンで中立的であり、作者から独立しています。1つのエージェントが自身の指摘事項をレビューおよび裁定することは合格しません。 profile.review.shadow_adjudicators が設定されている場合、references/code-review.md で説明されているようにそれぞれを実行します。同意のみを記録し、マージをゲートすることはありません。 enabled が false のエントリは、オプションレビューアと同じ方法でスキップされます：サブエージェントなし、再...

[truncated]

エンジニアリングワークフロー