基于 SOC 职业分类
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt;运行前请先检查来源。
npx skills add https://github.com/s977043/river-review --skill river-review-performance命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地?可下载 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-performance |
| name | river-review-performance |
| description | パフォーマンス観点のレビューエージェント。 N+1クエリ、メモリ効率、キャッシュ戦略、可観測性の観点でコード変更を評価する。 |
| category | midstream |
| phase | ["midstream"] |
| severity | major |
| applyTo | ["src/**/*.{ts,tsx,js,jsx,mjs,cjs,html,css}","app/**/*.{ts,tsx,js,jsx,mjs,cjs,html,css}","components/**/*.{ts,tsx,js,jsx,html,css}","pages/**/*.{ts,tsx,js,jsx,html,css}","lib/**/*.{ts,tsx,js,jsx,mjs,cjs}","packages/**/*.{ts,tsx,js,jsx,mjs,cjs}","styles/**/*.css","public/**/*.html","**/*.sql"] |
| applyToExemptions | [{"skill":"cache-strategy-consistency","reason":"参照のみ。cache-strategy-consistency は docs 向け設計文書レビュー(phase upstream、applyTo が docs/**/*.md 等のみ)で、code/sql 実行観点の本エントリ(phase midstream)とはドメインが異なる。実行は river-review-architecture に据置く(本 SKILL.md「cache-strategy-consistency の帰属について」)。本エントリの applyTo には含めない。"},{"skill":"operability-slo","reason":"参照のみ。実行は river-review-architecture に据置く(ドメイン不一致。operability-slo は upstream/docs 系、本エントリは midstream/code 系。architecture 経由で完全到達済み)。cache-strategy-consistency exemption(#1522)の様式を踏襲。"}] |
| inputContext | ["diff","fullFile"] |
| outputKind | ["findings","actions"] |
| tags | ["performance","optimization","entry","routing"] |
| version | 0.1.0 |
| license | MIT |
パフォーマンスに影響する変更を検出し、適切な個別スキルで検証する。
| キーワード | スキルID | 説明 |
|---|---|---|
| キャッシュ, TTL | cache-strategy-consistency | 参照のみ。実行は river-review-architecture(理由) |
| 障害, 監視, メトリクス | failure-modes-observability | 障害モードと可観測性 |
| ログ, トレース | logging-observability | ロギング・可観測性 |
| SLO, レイテンシ | operability-slo | 運用性・SLO |
cache-strategy-consistency の帰属についてcache-strategy-consistency はキャッシュ戦略という語感から performance の懸念に見えるが、実体は設計ドキュメント(docs/spec/RFC 等)のキャッシュ戦略記述をレビューする upstream スキル(applyTo が docs/**/*.md 等の docs 系のみ、Pre-execution Gate も「差分に設計ドキュメントの変更がある」ことを要求)である。本エントリ(phase midstream、applyTo が code/sql)とはドメインが異なるため、ドメイン一貫性を優先し実行は river-review-architecture(phase upstream、docs 系 applyTo を保有)に据え置く。本表には到達性のための参照行として掲載するのみで、performance 側に重複するアクティブなキーワードルートは追加しない。
1. 変更内容の分析
├─ ループ内I/O → N+1クエリ検出を優先
├─ 大量データ処理 → メモリ効率チェックを優先
├─ 外部API呼び出し → タイムアウト・リトライ検証を優先
└─ キーワード指定あり → 該当スキルを直接選択
2. スキルの実行
├─ cache-strategy-consistency: キャッシュ戦略の一貫性
├─ failure-modes-observability: 障害モードと可観測性
├─ logging-observability: ロギング・可観測性
└─ operability-slo: 運用性・SLO
3. 統合
├─ 重複する指摘の除去
└─ Checklistに基づくパフォーマンスチェックの補完
パフォーマンスレビューでは以下を確認する:
<file>:<line>: <message>
| スキル | 関係 | 棲み分け |
|---|---|---|
river-review-architecture | 補完 | performance は「実行時効率」、architecture は「構造的スケーラビリティ」 |
river-review-code | 補完 | performance は「速度・効率」、code は「可読性・保守性」 |