소스 정보
- 저장소
- s977043/river-review
- 최근 소스 활동
- 2026년 7월 19일 02:49
- 감지된 SKILL.md 언어
- 일본어
- 스타
- 2
- 포크
- 0
설치 방법
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
소스 파일 검토
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
메뉴
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
SOC 직업 분류 기준
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/s977043/river-review --skill river-review-code명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
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 間の整合性をチェックし、実装着手前の仕様漏れを検知する
| 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) |