API Compatibility and Test Gap Review
Skill7 starsChanged 5 months agoMITView on GitHub
Detect breaking API contract changes, DTO modifications without compatibility handling, and missing tests for changed API boundaries.
In this repository140 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .codex/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- static/llms.txtllms.txt
- ask-codexSkill
- river-review-disciplineSkill
- skill-creatorSkill
- skill-ops-plannerSkill
- skill-optimizerSkill
- commandsSkill
- adversarial-reviewSkill
- review-teamSkill
- river-review-architectureSkill
- river-review-codeSkill
- river-review-docsSkill
- river-review-frontendSkill
- river-review-performanceSkill
- river-review-security-auditSkill
- river-review-securitySkill
- river-reviewSkill
- river-review-testingSkill
- unknown-coverage-reviewSkill
- Coverage and Failure Path GapsSkill
- Flaky Test Risk CheckSkill
- GitHub Actions Workflow Security ReviewSkill
- Standard Review Policy for DownstreamSkill
- Test Assertion Effectiveness 常に PASS するテストの検出Skill
- Test Presence for Changed CodeSkill
- Test Naming and StructureSkill
- テスト観点レビュー(差分ドリブン)Skill
- a11y Accessible Name BasicsSkill
- Agent Skill Bridge ReviewSkill
- Altitude Generalization GuardSkill
- Assumption Resolution Trace Plan の前提解消トレーサビリティSkill
- Async Correctness 非同期処理の正しさ検証Skill
- Behavior-Structure Separation 振る舞い変更と構造変更の分離・外部挙動維持Skill
- Closure Scope Retention GuardSkill
- Component Variants / States Documentation コンポーネント状態の文書化Skill
- Configuration File ReviewSkill
- Cross-File Leakage リファクタ後の caller 側残骸検出Skill
- Design Source-of-Truth Conformance デザイン定義準拠Skill
- Design System Component Reuse GuardSkill
- Design Token EnforcementSkill
- Detector Detection Power 検査器の検出力の検証Skill
- Documentation Hygiene ドキュメント衛生Skill
- End-to-End Wiring 末端到達・貫通の検証Skill
- Existing-Pattern Conformance 既存パターン準拠の確認Skill
- Firebase Security Rules ReviewSkill
- Fix Scope Integrity 指摘対応ループのスコープ逸脱・前提破壊検出Skill
- GitHubレビューコメント対応(修正案つき)Skill
- Hallucinated Reference 幻覚的参照の実在確認Skill
- Hello Skill (Always-On Sample)Skill
- i18n Unused Key ReviewSkill
- Impact Evidence Coverage 影響・失敗系・外部依存の証拠充足Skill
- Independent Review SynthesisSkill
- Invisible Unicode Injection Scan 不可視 Unicode コード注入検出Skill
- Knowledge-to-Code Alignment 新知識のコード反映・設計知識の保全Skill
- Laravel Eloquent N+1 and Query Efficiency ReviewSkill
- Laravel Mass Assignment and Authorization ReviewSkill
- The first 60 shown.
The file
Files
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)
- 破壊的変更が意図的なメジャーバージョンアップの一環か否かの判断が必要な場合は人間レビューへ返す。
- 影響範囲が差分から特定できないほど広い場合は人間レビューへ返す。
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
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.

