| name | aota-review |
| description | GitHub PR の変更内容を先に解説し、ユーザーの理解確認を挟みながら対話的に レビューを進めるワークフロー。 Trigger: ユーザーが `$aota-review` を明示した場合、PR の URL または番号を 提示して「まず変更内容を理解したい」「解説を受けてから一緒にレビューしたい」 など段階的・対話的な進行を求めた場合、またはこのスキルで開始したレビューの 続行を明示した場合に使用する。 Do not trigger: PR の URL または番号とともに単にレビュー、merge 可否、問題点、 特定観点での検証、または最終結論までの自律的な作業を求められた場合には 使用しない。PR を既に理解した後の単発の説明・要約・質問回答、PR 説明文の 作成・更新、コード修正、レビューコメントへの対応、CI 修正、または PR を 対象としない一般的なコードレビューにも使用しない。 |
Aota Review
GitHub CLI（gh コマンド）を使用して PR レビューを行う。
ワークフロー
1. PR 情報の取得
ユーザーが PR の URL または PR 番号を指定する。
gh pr view <PR番号> --json title,body,headRefName,baseRefName,author,files
取得情報：タイトル、説明文、変更ファイル一覧、ブランチ名、作成者
2. ブランチの切り替え
git fetch origin <ブランチ名> && git checkout <ブランチ名>
3. main との差分確認
git diff origin/main...HEAD -- <対象ファイル>
変更ファイルごとに差分を取得し、全体像を把握する。
4. 変更内容の理解と解説
- 変更ファイルの中身を読み、処理の流れを理解する
- ユーザーにとって理解しやすい順序で解説する
- 全体フローを図解・構造化して示す
- 「どこが処理の肝か」を明確にする
- 各ステップの詳細へ掘り下げる
- ユーザーからの質問に答えながら理解を深める
- あなたはここでレビューはしない。あくまで解説を行う。
重要: ユーザーが変更内容を理解したことを確認してから、次のステップに進む。ユーザーから明示的な承認が得られた場合にのみ次のステップに進む。
5. レビューの実施
5.1 codex review の実行確認
ユーザーに「codex review を実行してもよいか？」と確認する。
許可された場合：
codex review --base origin/main
5.2 自身によるレビュー
codex review の実行有無にかかわらず、自分自身でもコードを読んでレビュー観点を洗い出す。
観点：
- 実装の正確性
- 既存コードとの整合性
- エッジケースの考慮
- ドキュメント・コメントの妥当性
6. レビュー観点の整理
codex review の指摘（実行した場合）と自分の観点を統合する- 問題点を優先度付けする（P1, P2 など）
- 各問題点について根拠を明確にする
- ドキュメント参照
- 実装コードの調査
- 既存コードとの整合性確認
7. 問題点の検証と議論
各指摘点について、ユーザーと議論する。
- 「これはバグか、意図的な仕様変更か」を確認する
- 指摘が妥当かどうかを検証する（調査の結果 close になることもある）
- 各指摘点に対して、PR にコメントする文章を一緒に考える
- 指摘の背景・根拠
- 推奨する対応（修正案、コメント追加、議論の呼びかけなど）
- 文章のトーン（blocker か suggestion か）
スコープ外
以下はこのスキルの範囲外とする：
- コードの修正対応
git commit / git push- PR へのコメント投稿
これらはユーザー自身が行うか、別途明示的に指示があった場合にのみ対応する。
