Persona Review

---
name: persona-review
description: >
  簡潔な PR レビューコメントを生成する。1行1指摘、位置・問題・修正、重大度タグ付き。
  「PRレビューして」「コードレビュー」「/persona-review」で起動。
---

Derived from genshijin (MIT, InterfaceX-co-jp) — https://github.com/InterfaceX-co-jp/genshijin

レビューコメントは簡潔かつ行動可能に。1行1指摘。位置・問題・修正。前置き禁止。

**このスキルはキャラクター非依存。** レビューコメントは PR に残る文章なので、
どのキャラクターが有効でも口調を適用しない。

## 形式

`L<line>: <問題>。<修正>。` — 複数ファイルにまたがる場合は `<file>:L<line>: ...`

## 重大度プレフィックス

- 🔴 `バグ:` — 壊れている。インシデントに直結する
- 🟡 `リスク:` — 動くが脆い（race、null 未チェック、握り潰した error）
- 🔵 `nit:` — スタイル・命名・ミクロ最適化。著者は無視してよい
- ❓ `質問:` — 純粋な疑問。提案ではない

## 削除する

- 「〜に気づきました」「〜のように見えます」「〜を検討するとよいかもしれません」
- 「あくまで提案ですが」→ `nit:` を使う
- 「素晴らしい仕事です」「全体的には良さそうですが」— 先頭に一度だけ。個別コメントには不要
- その行が何をしているかの説明 — diff を読めば分かる
- ぼかし（「おそらく」「たぶん」「〜と思います」）— 不確実なら `質問:` にする

## 保持する

- 正確な行番号
- シンボル・関数名・変数名はバッククォートで囲む
- 具体的な修正案（「リファクタリングを検討」は不可）
- 問題文から自明でない「なぜ」

## 例

不可:

> L42 で user オブジェクトが null かどうかをチェックせずに email プロパティに
> アクセスしているように見えます。DB で user が見つからなかった場合にクラッシュする
> 可能性があります。null チェックを追加することを検討してみてください。

可:

```text
L42: 🔴 バグ: .find() 後 user が null になりうる。.email の前にガードを追加。
L88-140: 🔵 nit: 50行の関数に4責務。validate / normalize / persist を抽出。
L23: 🟡 リスク: 429 のリトライなし。withBackoff(3) で包む。
```

## 簡潔モードを解除するケース

以下は通常の段落で記述する。該当の指摘が終わったらすぐ形式に戻る。

- セキュリティ指摘（CVE 級は参照 URL 付きで十分な説明が必要）
- アーキテクチャへの異論（根拠が必要。ワンライナーでは不足）
- 新人のオンボーディング文脈（「なぜ」が必要）

## 境界

- レビューのみ。コード修正、approve / request-changes、linter の実行はしない
- 出力はそのまま PR に貼り付けられる形式にする