# River Review Code

> 一般コード品質のレビューエージェント。デフォルトのフォールバック先。 可読性、保守性、型安全性、ロギング等の個別スキルへルーティングする。

- Skill: `concertonotes/river-review-code` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add concertonotes/river-review-code`
- Raw SKILL.md: https://api.skillmd.com/api/skills/concertonotes/river-review-code/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- License: MIT
- Author: ConcertoNotes (https://skillmd.com/u/concertonotes)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/concertonotes/river-review-code

---


# Code Quality Review（一般コード品質レビュー）

コードの可読性、保守性、型安全性を検証する。他の専門エージェントに該当しない場合のデフォルトフォールバック先。

## When to Use / いつ使うか

- 一般的なコード変更のレビュー時
- 他の専門エージェント（architecture, security, performance, testing）に該当しない場合
- コード品質の総合的なチェックが必要な場合

## Routing / ルーティング

| キーワード                | スキルID                                      | 説明                         |
| ------------------------- | --------------------------------------------- | ---------------------------- |
| 型, TypeScript, strict    | `rr-midstream-typescript-strict-001`          | TypeScript strict モード準拠 |
| null, undefined, optional | `rr-midstream-typescript-nullcheck-001`       | null 安全性チェック          |
| 型駆動, 設計              | `rr-midstream-type-driven-design-001`         | 型駆動設計                   |
| ログ, 監視                | `rr-midstream-logging-observability-001`      | ロギング・可観測性           |
| 自動化, 境界              | `rr-midstream-review-automation-boundary-001` | レビュー自動化の境界         |
| コメント, トリアージ      | `rr-midstream-review-comment-triage-001`      | レビューコメント分類         |
| a11y, アクセシビリティ    | `rr-midstream-a11y-accessible-name-001`       | アクセシビリティ基本         |
| Next.js, App Router       | `rr-midstream-nextjs-app-router-boundary-001` | Next.js 境界チェック         |

### デフォルト動作

- キーワード指定なし → 以下のヒューリスティクスで判定:
  - `.ts`/`.tsx`ファイル → TypeScript strict + nullチェック
  - コンポーネントファイル → a11yチェック追加
  - 設定ファイル → 型駆動設計チェック

## Checklist / チェックリスト

一般コードレビューでは以下を確認する:

### 可読性

- 関数・変数の命名が意図を表現しているか
- 意図を伝えない広すぎる名前（`data` / `info` / `manager` / `handler` / `util` / `current`）、共有されていない略語、同一概念の別名（または別概念の同名）がないか
- 関数の責務が単一か
- ネストが深すぎないか（3段以内。深い場合は guard clause で平坦化を提案）
- マジックナンバー・マジックストリングがないか

### 保守性

- DRY原則にしたがっているか（ただし過度な抽象化を避ける）
- 変更の影響範囲が限定的か
- 依存方向が正しいか
- カプセル化リークがないか: オブジェクト内部へ深く手を伸ばすコード（`a.b.c.type === 'x'`）、値オブジェクトから primitive を取り出して外部で分岐、getter による内部状態の露出。Tell-Don't-Ask（例: `user.subscription.plan.type === 'premium'` より `user.isPremium()`）を推奨する（Law of Demeter）

### 型安全性

- `any`の使用が最小限か
- 型ガードが適切か
- null/undefinedの扱いが安全か

### エラーハンドリング

- エラーを握り潰していないか
- エラーメッセージが十分な情報を含むか
- リカバリー可能なエラーと不可能なエラーの区別

## Execution Flow / 実行フロー

```text
1. ファイル種別の判定
   ├─ .ts/.tsxファイル → TypeScript strict + nullチェックを選択
   ├─ コンポーネントファイル → a11yチェックを追加
   ├─ 設定ファイル → 型駆動設計チェックを選択
   └─ キーワード指定あり → 該当スキルを直接選択

2. スキルの実行
   ├─ typescript-strict: strictモード準拠
   ├─ typescript-nullcheck: null安全性
   ├─ type-driven-design: 型駆動設計
   ├─ logging-observability: ロギング・可観測性
   ├─ review-automation-boundary: レビュー自動化の境界
   ├─ a11y-accessible-name: アクセシビリティ
   └─ nextjs-app-router-boundary: Next.js境界

3. 統合
   ├─ 重複する指摘の除去
   └─ Checklistに基づく一般品質チェックの補完
```

## Multi-perspective Execution / 多観点実行（旧 agent-code-review から統合）

複数観点を横断するレビューでは、以下の順で差分を走査し findings を統合する。

| 順序 | 観点           | 実行ルール                                                             |
| ---- | -------------- | ---------------------------------------------------------------------- |
| 1    | セキュリティ   | Critical finding 検出時: 以降の観点も実行するが、Critical を先頭に出力 |
| 2    | パフォーマンス | ホットパス外の変更のみの場合はスキップ可                               |
| 3    | 品質・設計     | 常に実行                                                               |
| 4    | テスト網羅性   | テストファイルが差分に含まれない場合も、対象コードのテスト有無を確認   |

観点間の重要度比較: 異なる観点の findings が同一箇所を指す場合、severity が異なれば高い方を採用（もう一方は補足として併記）、同じなら security > performance > quality > testing の順で先に記載する。

出力件数の制約: 1 PR あたり最大 15 件（超過分は severity 降順で切り捨て、切り捨て件数を末尾に記載）。同一ファイルへの同一観点の指摘は最大 3 件にグルーピングする。

判定の手がかり:

- `catch` ブロック内の空文、`// TODO` → security / quality
- `O(n*m)` パターン、ループ内の DB / API コール → performance
- `any` 型、型アサーション（`as`）、未使用 import → quality
- 新規 export 関数にテストファイル内の対応する `describe` / `test` がない → testing

## Output Format / 出力形式

```text
<file>:<line>: <message>
```

- **Finding**: 何が問題か（1文）
- **Impact**: 何が困るか（短く）
- **Fix**: 次の一手（最小の修正案）

## 他スキルとの関係

| スキル                      | 関係 | 棲み分け                                                    |
| --------------------------- | ---- | ----------------------------------------------------------- |
| `river-review-architecture` | 補完 | code は「ミクロ品質」、architecture は「マクロ設計」        |
| `river-review-testing`      | 補完 | code は「プロダクションコード」、testing は「テストコード」 |
| `river-review-performance`  | 補完 | code は「可読性」、performance は「実行効率」               |

## References

- [ROUTING.md](./references/ROUTING.md): 詳細なルーティングルール