---
name: qa-check
description: >
  このスキルは、コードレビュー、セルフレビュー、QA チェックをします。
  ユーザーが「このコードを確認してください」、「PR を確認してください」、「QA を行ってください」、「ここに問題がありますか?」と言うたびに呼び出します。
  またはペーストフィードバックを求めるコードに対しても呼び出します。。
  Ruby/Rails、JavaScript/TypeScript/React、および一般的なコードの品質、パフォーマンスの問題、セキュリティの脆弱性、コードの品質をチェックします。
  チェック結果をCRITICAL/WARNING/INFOに分類してをレポートを出力します。
  明示的に求められるのを待つ必要はありません。レビューのためにコードが共有されている場合は、このスキルを開始してください。
context: fork
agent: Explore
---

# QA チェック

## 使い方

以下のいずれかの入力に適用する：
- リポジトリ内のファイルパス（1つまたは複数）
- `git diff` またはパッチ
- プルリクエスト（`gh pr diff <番号>` で取得）
- 会話に直接貼り付けられたコード

複数ファイルや大きな diff の場合は、レビューを開始する前にすべて読み込む。

---

## レビューワークフロー

### ステップ 1 — コンテキストの把握

チェックを開始する前に以下を確認する：
1. **言語 / フレームワーク**: ファイル拡張子・import・設定ファイルから判定する。
   - `.rb`、`Gemfile`、`config/routes.rb` → Ruby/Rails
   - `.ts`、`.tsx`、`.js`、`.jsx`、`package.json` → JavaScript/TypeScript/React
   - 混在している場合 → 複数の参照セットを適用する
2. **変更の目的**: コミットメッセージや PR の説明を読む。不明な場合はユーザーに確認する。
3. **スコープ**: テスト未記載・関連ファイル不足など、含まれていないものを把握する。

### ステップ 2 — 該当する参照ファイルを読み込む

検出した言語/フレームワークに応じて、対応する参照ファイルを読み込む：

| 検出したスタック | 読み込む参照ファイル |
|---|---|
| Ruby / Rails | `~/.claude/skills/qa-check/references/backend.md` |
| JavaScript / TypeScript / React | `~/.claude/skills/qa-check/references/frontend.md` |
| 汎用 | `~/.claude/skills/qa-check/references/general-principles.md`（常に読み込む） |

`general-principles.md` はスタックに関係なく必ず読み込む。

### ステップ 3 - 該当するリファレンスを読み込みチェック項目に従ってレビュー実施

各観点について、コードを体系的にスキャンする。コードが問題なく見えても観点を省略しない — 問題がないこと自体が有用なフィードバックになる。

### ステップ 4 - 結果をCRITICAL/WARNING/INFO に分類してレポートする

以下の **出力フォーマット** に従う。すべての指摘には以下を含める：
- 具体的で明確な説明（「これは改善できる」のような曖昧な表現は不可）
- 問題が発生している正確なファイルと行番号（または範囲）
- 未修正の場合の影響やリスク
- 具体的な修正提案またはコードスニペット

#### チェック観点

| 観点 | フォーカス | デフォルト優先度 |
|---|---|---|
| パフォーマンス | クエリ、レンダリング、CPU/メモリ | WARNING |
| セキュリティ | インジェクション、認証認可、シークレット | CRITICAL |
| コード品質 | 設計、テスト、可読性 | INFO |
| バグ / ロジック | 正確性、エッジケース、エラーハンドリング | CRITICAL |


#### 出力フォーマット

```markdown
## QA レビュー: [レビュー対象の簡単な説明]

### サマリー
[最も重要な発見とコード全体の評価を1〜3文で記述する。
例:「コントローラーの42行目に SQL インジェクションのリスクがあり、認可チェックも不足しています。
ロジック自体は概ねクリーンですが、新しい分岐に対するテストカバレッジが欠けています。」]

### 指摘事項

#### CRITICAL — 必ず修正
> マージ前に解消必須。バグ、セキュリティ脆弱性、データ消失リスクなど。

| # | 問題 | 場所 | 影響 |
|---|-----|------|------|
| 1 | [問題の短いタイトル] | file.rb:42 | [リスクの説明] |

**#1 の詳細と修正案:**
[なぜ問題なのかの説明と、具体的な修正方法またはコード例。]

---

#### WARNING — 修正すべき
> 重大なバグ、パフォーマンス問題、または重要なテストの欠如。対応せずにリリースしないことを推奨。

| # | 問題 | 場所 | 影響 |
|---|-----|------|------|
| 1 | [問題の短いタイトル] | file.ts:17 | [リスクの説明] |

**#1 の詳細と修正案:**
...

---

#### INFO — 検討
> 保守性、非クリティカルなパフォーマンス、テストのギャップ、軽微なスタイルの不一致、小さなリファクタリング機会、任意の改善。任意の改善。

| # | 問題 | 場所 | 影響 |
|---|-----|------|------|

---

### 未チェック箇所
- [スコープ外・アクセス不可・意図的にスキップしたファイルや領域]
- [レビューを制限した時間的・コンテキスト的な制約]
```

各優先度レベルで指摘がない場合は、空欄にせず `_指摘なし。_` と記載する。

## アンチパターン

以下のことは絶対に行わない：

1. **証拠のない曖昧な批判**: 特定の行番号と理由なしに「これは良くない」「もっとクリーンにできる」とは言わない。
2. **スタイルのみの指摘を CRITICAL にする**: フォーマットや命名の問題は、実際のバグを引き起こさない限り最大 WARNING にする。
3. **問題の捏造**: 問題かどうか確信がない場合は明示的にそう伝える（「潜在的な問題 — X で確認してください」）。
4. **コンテキスト不足の無視**: 全体像が見えない場合（モデル定義が欠けている、差分が部分的など）、「未チェック箇所」に明記する。
5. **ポジティブな評価の省略**: CRITICAL の問題がない場合は明確にそう伝える。問題なしという評価は価値あるフィードバックである。
6. **関心事の混在**: 各指摘は原子的に保つ — 指摘テーブルの1行に1つの問題のみ記載する。