reviewing

レビュー

ドキュメント（調査、計画、ブレインストーミング）を構造的に批評し、抜け漏れ、弱点、品質上の問題を特定します。（コード差分をレビューする場合は、代わりに desplega:code-reviewing を使用してください。このスキルはドキュメントをレビューします。）

作業上の合意事項

ユーザー向けの質問はすべて AskUserQuestion を通じて行います（Autopilot でない場合）。規約については desplega:ask-user を参照してください。チャット上で箇条書きの質問を直接してはいけません。

ファイルレビューはデフォルトで有効です。自動レビューの後に実行してください（Autopilot の場合のみ省略します）。

出力モード

Autopilot でない場合は、開始時に一度だけ質問します。

質問	選択肢
「レビュー結果をどのように提示しますか？」	1. ドキュメントに正誤表セクションを追加する（推奨）、2. ドキュメントに修正を自動適用する、3. thoughts/*/reviews/ に別のレビュー ファイルを作成する

使用する場面

このスキルは、次の場合に有効になります。

• ユーザーが /review コマンドを呼び出したとき
• 別のスキルが完了時に reviewing スキルを参照したとき
• ユーザーがドキュメントのレビュー、批評、確認を依頼したとき

自律性モード

レビューの開始時に、自律性モードに応じて対話レベルを調整します。

モード	動作
Autopilot	レビュー全体を実行し、軽微な問題を自動修正して、最後に概要を提示します
Critical（デフォルト）	Critical／Important の指摘についてユーザーに確認し、Minor の指摘は自動修正します
Verbose	各指摘を順に説明し、変更前に確認します

自律性モードは呼び出し元のコマンドから渡されます。指定がない場合は、デフォルトで Critical を使用します。

プロセスの手順

ステップ 1：読み取りと分類

入力ドキュメントを最後まで読みます。パスとコンテンツの構造から、ドキュメントの種類を判定します。

パスに含まれる文字列	種類
/research/	調査ドキュメント
/plans/	計画
/brainstorms/	ブレインストーミング
/qa/	QA レポート

種類が曖昧な場合は、コンテンツの構造から推測するか、AskUserQuestion を使って確認します。

ステップ 2：構造の確認

ドキュメントの種類に応じて、必要なセクションが存在するか確認します。

調査ドキュメント：

• 必須フィールド（date、researcher、topic、status）を含む YAML frontmatter
• Research Question セクション
• Summary セクション
• file:line 参照を含む Detailed Findings
• Code References テーブル
• Open Questions セクション

計画：

• 必須フィールド（date、planner、topic、status）を含む YAML frontmatter
• Motivation と Related links を含む Overview
• Current State Analysis
• Desired End State
• What We're NOT Doing
• Implementation Approach（箇条書きの一行項目）
• Quick Verification Reference
• Changes Required と Success Criteria を含む Phases（3 つのサブセクションすべて：Automated Verification、Automated QA、Manual Verification）
• QA Spec（ある場合）は、インラインのシナリオではなく、desplega:qa が生成したドキュメントへのリンク
• Appendix（フォローアップ計画、脱線に関する注記、参照資料）

ブレインストーミング：

• 必須フィールド（date、author、topic、status）を含む YAML frontmatter
• Context セクション
• Q&A のペアを含む Exploration セクション
• Synthesis セクション
• Next Steps セクション

QA レポート：

• 必須フィールド（date、author、topic、status）を含む YAML frontmatter
• Context セクション
• Scope セクション（In Scope / Out of Scope）
• 各ケースについて Steps、Expected、Actual、Status を含む Test Cases
• Evidence セクション（Screenshots、Videos、Logs、または External Links）
• 全体のステータスと概要を含む Verdict セクション

ステップ 3：内容の分析

種類ごとの品質基準を適用します。

調査ドキュメント：

• 調査結果は、具体的なファイル名と行番号を示して裏付けられていますか？
• コードベースの根拠がない主張はありませんか？
• 調査されていない明らかな領域はありませんか？
• 未解決の質問は、本当に未解決ですか（調査結果から答えられるものではありませんか）？

計画：

• フェーズの抜けや、実装手順の不足はありませんか？
• 成功基準は、実行に移せるほど具体的ですか？
• コードベースに関する暗黙の前提はありませんか？
• エラー処理やロールバックについて説明されていますか？
• スコープが拡大するリスク（明示された範囲を超えて作業すること）はありませんか？
• フェーズの作り込みすぎはありませんか？提案された抽象化、レイヤー、新しい依存関係を desplega:engineering-standards（削除テスト、2 アダプターのルール、新しい依存関係のテスト）に照らして確認し、基準に満たない場合は Important として指摘してください。

ブレインストーミング：

• 重要な観点が未検討のままになっていませんか？
• 十分な検討を行う前に、結論を急いでいませんか？
• 制約と要件は明確に特定されていますか？
• このドキュメントは、調査や計画に進むための準備ができていますか？

QA レポート：

• すべてのテストケースに、実際の結果とステータスが記載されていますか？
• 失敗の証拠（スクリーンショット、ログ）は提示されていますか？
• 判定は、各テストケースの結果と一致していますか？
• エッジケースや探索的テストは記録されていますか？
• 外部参照（Sentry、PR、CI）は、該当する場合にリンクされていますか？

ステップ 4：ギャップの特定

不足している点や暗黙の前提を探します。

• 必要に応じて、主張をコードベースと照合します（検証のために codebase-analyzer エージェントを起動します）。
• 明示されていない前提を特定します。
• 内部矛盾がないか確認します。
• 外部参照が現在も有効か確認します。

ステップ 5：結果の提示

すべての指摘事項を、次の 3 つの重要度に分類します。

重要度	意味	対応
Critical	正確性または完全性を損なう要因であり、必ず対処が必要です	ユーザーと相談します
Important	重大なギャップまたは弱点であり、対処すべきです	ユーザーと相談します（Autopilot では自動修正も可）
Minor	書式、誤字、小さな不整合です	Verbose モードでない限り、自動修正します

重要度ごとに指摘事項をまとめ、要約をテキストで提示します。

ステップ 6：適用または相談

出力モードの設定に応じて対応します。

「Append errata」の場合：

• Minor の問題は、ドキュメント内で直接自動修正します。
• Critical／Important の項目については、ドキュメントの末尾に ## Review Errata セクションを追加し、次の内容を記載します。

  ## Review Errata
  
  _Reviewed: YYYY-MM-DD by [reviewer]_
  
  ### Critical
  - [ ] [Finding description and recommended action]
  
  ### Important
  - [ ] [Finding description and recommended action]
  
  ### Resolved
  - [x] [Minor issue] — auto-fixed
  

「Auto-apply」の場合：

• Minor の問題は、ドキュメント内で直接自動修正します。
• Important の問題は、ドキュメント内で直接自動修正します。
• Critical の指摘については、次の内容を使って AskUserQuestion を実行します。

質問	選択肢
「Critical の指摘が [N] 件あります。これらも自動修正しますか？」	1. はい、Critical の指摘も修正する、2. いいえ、Critical の項目は対応用の errata として残す

• 許可された場合は Critical の指摘を修正し、許可されなかった場合は未チェックの errata 項目として残します。
• すべての変更を要約した ## Review Errata セクションを追加します。

  ## Review Errata
  
  _Reviewed: YYYY-MM-DD by [reviewer]_
  
  ### Applied
  - [x] [Finding description] — auto-applied
  - [x] [Finding description] — auto-applied
  
  ### Remaining (if any Critical items were not auto-applied)
  - [ ] [Critical finding description and recommended action]
  

「Separate file」の場合：

• レビューを thoughts/*/reviews/YYYY-MM-DD-review-of-<original-slug>.md に書き込みます。
• 元のドキュメントへの参照を添えて、すべての指摘事項を記載します。

