code-review

コードベース全体を対象に品質チェックを行い、改善点をレポートにまとめるスキル。全体・フロントエンド・バックエンドの観点に加え、一般的なリファクタリングレビューも行う。

引数

•引数なし: カレントディレクトリのプロジェクト全体をチェック
•パス指定: 特定のディレクトリやファイルに絞ってチェック

実行プロセス

フェーズ1: プロジェクト構造の把握

•プロジェクトのディレクトリ構成、使用言語・フレームワークを把握する
•フロントエンド / バックエンド / その両方かを判定する
•対象ファイルを全件リストアップする（.gitignore やビルド成果物は除外）
•該当するチェック観点を特定し、TodoWrite でタスク化する

フェーズ2: 品質チェック

判定した構成に応じて、該当するチェック観点をすべて実行する。 対象ファイルは全件チェックする。 ファイル数が多い場合はディレクトリ単位で分割して進める。

全体共通

チェック項目	基準
ファイル行数	各ファイルが 400 行以下に収まっているか。超過している場合は分割を提案
ディレクトリ構成	責務に応じた適切なディレクトリ分けがされているか
Makefile	Makefile が存在し、`make` または `make help` でコマンド一覧が確認できるか
Lint & Format	lint / format の設定が存在し、実行可能な状態か。未設定の場合は導入を提案
Git Hooks (husky)	husky が導入されているか。pre-commit で lint / format / test が実行される設定か。pre-push で build が実行される設定か。未設定の場合は導入を提案
環境変数管理	`.env.example` 等が整備されているか。シークレットがハードコードされていないか
エラーハンドリング	エラーが適切に処理されているか。握りつぶしや不適切な無視がないか
重複コード	同一・類似ロジックの重複がないか。共通化すべき箇所の特定
ログ設計	ログレベルの使い分けが適切か。構造化ログになっているか。機密情報がログに出力されていないか
テストカバレッジ・品質	テストが存在するか。Happy Path だけでなく異常系・境界値のテストがあるか。テストを実行して全件パスするか確認する。カバレッジ計測が可能な場合は実行し、カバレッジ率をレポートに含める
CI/CD 設定	CI が設定されているか。lint / test / build が自動化されているか
`.gitignore`	ビルド成果物、`node_modules`、`.env` 等が適切に除外されているか

フロントエンド

チェック項目	基準
Atomic Design	後述の Atomic Design ルールに準拠しているか（レイヤー分類、インポート方向、命名、HTML の atoms 化）
Composables 分離	ロジックが composables（hooks）に適切に切り出されているか。コンポーネントにビジネスロジックが混在していないか
命名規則	コンポーネント名、props、emits、変数名が一貫したルールに従っているか
責務分担	各コンポーネントが単一責任になっているか。肥大化したコンポーネントがないか
状態管理	グローバル状態とローカル状態が適切に使い分けられているか
型定義	型定義が適切に行われているか。`any` の乱用がないか
アクセシビリティ (a11y)	alt 属性、aria ラベル、キーボード操作対応が適切か
バンドルサイズ	不要な依存や tree-shaking できていない箇所がないか

Atomic Design ルール

下位レイヤーのみインポート可能。上位レイヤーをインポートしてはならない。

レイヤー	Prefix	インポート可能	役割
Atoms	A	types のみ	最小単位の UI コンポーネント
Molecules	M	Atoms	汎用的な複合コンポーネント（ドメイン知識なし）
Organisms	O	Molecules, Atoms	ドメイン固有のコンポーネント
Templates	T	Organisms, Molecules, Atoms	ページの骨格
Pages	-	Templates のみ	ルーティングとデータ取得
Layouts	-	Organisms のみ	共通レイアウト

命名規則:

•Atoms: A + PascalCase（例: AButton, AInput）
•Molecules: M + PascalCase（例: MModal, MCard）
•Organisms: O + PascalCase（例: OTaskCard, ODocumentTree）
•Templates: T + PascalCase + Page（例: TLoginPage, TTasksPage）

HTML の atoms 化:

•レイアウト要素も含め、すべての HTML 要素を Atoms コンポーネントとして定義する
•素の HTML タグを直接使わず、対応する Atoms を使用する

許容される例外:

•再帰コンポーネント: ツリー構造等で同レイヤーのコンポーネントをインポートすることを許容（例: ODocumentTree → ODocumentTreeItem）
•Organisms 内の Toolbar 系: 同ドメイン内の関連 Toolbar コンポーネントの使用を許容（例: ODocumentEditor → ODocumentToolbar）

バックエンド

