factory-review

Factory Review

価値： Communication -- factory モードでは、人間の注意を重要な判断に集中させます。このスキルにより、レビューインターフェースが明確で簡潔、かつ実行可能なものになり、人間はコードを一行ずつ読み直さなくても、意味のある監督を行えます。

目的

factory モードのビルドにおけるフェーズ 3 の人間によるレビュー体験を構成します。監査証跡の要約、PR ダイジェスト、振り返りの統合、品質傾向レポート、自律性の調整インターフェースを作成します。目標は、最小限の時間で重要な情報を把握できるレビューです。

プラクティス

監査証跡の要約

.factory/audit-trail/ から読み取り、簡潔なビルド概要を提示します。

• 完了したスライス： 数を示し、スライス ID とタイトル別に一覧表示します
• 手戻り率： 手戻りサイクルが必要だったスライスの割合
• ゲート失敗の内訳： ゲート種別（tdd、review、ci、mutation）ごとの失敗数
• 保留中のエスカレーション： 件数と、未解決の各エスカレーションの簡単な説明

ダッシュボード形式でまとめます。まず数値を示し、人間から求められた場合にのみ詳細を続けます。

PR ダイジェスト

ビルド内でマージされた PR ごとに、1 段落の要約を作成します。

1. 変更内容： 機能または修正の内容を平易な言葉で説明します
2. 対象スライス： この PR が実装する垂直スライスの ID
3. ペア： 実装を担当した 2 人のエンジニア
4. ゲートの結果： 各品質ゲート（tdd、review、ci、mutation）の合格／不合格
5. 手戻り回数： すべてのゲートに合格するまでの手戻りサイクル数

各ダイジェストは 3～5 文に収めます。一般的なビルドセッションであれば、人間が 1 分以内にすべての PR ダイジェストに目を通せるようにします。

振り返りの統合

チームの振り返り（.factory/audit-trail/retrospectives/ に保存）から得られた知見を集約し、パターンを提示します。

• 繰り返し発生する手戻りの原因： どのような問題が最も多くの手戻りを引き起こしましたか？
• ペアの有効性： 手戻りサイクルが最も少なかったペアはどれですか？
• ドメインのホットスポット： ドメインモデルのどの領域で、議論や修正が最も多く発生しましたか？
• プロセス上の摩擦： チームが特定した障害や改善案はありますか？

テーマごとにグループ化した箇条書きで提示します。論評は加えず、チームの発言を報告します。

品質傾向の追跡

.factory/audit-trail/metrics/ から読み取り、傾向を提示します。

指標	現在	前回	傾向
Mutation スコア	%	%	上昇／下降／横ばい
手戻り率	%	%	上昇／下降／横ばい
スライスあたりのサイクル時間	所要時間	所要時間	上昇／下降／横ばい
種別ごとのゲート失敗率	件数	件数	上昇／下降／横ばい

「前回」とは、直近で完了したビルドセッションを指します。前回のセッションがない場合は、比較列を省略します。

調整インターフェース

レビュー中に .factory/config.yaml の変更を受け付けます。変更案ごとに、次の手順を行います。

1. 検証： 変更に矛盾がないことを確認します（例：自律性レベルが conservative の場合は自動マージを有効にできない、別の設定が依存するゲートを無効にできない）
2. 影響の説明： この設定を変更すると動作がどう変わるか、具体的に説明します
3. 適用または却下： 有効な場合は変更を適用します。無効な場合は理由を説明し、最も近い有効な代替案を提示します

設定変更を黙って適用してはいけません。.factory/config.yaml に書き込む前に、必ず人間に確認します。

エスカレーションのレビュー

保留中の各エスカレーションについて、詳細な状況を提示します。

1. 該当するゲート： エスカレーションを引き起こした品質ゲート
2. 手戻りの試行回数： 試行した手戻りサイクル数
3. 試した内容： 各手戻りの試行についての簡単な要約
4. 現在の状態： 現時点のコードの状態（差分または説明）
5. 推奨事項： チームが提案する解決策（ある場合）

人間が、解決、上書き、または追加の手戻りのため差し戻すかを決定します。

適用に関する注記

すべてのモードで助言的に適用します。要約と傾向レポートは、形式を自己遵守する運用規律です。

厳格な制約：

• 設定変更を黙って適用しないこと：[H]

制約

• 「意見を加えない」：チームの発言を報告し、チームの発言について自分がどう考えるかは述べません。「チームは X について話し合い、Y と決定しました」は報告です。「チームは賢明にも Y と決定しました」は意見を加えています。「チームは X について話し合いましたが、Z という重要な点を見落としました」は意見を加えています。懸念がある場合は、明確に自分の分析としてラベル付けし、分けて提示してください。
• 設定の検証：「設定変更を黙って適用しない」とは、ユーザーが以前に「設定を進めてください」と言っていた場合でも、設定変更のたびに明示的なユーザー確認を得るという意味です。個々の変更ごとに確認します。設定変更に対する包括的な許可はありません。

検証

ファクトリーレビューセッションの完了後、次の項目を確認してください。

• 現在のビルドメトリクスとともに、監査証跡の概要が提示された
• マージされたすべての PR にダイジェストがある（省略された PR がない）
• レトロスペクティブの統合に、セッション中のチームのレトロスペクティブがすべて含まれている
• 品質の傾向に、前回のセッションとの比較が含まれている（可能な場合）
• 保留中のエスカレーションがすべて、十分な背景情報とともに提示された
• 設定変更は適用前に検証された
• 各エスカレーションについて、人間による確認または却下が行われた

基準を満たしていない項目がある場合は、該当するプラクティスを見直してください。

依存関係

このスキルでは、ファクトリーモードのインフラストラクチャとして pipeline スキルが必要です。 次のスキルと連携します。

• pipeline： フェーズ 2 でパイプラインオーケストレーターが生成した監査証跡ファイルとメトリクスを読み取ります
• ensemble-team： レトロスペクティブの統合ではチームのレトロスペクティブ出力を読み取り、ペアの有効性データにはペアリング履歴を使用します
• ci-integration： ゲート失敗データには、ci-integration スキルからの CI_RESULT パケットが含まれます

依存関係が不足していますか？次のコマンドでインストールしてください。

npx skills add jwilger/agent-skills --skill pipeline