staged-review-flow

段階的レビューのフロー

内部共有スキルです。このスキルを参照するワークフローでは、ステージ番号、成果物の保存先、意図的な相違点を維持してください。このスキルが、レビューと検証レポートのフローに関する唯一の信頼できる情報源です。

前提条件の確認： このスキルの読み込み時に、宣言されている依存関係がそれぞれ利用可能か確認してください。1つでも不足している場合は、停止して npx skills add FuDesign2008/open-skills -g --skill '*' --yes を出力し、レビューを黙って簡略化しないでください。

プレースホルダーの契約

プレースホルダー	意味	参照するワークフローが指定する内容
{next-stage}	レビュー合格後に進むステージ	番号と名前
{artifact-sink}	レビュー記録または設計概要の保存先	ホスト固有のパスまたは成果物
{extra-dimensions}	ホスト固有の追加評価項目	必須の確認事項とその保存先
{batch-overcap-behavior}	バッチコンテキストで自動の3ラウンド制限を超えた後のアクション	ホスト固有の動作、または N/A

ホストワークフローのステージ番号、OpenSpec のパス、Jira の状態遷移、バッチポリシーをハードコードしないでください。

レビューの契約

1. 必ず solution-review フレームワーク全体を読み込んで実行してください。可逆性に応じた深さで、すべてのコア評価項目と戦略的評価項目を確認してください。コードに影響するソリューションについては、長期的なコストを伴う戦略的評価項目（コスト対価値、チームの認知的適合性）を、可逆性の分類にかかわらず、少なくとも標準の深さで確認してください。
2. ソリューションがコードに影響する場合（スクリプトや生成された設定コードを含むソースファイルの作成または変更）、その適用規則に従って code-design-review のレイヤー A／B／C も読み込んで実行してください。
3. 共有レビューの後に {extra-dimensions} を適用してください。これらの確認項目はレビューを補足するものであり、solution-review に取って代わるものではありません。
4. レポートでは2つの軸を分けてください（ラベルは変更してもかまいませんが、意味は必ず維持してください）。
   • 標準 — 設計／品質／問題点／セキュリティの適合性（solution-review の戦略的・コアな品質評価項目、および適用される場合の code-design-review）。
   • 仕様 — 選択したソリューション、チケット、OpenSpec の差分／明示された要件への適合性。 2つの軸は並行して確認してもかまいません（例：別々のサブエージェントを使用）。**両方を区別のない単一の評価リストにまとめてはいけません。**一方の軸が合格しても、もう一方の不合格を見えなくしてはいけません。
5. ブロッキング条件を集約し、全体結果を合否の2択にしてください。
   • **合格：**どちらの軸にも {extra-dimensions} にも、未解決のブロッキング問題がないこと。
   • **不合格：**いずれかの軸に、未解決のブロッキング問題が1つ以上あること。
6. レビュー記録と合格した設計概要を {artifact-sink} に書き込んでください。

レビューループとゲート

• 自動モードでは、不合格の場合、ソリューションを最適化し、最適化の内容を記録してから、レビュー全体を再実行してください。初回レビューと最適化後の再レビューは最大2回で、合計3ラウンドまでです。
• 上限に達した場合は、{batch-overcap-behavior} にホストのバッチ処理が指定されていない限り、ユーザーの判断を仰いで一時停止してください。
• 手動モードでは、レビューレポートを提示し、ユーザーが承認、修正、またはソリューションの再選択を行うまで待機してください。ユーザーの明示的な判断なしに先へ進んではいけません。
• 合格の場合は {next-stage} に進みます。不合格の場合は、ソリューションの最適化を続けるか、ユーザーの指示に従ってソリューションの選択に戻ります。

設計概要

レビュー合格後、目標、対象外事項、決定事項、リスクと緩和策、未解決の質問を含む構造化された設計概要を出力してください。これはレビュー出力の一部であり、{artifact-sink} で永続化が求められていない限り、別個の必須ファイルではありません。

検証レポートの誠実性

検証結果では、必ず実行状態を明示してください。

• 実行済み： コマンドまたは操作と、簡潔な出力／結果の要約を含めます。
• 保留中： まだ必要な手動操作を具体的に示します。

設計したシナリオや、正しいと推測した内容を、完了済みの検証として報告しないでください。ブラウザーなどでの手動操作ができない場合は、実行可能な手順を示して保留中としてください。

completion-evidence-discipline に従って作成してください： 実行済み／合格の主張が有効なのは、そのスキルの鉄則に従い、現在のターンで得た新たな証拠に裏付けられている場合に限ります。検証時に completion-evidence-discipline を読み込み、その文章をホストに貼り付けないでください。

統合ガイド

参照するワークフローでは、次のことを行う必要があります。

1. frontmatter の依存関係に staged-review-flow を宣言し、通常の依存関係チェックを実施します（推移的に completion-evidence-discipline も必要になります）。
2. レビューステージでこのスキルを読み込み、該当する場合はすべてのプレースホルダーを番号と名前で対応付けます。
3. ホスト側のオーケストレーションとして、ステージの終了条件の文言、{extra-dimensions}、{artifact-sink}、{batch-overcap-behavior} のみを残します。
4. 検証ステージでは、このスキルの誠実性ルールと completion-evidence-discipline の両方を参照します。説明は最大で1～2文にしてください。

二択の表、ブロッキング項目のリスト、3ラウンドのループに関する説明、設計サマリーテンプレート、2軸の定義、検証の誠実性に関する記述をホストで重複させないでください。