チェック項目	基準
レイヤー分離	Service / Router / Handler / Middleware が適切に分離されているか。各レイヤーの責務が明確か
パス単位の分割	Router / Handler / Service がリソースやパスごとにファイル分割されているか。1ファイルに複数リソースの処理が混在していないか
コードドキュメント	公開関数・型にドキュメントコメント（Go: godoc、TS: TSDoc/JSDoc）が記載されているか。ファイル数が多いパッケージ/モジュールではパッケージ概要（Go: `doc.go`、TS: `index.ts` の先頭コメント等）が整備されているか
Swagger / API ドキュメント	Swagger（OpenAPI）対応がされているか。エンドポイントの定義が実装と一致しているか
命名規則	関数名、変数名、パッケージ名が一貫したルールに従っているか
バリデーション	入力バリデーションがハンドラー層で適切に行われているか
認証・認可	ミドルウェアで適切に認証・認可が処理されているか。保護すべきエンドポイントが保護されているか
DB アクセス	リポジトリ / データアクセス層が分離されているか。SQL インジェクション等のリスクがないか
レートリミット	API の過負荷保護が実装されているか
ヘルスチェック	`/health` 等のヘルスチェックエンドポイントが存在するか
グレースフルシャットダウン	シグナルハンドリングが適切に実装されているか。接続中のリクエストが安全に完了するか

リファクタリング観点

チェック項目	基準
関数の複雑度	関数が長すぎる、ネストが深すぎる箇所がないか
依存関係	不要な依存、循環依存がないか
マジックナンバー / マジックストリング	定数化すべきリテラル値が散在していないか
デッドコード	使われていないコード、到達不能なコードがないか
テスタビリティ	テストしにくい構造になっていないか。依存の注入が可能か
パフォーマンス	明らかな N+1 クエリ、不要なループ、メモリリークのリスクがないか
エラー多発リスク	nil/null 参照、未チェックの戻り値、型変換の失敗、境界値の未考慮、競合状態など実行時エラーが発生しやすい箇所がないか

フェーズ3: レポート生成

•
出力先を判定する
- •gh コマンドが利用可能かつ git リポジトリ内 → GitHub Issue として作成する（タイトルは review: コード品質レポート(<ブランチ名>, <YYYY-MM-DD>) の形式）
- •上記が使えない場合 → プロジェクトルートに code-review-report.md を生成する
•レポートの要約をユーザーに報告する

レポート形式

markdown

# Code Review Report

> 生成日時: YYYY-MM-DD HH:MM
> 対象プロジェクト: <プロジェクト名>
> チェック対象: 全体 / フロントエンド / バックエンド

## サマリー

| 指標 | 値 |
|-----|-----|
| チェックしたファイル数 | N |
| テスト結果 | N passed / N failed / N skipped |
| カバレッジ | N%（計測不可の場合は「-」） |
| 検出した指摘数 | N |
| 重大度 🔴 | N |
| 重大度 🟠 | N |
| 重大度 🟡 | N |
| 重大度 🟢 | N |

## 全体共通

### 🔴 重大

#### 1. <指摘タイトル>
- **ファイル**: `<ファイルパス>:<行番号>`
- **問題**: 具体的な問題の説明
- **推奨**: 改善案

### 🟠 重要

...

### 🟡 提案

...

### 🟢 軽微

...

## フロントエンド

### 🔴 重大

...

### 🟠 重要

...

### 🟡 提案

...

### 🟢 軽微

...

## バックエンド

### 🔴 重大

...

### 🟠 重要

...

### 🟡 提案

...

### 🟢 軽微

...

## リファクタリング

### 🔴 重大

...

### 🟠 重要

...

### 🟡 提案

...

### 🟢 軽微

...

重大度の基準

重大度	基準
🔴 重大	セキュリティリスク、データ損失の可能性、本番障害に直結する問題
🟠 重要	アーキテクチャ違反、レイヤー分離の欠如、テスト不能な構造
🟡 提案	可読性・保守性の改善、リファクタリング候補
🟢 軽微	命名の改善、コードスタイル、些細な改善

ルール

•推測で指摘しない。実際のコードを確認して裏付けを取ること
•指摘には必ず該当ファイルと行番号を示すこと
•改善案は具体的に示す。「改善すべき」だけで終わらせない
•🔴（重大）または🟠（重要）の指摘は必ずレポートに含める
•🟡（提案）や🟢（軽微）は、明確なメリットがある場合のみレポートに含める
•プロジェクトの規模に応じて優先度の高い箇所から順にチェックする
•フレームワークや言語の慣習を尊重する。プロジェクトの既存スタイルに合わない指摘はしない
•各フェーズの進捗は TodoWrite ツールで管理する