[レビュー] Basic Review

入力: $ARGUMENTS

• PR番号（例: #123 または 123）
• 省略時: 現在のブランチの差分をmainと比較

🎯 目的

• 表面的なミスを素早く検出する
• typo、スペルミス、命名規約違反、フォーマット問題を洗い出す
• 深い設計レビューは /deep-review に任せる

実行形態（文脈遮断・必須）

• 実装と同じ文脈でこのレビューを実行しない。実装した本人（同一セッション文脈）は自分の選択に錨づけされ、違和感を検出できないため
• 実装ループ（auto-task / auto-design 等）から呼ばれた場合は、code-reviewer サブエージェント（.claude/agents/code-reviewer.md）に モード: basic と PR番号/ブランチ名だけを渡して実行する。実装の経緯・意図の弁明を渡さない（文脈遮断≠情報遮断: レビュアーは差分・rdd.md・rules等の永続成果物を自分で読む）
• 人間が実装文脈のないセッションで直接 /basic-review を起動した場合は、そのまま実行してよい
• 自律ループの収束判定は「要修正（Must Fix）件数」のみで行う。所感・応援メッセージは人間向けの出力であり、収束判定・重大度に影響させない

モード自動判定

対象ファイルのパスで自動判定:

• doc/**/*.md → 設計書モード
• それ以外 → コードモード（従来動作）

対象範囲

コードモード

設計書モード

Docコメント転記（コード変更時）

PRにコード変更が含まれる場合、対応する設計書の内容をDocコメントに転記:

1. 変更ファイルと設計書の対応を特定
   • src/auth/* → doc/generated/reverse/modules/auth.md
2. 設計書から該当箇所を抽出
   • 関数/クラスの「責務」「設計意図」を特定
3. Docコメントに転記（提案）

   /**
    * ユーザー認証を実行する
    *
    * @description 設計書より: JWT検証後、セッションを生成。
    *              失敗時は監査ログを記録して拒否。
    * @see doc/generated/reverse/modules/auth.md
    */

💡 設計書とコードのDocコメントを連動させ、乖離を防ぐ

実行手順

1. 差分取得

PR番号指定時:

gh pr diff {PR_NUMBER}

省略時（現在ブランチ）:

git diff main...HEAD

2. 変更ファイル一覧

# PR番号指定時
gh pr view {PR_NUMBER} --json files --jq '.files[].path'

# 省略時
git diff --name-only main...HEAD

3. レビュー実行

各ファイルの差分に対して以下をチェック：

1. typo/スペル
   • 変数名・関数名のスペルミス
   • コメント内の誤字
   • 文字列リテラル内の誤字
2. 命名規約
   • プロジェクトの命名規約との整合性
   • 一貫性のない命名（同じ概念に異なる名前）
3. フォーマット
   • インデントの乱れ
   • 不要な空白・改行
   • 行末スペース
4. 明らかなバグ
   • 未使用のimport/変数
   • console.log/debugger の残存
   • 明らかな論理エラー

4. 結果出力

## 📝 Basic Review 結果

### 対象
- PR: #{PR_NUMBER} または ブランチ: {branch_name}
- ファイル数: {count}

### 🔴 要修正（Must Fix）
| ファイル | 行 | 種別 | 内容 |
|----------|-----|------|------|
| src/foo.ts | 23 | typo | `recieve` → `receive` |
| src/bar.ts | 45 | 未使用 | `import { unused }` |

### 🟡 推奨（Should Fix）
| ファイル | 行 | 種別 | 内容 |
|----------|-----|------|------|
| src/foo.ts | 30 | 命名 | `getData` → より具体的な名前を推奨 |

### 🟢 問題なし
- フォーマット: OK
- コメント品質: OK

### サマリ
- 要修正: {count}件
- 推奨: {count}件

---

### 💬 所感
{レビュアーとしての所感を記載}

**良かった点:**
- {具体的に良かった点を挙げる}
- {例: 命名が一貫していて読みやすい}
- {例: 適切なエラーハンドリング}

**応援メッセージ:**
{前向きなコメントで締める。例: 「全体的にクリーンなコードです！細かい点を修正すれば完璧ですね」}

出力先

PR番号指定時（⚠️ 確認あり）:

gh pr comment {PR_NUMBER} --body "{レビュー結果}"

省略時:

• 標準出力にレビュー結果を表示

注意事項

• 設計の良し悪しは判断しない（それは /deep-review の役割）
• 主観的な指摘は避ける（客観的に問題と言える箇所のみ）
• 自動修正可能なものは修正コマンドを提示（例: pnpm lint --fix）

自己評価

• 成功自信度: (1-10)
• 一言理由: {短く理由を記載}