--- user-invocable: true description: "[レビュー] Basic Review - typo/命名/フォーマットの表面チェック" --- # [レビュー] Basic Review ## 入力: $ARGUMENTS - PR番号(例: `#123` または `123`) - 省略時: 現在のブランチの差分をmainと比較 --- ## 🎯 目的 - **表面的なミス**を素早く検出する - typo、スペルミス、命名規約違反、フォーマット問題を洗い出す - 深い設計レビューは `/deep-review` に任せる --- ## 対象範囲 | チェック項目 | 内容 | |-------------|------| | **typo/スペル** | 変数名、コメント、文字列リテラルの誤字 | | **命名規約** | camelCase/snake_case の混在、略語の不統一 | | **フォーマット** | インデント、空白、改行の不統一 | | **明らかなバグ** | 未使用変数、到達不能コード、明らかなnull参照 | | **コメント品質** | 古いコメント、意味のないコメント | --- ## 実行手順 ### 1. 差分取得 **PR番号指定時:** ```bash gh pr diff {PR_NUMBER} ``` **省略時(現在ブランチ):** ```bash git diff main...HEAD ``` ### 2. 変更ファイル一覧 ```bash # 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. 結果出力 ```markdown ## 📝 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番号指定時(⚠️ 確認あり):** ```bash gh pr comment {PR_NUMBER} --body "{レビュー結果}" ``` **省略時:** - 標準出力にレビュー結果を表示 --- ## 注意事項 - **設計の良し悪しは判断しない**(それは `/deep-review` の役割) - **主観的な指摘は避ける**(客観的に問題と言える箇所のみ) - **自動修正可能なものは修正コマンドを提示**(例: `pnpm lint --fix`) --- ## 自己評価 - **成功自信度**: (1-10) - **一言理由**: {短く理由を記載}