ステップ 7：ワークフローの引き継ぎ

レビューが完了したら、ドキュメントの種類（フロントマター、ファイルパス、または内容から判断）を特定し、適切な次のステップを提案します。

状況に応じた選択肢を使って AskUserQuestion を使用します。

ブレインストーミング文書をレビューしている場合：

質問	選択肢
「レビューが完了しました。このブレインストーミングの次のステップは何ですか？」	1. 調査を開始する（→ /research）、2. 直接計画を作成する（→ /create-plan）、3. ここで終了

調査文書をレビューしている場合：

質問	選択肢
「レビューが完了しました。この調査の次のステップは何ですか？」	1. 計画を作成する（→ /create-plan）、2. ここで終了

計画文書をレビューしている場合：

質問	選択肢
「レビューが完了しました。この計画の次のステップは何ですか？」	1. 実装を開始する（→ /implement-plan）、2. ここで終了

実装後の検証をレビューしている場合：

質問	選択肢
「レビューが完了しました。次のステップは何ですか？」	1. 完了としてマークする、2. 残りの項目に対応する

QA レポートをレビューしている場合：

質問	選択肢
「レビューが完了しました。この QA レポートの次のステップは何ですか？」	1. QA 後の検証を実行する（→ /verify-plan）、2. 見つかった問題に対応する、3. 完了

ドキュメントの種類が不明な場合は、汎用的な質問をします。

質問	選択肢
「レビューが完了しました。次のワークフローステップに進みますか？」	1. はい、次のステップを提案する、2. ここで終了

学びの記録

任意のサブスキル： このワークフロー中に重要な知見、パターン、注意点、または決定事項が得られた場合は、desplega:learning を使用して /learning capture 経由で記録することを検討してください。今後のセッションで他の人に役立つ学びに焦点を当ててください。

書き換え禁止ルール

重要： レビュアーが特定するのは問題点であり、ドキュメントを書き換えることはありません。指摘事項を提示し、元の作成者が対応できるようにします。例外：

• 軽微な自動修正（誤字、書式設定）は常に適用します
• 自動適用モードでは、ユーザーの許可に基づき、レビュアーが重要な修正と（必要に応じて）重大な修正を直接適用します

レビューとの連携

ファイルレビューはデフォルトで有効です（Autopilot を除く）。

• 自動レビューの後、インラインの人間によるコメントを得るために /file-review:file-review <path> を呼び出します
• file-review:process-review スキルでフィードバックを処理します