Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/s977043/river-review/api-compatibilitynpx skills add s977043/river-review --skill api-compatibilitygit clone --depth 1 https://github.com/s977043/river-reviewWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/s977043/river-review/api-compatibility)<a href="https://agentmods.dev/skills/s977043/river-review/api-compatibility"><img src="https://agentmods.dev/badge/skills/s977043/river-review/api-compatibility.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00027 | $0.01421 |
| Opus 5 | $0.00014 | $0.00711 |
| Sonnet 5 | $0.00005 | $0.00284 |
| Haiku 4.5 | $0.00003 | $0.00142 |
Grade A, and why
API Compatibility and Test Gap Review scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 89 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Pattern declaration
Primary pattern: Reviewer Secondary patterns: Inversion Why: API契約変更は下流の呼び出し元を静かに壊す。差分内のDTO・インターフェース・エンドポイント定義の変更が既存呼び出し元との互換性を壊していないか、かつテストが更新されているかを検証する。
Rule / ルール
- APIエンドポイントのリクエスト/レスポンス型（DTO）を変更する場合、既存の呼び出し元との後方互換性を保持するか、バージョニング戦略を適用する。
- DTOへのフィールド削除・型変更・必須化は破壊的変更とみなし、影響範囲のコード修正またはマイグレーションパスを確認する。
- API変更にはテスト（ユニットテスト・インテグレーションテスト・APIテスト）の更新が必須。
- オプショナルフィールド追加は後方互換だが、受信側でのnullabilityハンドリングを確認する。
Heuristics / 判定の手がかり
interface/typeの定義でフィールドが削除または型が変更されているが、呼び出し元（サービス・コントローラ等）の修正がない。- RESTエンドポイントのリクエストボディやクエリパラメータの型が変更されているが、対応するAPIテストが差分に含まれていない。
- レスポンス型（DTO）にフィールドが追加されているが、呼び出し元でのデシリアライズ処理が更新されていない。
- API型定義（OpenAPI schema、Zod schema等）が変更されているが、それを参照するテストが更新されていない。
optional→required（?の削除）の変更があるが、既存の呼び出し元がフィールドを省略している。
Good / Bad Examples
- Good: DTOに新フィールドを追加し、受信側コードでのハンドリングとテストを同時に追加している。
- Bad: レスポンスDTOから
userIdフィールドを削除したが、そのフィールドを参照している呼び出し元を修正していない。 - Good: 型変更（
string→number）と同時に呼び出し元の変換処理とテストを更新。 - Bad:
required: trueにしたが既存テストデータがそのフィールドを含んでいない。 - Good: バージョニング（
/v2/endpoint）で旧バージョンと共存させ段階的移行。
Actions / 改善案
- DTOの変更箇所に対して、影響を受けるすべての呼び出し元・デシリアライズ処理を
code_searchで特定し更新する。 - API変更に対応するテスト（happy path + error case）を追加・更新する。
- 後方互換を保てない変更の場合、APIバージョニングやフィーチャーフラグによる段階移行を検討する。
- 変更前後のスナップショットテストまたはContract Testを追加する。
Non-goals / 扱わないこと
- APIの設計思想・RESTful原則への準拠評価（別スキルのスコープ）。
- パフォーマンスや認証・認可の問題（別スキルのスコープ）。
- 外部サードパーティAPIへの変更（コードベース外のコントロール外）。
Pre-execution Gate / 実行前ゲート
このスキルは以下の条件がすべて満たされない限りNO_REVIEWを返す。
- 差分にTS/JS/TSXファイルが含まれている
- 差分にAPIエンドポイント定義、DTO/インターフェース/型定義の変更が含まれている
- inputContextにdiffが含まれている
ゲート不成立時の出力: NO_REVIEW: api-compatibility — API契約・DTO変更の差分がない
False-positive guards / 抑制条件
- 新規追加エンドポイント・DTOには互換性リスクがないため指摘しない。
- テストファイル内のみの型変更（テスト用モック型）は対象外。
- 変更がオプショナルフィールドの追加のみで、かつ受信側でnullabilityがハンドルされている場合。
評価指標（Evaluation）
- 合格基準: 指摘が差分の具体的なDTO/型変更に紐づき、互換性リスクまたはテスト不足が説明されている。
- 不合格基準: 新規追加への誤指摘、テストファイル内変更への誤指摘、差分外コードへの指摘。
人間に返す条件（Human Handoff）
What ships with it
4 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 89 lines · 27 tokens per session scan A aaa238053863
API Compatibility and Test Gap Review is a skill published in the GitHub repository s977043/river-review (3 stars, last pushed today), licensed MIT. It adds 27 tokens to every session and 1,421 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
Contract-First Testing
Contract-first testing approach using Pact, Spring Cloud Contract, or Dredd for ensuring API consumer-provider compatibility.
api-integrations
Expose external APIs to Falcon Foundry via OpenAPI specs. TRIGGER when user asks to "create an API integration", "adapt an OpenAPI spec for Foundry", "expose an API to workflows", "connect to a third-party API", or runs foundry api-integrations create. Also trigger when user has an OpenAPI/Swagger spec and wants it…
run-iteration-eval
Run the Logic-Lens content-eval pipeline for one iteration and produce a scored summary.json — use to measure a skill change. Wraps scripts/run-content-evals.sh (runner, costs tokens) and scripts/grade-iteration.py (grader, free, re-runnable). ALWAYS sync the plugin cache first. Use when the user wants to "run the…
fastapi
FastAPI best practices + Pydantic. Use when building or reviewing FastAPI APIs.
review
AI code review of your changes (open-code-review methodology, run natively in Claude Code). Reviews the working diff or staged changes, or scans whole files, and prints findings plus a block/warn/pass verdict. Use for "review my changes", "review staged", "scan this repo", or as the engine behind the commit gate.
omnicheck-gitlab
Use when checking if MR review findings have been applied — verifies both OmniForge-generated and human reviewer comments against the current diff, posts nudge replies on unaddressed threads.