用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt;运行前请先检查来源。
npx skills add https://github.com/s977043/river-review --skill end-to-end-wiring命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地?可下载 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 | e2e-wiring |
| name | End-to-End Wiring 末端到達・貫通の検証 |
| description | 宣言した処理(計測 / 通知 / 保存 / 検証 / 例外通知)が起点から末端まで途切れず配線されているかを確認し、「実装したつもり」で経路が途中で止まっている欠落を検出する |
| version | 0.1.0 |
| category | midstream |
| phase | midstream |
| applyTo | ["**/*.{ts,tsx,js,jsx,mjs,cjs,py,rb,go,php,java}"] |
| tags | ["wiring","end-to-end","correctness","integration","midstream"] |
| severity | major |
| inputContext | ["diff"] |
| outputKind | ["findings","questions"] |
| modelHint | high-accuracy |
| dependencies | ["code_search"] |
Primary pattern: Reviewer Secondary patterns: Inversion Why: 宣言された処理の配線追跡はチェックリスト型だが、貫通すべき処理を含まない変更では実行を止めるゲートが必要。
validate() が保存経路に未配線、例外を捕捉して silent skip)を可視化する。logic-torturing の領域)。cross-file-leakage の領域)。このスキルは以下の条件がすべて満たされない限り NO_REVIEW を返す。
code_search(grep)が利用可能であるゲート不成立時の出力: NO_REVIEW: e2e-wiring — 貫通処理の変更が検出されない
code_search(grep)で呼び出し先・末端の配線を確認した上でのみ指摘する。grep で確認せず「差分内に末端が見えない」ことだけを根拠に「途切れている」と推測断定してはならない(推測断定は最も多い誤検出源)。grep で配線済みと確認できたら指摘しない。findings で断定せず questions で確認する。validate() 等を定義したが保存・実行経路に呼び出していないcatch して通知・再送・再 throw のいずれもせず握り潰している(silent skip)await / 完了確認せず**発火しっぱなし<file>:<line> で示す。questions で確認する。<file>:<line> に紐づけ、推測で経路を述べない。すべて日本語。
(e2e-wiring):1: [要約] 末端に到達しない最も重大な処理は〈1文〉
<file>:<line>: [配線断点1] <タイトル>
宣言: <何をするはずか>(<起点 file>:<line>)
途切れ: <どこで止まるか>(<断点 file>:<line>)
影響: <データ欠落 / 通知不達 / 集計欠損 / 例外の不可視化>
Fix: <末端まで配線する最小修正(永続化呼び出し / 経路への結線 / 再throw・通知)>
<file>:<line> で示され、末端未到達の実害が具体的に説明されている。