品質レビュースキル

トリガー条件

• •ユーザーが「レビューして」「品質チェック」「コードを見て」と言った時
• •機能実装完了後の自動チェックとして

レビュー基準

1. 可読性（Readability）

• • 関数名・変数名は意図を明確に表現しているか
• • 1関数の行数は50行以内か
• • ネストは3階層以内か
• • マジックナンバー/マジックストリングはないか

2. 保守性（Maintainability）

• • 単一責任原則（SRP）に従っているか
• • 重複コード（DRY違反）はないか
• • 適切な抽象化がされているか
• • 依存関係は明確か

3. 型安全性（Type Safety）

• • any型の使用はないか
• • nullチェックは適切か
• • 型ガードは正しく実装されているか

4. エラーハンドリング

• • try-catchが適切に使用されているか
• • エラーメッセージは分かりやすいか
• • エッジケースが考慮されているか

実行手順

1. •

   対象ファイルの特定

   • •変更されたファイルを git diff --name-only で取得
   • •または指定されたファイル/ディレクトリを対象とする
2. •

   静的解析の実行

   bash

   # ESLint実行（設定がある場合）
   npx eslint --format=json [対象ファイル] 2>/dev/null || true
   
   # TypeScript型チェック
   npx tsc --noEmit 2>&1 || true
   

3. •

   AIによる意味論的レビュー

   • •上記チェックリストに基づき各ファイルを評価
   • •問題点を重要度順（Critical > Warning > Suggestion）に分類
4. •

   修正提案の生成

   • •各問題に対する具体的な修正コードを提示
   • •ユーザーの承認を得てから修正を適用

出力フォーマット

## 品質レビュー結果

### 📊 サマリー
- 対象ファイル数: X
- Critical: X件
- Warning: X件
- Suggestion: X件

### 🔴 Critical（必須修正）
#### ファイル名:行番号
**問題**: [問題の説明]
**修正案**:
```typescript
// 修正後のコード

🟡 Warning（推奨修正）

...

🟢 Suggestion（任意改善）

...

## 自動修正モード
ユーザーが「自動で直して」と指示した場合：
1. Critical項目のみを自動修正
2. 修正後、再度レビューを実行
3. 問題が解消されるまでループ（最大3回）

## Good/Bad例

### Bad: マジックナンバー
```typescript
if (user.age >= 18) { // 18が何を意味するか不明
  allowAccess();
}

Good: 定数化

const LEGAL_AGE = 18;
if (user.age >= LEGAL_AGE) {
  allowAccess();
}

Bad: 深いネスト

if (user) {
  if (user.profile) {
    if (user.profile.settings) {
      return user.profile.settings.theme;
    }
  }
}

Good: 早期リターン

if (!user?.profile?.settings) {
  return undefined;
}
return user.profile.settings.theme;