用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt;运行前请先检查来源。
npx skills add https://github.com/s977043/river-review --skill river-review-code命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地?可下载 SkillsMP 当前能够提供的文件。
6つの専門レビュアーロールを並列実行し、consensusLevel(複数ロールの合意度)と Tech Lead レポート(top3指摘・blindSpots・consensusSummary)で結果を統合する マルチエージェントレビュー entry skill。 Parallel multi-role review with consensus scoring (consensusLevel) and Tech Lead report. Use when a major release needs exhaustive multi-angle review, or when a single-perspective review is not enough and you want confidence that no reviewer angle was missed(重要リリース前の網羅レビュー・多視点の確証が 欲しいとき)。
検査器(linter / ガード / CI ゲート / バリデータ / フィルタ)そのものの検出力が差分で静かに落ちていないか、また新設した検査が実際に検出できることが実証されているかを diff-time で検出する。Check 1 unverified detection reduction(検査器の検出ロジック(正規表現・除外パターン・解決集合・allowlist・baseline)を変更して検出件数が減ったのに、減った 1 件ずつが誤検出であった根拠が示されないまま「誤検出を潰した」「N → M 件に減少」と改善として主張している)、Check 2 unproven guard detection power(新しい検査ロジック・CI ゲート・バリデーションを追加・変更したのに、検出すべき入力を注入して検出されること/検出すべきでない入力で黙ることを示す変異注入の証跡が無く、「追加した」「CI が緑」を検出力の証拠として扱っている)、の 2 Check を対象とする report-only。テスト自身のアサーションが実質何も検証していない構造は test-assertion-effectiveness、レビュー基準・品質ゲートの明示的な弱体化(ルールの削除・閾値の引き下げ・suppression entry 追加・lint ルールの無効化)は review-criteria-integrity、リファクタ完了主張一般の検証は refactor-claim-audit、workflow の permissions と action pin は gha-workflow-security、設定ファイルの構文・型の妥当性は config-json へ委譲する
pbi-input, plan, todo, test-cases 間の整合性をチェックし、実装着手前の仕様漏れを検知する
基于 SOC 职业分类
正在显示 SKILL.md
| id | river-review-code |
| name | river-review-code |
| description | 一般コード品質のレビューエージェント。デフォルトのフォールバック先。 可読性、保守性、型安全性、ロギング等の個別スキルへルーティングする。 |
| category | midstream |
| phase | ["midstream"] |
| severity | minor |
| applyTo | ["src/**/*.{ts,tsx,js,jsx,mjs,cjs}","app/**/*.{ts,tsx,js,jsx,mjs,cjs}","lib/**/*.{ts,tsx,js,jsx,mjs,cjs}","packages/**/*.{ts,tsx,js,jsx,mjs,cjs}","scripts/**/*.{ts,tsx,js,jsx,mjs,cjs}","runners/**/*.{ts,tsx,js,jsx,mjs,cjs}"] |
| inputContext | ["diff","fullFile"] |
| outputKind | ["findings","actions"] |
| tags | ["code-quality","default","entry","routing"] |
| version | 0.1.0 |
| license | MIT |
コードの可読性、保守性、型安全性を検証する。他の専門エージェントに該当しない場合のデフォルトフォールバック先。
| キーワード | スキルID | 説明 |
|---|---|---|
| 型, TypeScript, strict | typescript-strict | TypeScript strict モード準拠 |
| null, undefined, optional | typescript-nullcheck | null 安全性チェック |
| 非同期, await, Promise | async-correctness | 非同期処理の正しさ検証 |
| 型駆動, 設計 | type-driven-design | 型駆動設計 |
| ログ, 監視 | logging-observability | ロギング・可観測性 |
| 自動化, 境界 | review-automation-boundary | レビュー自動化の境界 |
| コメント, トリアージ | review-comment-triage | レビューコメント分類 |
| 幻覚的参照, 実在確認 | hallucinated-reference | 新規参照の実在確認 |
| 簡素化, 整理, simplify | SIMPLIFY 観点(本 skill 内) | 品質クリーンアップ4観点 |
| 破壊的操作, undo, 回復支援 | UX-SAFEGUARD 観点(本 skill 内) | 操作の安全装置2観点 |
UI/コンポーネント系のルーティング(a11y, デザインシステム, Next.js App Router 境界等)は
river-review-frontendに一元化済み(#1462)。本ルーターからは移設し、二重発火を避けている。
.ts/.tsxファイル → TypeScript strict + nullチェックriver-review-frontend も参照(a11y・デザインシステム観点は frontend 側が担当)一般コードレビューでは以下を確認する:
data / info / manager / handler / util / current)、共有されていない略語、同一概念の別名(または別概念の同名)がないかa.b.c.type === 'x')、値オブジェクトから primitive を取り出して外部で分岐、getter による内部状態の露出。Tell-Don't-Ask(例: user.subscription.plan.type === 'premium' より user.isPremium())を推奨する(Law of Demeter)anyの使用が最小限かscripts/(tsconfig の include に含まれず tsc 検査対象外)の JSDoc で unknown を any へ緩める提案はしない。unknown は呼び出し側に絞り込みを強制する意図的で保守的な選択。詳細と canary は existing-pattern-conformance の「False-positive guards」を参照。?? {} 等の防衛は提案しない。外部 IO・環境境界(argv / fs / network)の例外・null には防衛必須。詳細と canary は nullability-contract の「False-positive guards」を参照。1. ファイル種別の判定
├─ .ts/.tsxファイル → TypeScript strict + nullチェックを選択
├─ コンポーネントファイル → river-review-frontend も参照(a11y・デザインシステム観点)
├─ 設定ファイル → 型駆動設計チェックを選択
└─ キーワード指定あり → 該当スキルを直接選択
(SIMPLIFY / UX-SAFEGUARD 観点のキーワード該当時は本 skill 内で実行。キーワードは ROUTING.md を参照)
2. スキルの実行
├─ typescript-strict: strictモード準拠
├─ typescript-nullcheck: null安全性
├─ async-correctness: 非同期処理の正しさ
├─ type-driven-design: 型駆動設計
├─ logging-observability: ロギング・可観測性
├─ review-automation-boundary: レビュー自動化の境界
└─ hallucinated-reference: 新規参照の実在確認
3. 統合
├─ 重複する指摘の除去
└─ Checklistに基づく一般品質チェックの補完
複数観点を横断するレビューでは、以下の順で差分を走査し findings を統合する。
| 順序 | 観点 | 実行ルール |
|---|---|---|
| 1 | セキュリティ | Critical finding 検出時: 以降の観点も実行するが、Critical を先頭に出力 |
| 2 | パフォーマンス | ホットパス外の変更のみの場合はスキップ可 |
| 3 | 品質・設計 | 常に実行 |
| 4 | テスト網羅性 | テストファイルが差分に含まれない場合も、対象コードのテスト有無を確認 |
観点間の重要度比較: 異なる観点の findings が同一箇所を指す場合、severity が異なれば高い方を採用(もう一方は補足として併記)、同じなら security > performance > quality > testing の順で先に記載する。
出力件数の制約: 1 PR あたり最大 15 件(超過分は severity 降順で切り捨て、切り捨て件数を末尾に記載)。同一ファイルへの同一観点の指摘は最大 3 件にグルーピングする。
判定の手がかり:
catch ブロック内の空文、// TODO → security / qualityO(n*m) パターン、ループ内の DB / API コール → performanceany 型、型アサーション(as)、未使用 import → qualitydescribe / test がない → testing<file>:<line>: <message>
| スキル | 関係 | 棲み分け |
|---|---|---|
river-review-architecture | 補完 | code は「ミクロ品質」、architecture は「マクロ設計」 |
river-review-testing | 補完 | code は「プロダクションコード」、testing は「テストコード」 |
river-review-performance | 補完 | code は「可読性」、performance は「実行効率」 |
river-review-frontend | 補完 | code は「一般コード品質」、frontend は「UI 固有の懸念」。UI 系ルートは frontend へ移設済み(#1462) |