agentleFS
s977043s977043/river-review/skills/midstream/e2e-wiring/SKILL.md

End-to-End Wiring 末端到達・貫通の検証

Skill7 starsChanged 5 months agoMITView on GitHub

宣言した処理(計測 / 通知 / 保存 / 検証 / 例外通知)が起点から末端まで途切れず配線されているかを確認し、「実装したつもり」で経路が途中で止まっている欠落を検出する

The file

Files
SKILL.md

Pattern declaration

Primary pattern: Reviewer Secondary patterns: Inversion Why: 宣言された処理の配線追跡はチェックリスト型だが、貫通すべき処理を含まない変更では実行を止めるゲートが必要。

Goal / 目的

  • ある処理が「宣言(意図)」されているのに、起点から末端まで配線が途切れている欠落を検出する。
  • 「実装したつもり」で経路が途中で止まっているパターン(計測がセッション書き込み止まりで永続化されない、validate() が保存経路に未配線、例外を捕捉して silent skip)を可視化する。

Non-goals / 扱わないこと

  • 個別関数の論理的正しさ(logic-torturing の領域)。
  • caller 側の旧構造残骸(リファクタ後ドリフトは cross-file-leakage の領域)。
  • テストの有無そのもの(テスト不足は test 系スキルの領域。本スキルは「本番経路の配線」を見る)。

Pre-execution Gate / 実行前ゲート

このスキルは以下の条件がすべて満たされない限り NO_REVIEW を返す。

  • 差分が、新規に起点→末端の貫通経路を導入または変更している(計測 / 通知 / 非同期 / 永続化 / 検証配線 / 例外通知 など複数層をまたぐ処理の新設・結線変更)。既存経路に無関係な単純変更(変数名変更・コメント・ログ文言・定数値の差し替えなど、貫通経路の新設・切断を伴わない変更)は対象外とする
  • inputContext に diff が含まれ、code_search(grep)が利用可能である

ゲート不成立時の出力: NO_REVIEW: e2e-wiring — 貫通処理の変更が検出されない

False-positive guards / 抑制条件

  • 経路の末端側が差分外の場合は、まず code_search(grep)で呼び出し先・末端の配線を確認した上でのみ指摘する。grep で確認せず「差分内に末端が見えない」ことだけを根拠に「途切れている」と推測断定してはならない(推測断定は最も多い誤検出源)。grep で配線済みと確認できたら指摘しない。
  • 末端の到達可否が grep でも確定できない場合は、findings で断定せず questions で確認する。
  • 意図的に途中で止める設計(feature flag で後続を保留中など)が差分内に明記されている場合は抑制。
  • ベストエフォートで欠落が許容される処理(デバッグログ等)は対象外。

Rule / ルール

検出ロジック

  1. 宣言の特定: 差分から「何をする宣言か」を抽出する(計測する / 通知する / 保存する / 検証する / 例外を通知する など)。
  2. 経路の追跡: その宣言の起点(呼び出し箇所)から末端(送信完了 / 受信者 / DB 確定 / 監視到達 / 戻り値の利用)まで、各ホップが実際に配線されているかを追う。
  3. 途切れの判定: 次の典型断点を確認する。
    • 計測・状態をセッション / メモリに書いたが永続化・送信していない
    • validate() 等を定義したが保存・実行経路に呼び出していない
    • 例外を catch して通知・再送・再 throw のいずれもせず握り潰している(silent skip)
    • 非同期処理を**await / 完了確認せず**発火しっぱなし
  4. 報告: 起点と途切れた箇所を両方 <file>:<line> で示す。

制約

  • 検出は最大 5 件。本番影響(データ欠落 / 通知不達 / 集計欠損)が大きいものを優先。
  • 各指摘に「宣言」「起点」「途切れた箇所」「末端に到達しない影響」を必ず含める。
  • 経路が差分から追えない場合は断定せず questions で確認する。

Evidence / 根拠の取り方

  • 宣言・起点・断点は必ず <file>:<line> に紐づけ、推測で経路を述べない。
  • 「どこまで到達し、どこで止まるか」を入力→処理→末端の流れで具体的に示す。

Output / 出力フォーマット

すべて日本語。

(e2e-wiring):1: [要約] 末端に到達しない最も重大な処理は〈1文〉

<file>:<line>: [配線断点1] <タイトル>
  宣言: <何をするはずか>(<起点 file>:<line>)
  途切れ: <どこで止まるか>(<断点 file>:<line>)
  影響: <データ欠落 / 通知不達 / 集計欠損 / 例外の不可視化>
  Fix: <末端まで配線する最小修正(永続化呼び出し / 経路への結線 / 再throw・通知)>

評価指標(Evaluation)

  • 合格基準: 宣言・起点・断点が <file>:<line> で示され、末端未到達の実害が具体的に説明されている。
  • 不合格基準: 経路の推測、差分にない配線の断定、テスト不足やロジック正しさへの越境。

人間に返す条件(Human Handoff)

  • 末端(外部システム・他サービス)への到達可否が環境依存で、コードからは判断できない場合。
  • 途中で止める設計が意図的かどうかの判断が必要な場合。

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.