[レビュー] 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 → 設計書モード
• それ以外 → コードモード（従来動作）

---

対象範囲

コードモード

チェック項目	内容
typo/スペル	変数名、コメント、文字列リテラルの誤字
命名規約	camelCase/snake_case の混在、略語の不統一
フォーマット	インデント、空白、改行の不統一
明らかなバグ	未使用変数、到達不能コード、明らかなnull参照
コメント品質	古いコメント、意味のないコメント
SSOT迂回	色/文言/効果値の直書き（マジックバリュー）。検出したら design-ssot の昇格手順（SSOT追加→ミラー追加→一致テスト→参照差し替え）を提案

設計書モード

チェック項目	内容
Markdown構文	壊れたリンク、見出し階層の乱れ
Mermaid図	構文エラー、描画可能性
typo/表記	誤字、用語の不統一
リンク切れ	内部リンク（他の.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)
• 一言理由: {短く理由を記載}