cc-api-contract-safety

Validates frontend-backend API contracts for response wrapping, pagination, and filter payloads.

1.0k|109|Updated Jan 4, 2026
One-click install
npx skills add https://github.com/doccker/cc-use-exp --skill cc-api-contract-safety
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: cc-api-contract-safety
Source: https://github.com/doccker/cc-use-exp/tree/main/.codex/skills/cc-api-contract-safety
Command: npx skills add https://github.com/doccker/cc-use-exp --skill cc-api-contract-safety

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Frontend-backend interface contracts often drift silently: list endpoints return raw arrays while the frontend expects paginated objects, filter options come back empty, and temporary frontend compatibility shims end up masking the real backend contract problems indefinitely. This Skill provides a structured checklist to detect and fix contract drift at the root cause.

Core Features & Use Cases

  • Response Wrapping Audit: Verifies that list, detail, enum, and filter endpoints all use the project's unified success response helper instead of ad-hoc shapes.
  • Pagination & Filter Contract Checks: Confirms field naming (page, pageSize, total, items), page index base, and that filter options come from real data rather than contract mismatches.
  • Temporary Compatibility Governance: Requires every frontend compatibility branch to document its exit condition and removal plan, separating root-cause fixes from short-term fallbacks.
  • Use Case: During frontend-backend integration, a list page renders but pagination is broken and filters are empty. Use this Skill to inspect the real API responses, identify that the backend returns a bare array instead of the paginated wrapper, fix the backend contract, and schedule removal of the frontend dual-format shim.

Quick Start

Use the cc-api-contract-safety skill to review the list, detail, and filter endpoints of this feature and check whether the response wrapping and pagination contracts are consistent.

Frequently Asked Questions about cc-api-contract-safety

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I fix frontend-backend API contract mismatches?

Inspect the real API responses or server logs first, then compare them against what the frontend expects. Fix the backend contract at the root cause when possible, and treat frontend compatibility code only as a short-term transition with a documented exit condition.

How to standardize pagination structure across list APIs?

Define one paginated response shape with explicit fields such as page, pageSize, total, and items, and apply it through a unified success response helper. Verify the page index base (0-based or 1-based) is consistent and avoid mixing raw arrays with paginated objects long-term.

Why does my filter dropdown return empty options?

Empty filter options are often a contract mismatch rather than genuinely missing data. Check whether the filter endpoint returns data from real status fields, whether enum values match the actual list data, and whether the frontend is reading the wrong response shape.

When should frontend compatibility shims for API responses be removed?

Remove them once the backend contract is unified and all consumers are verified against the real response. Every compatibility branch should record the problem it solves, its exit condition, and a removal plan so it does not permanently mask contract drift.

What are common API contract anti-patterns in frontend-backend integration?

Common anti-patterns include accepting dual response formats permanently, fixing only the list endpoint while ignoring detail and option endpoints, backfilling filter options from current page data, and guessing field names from type definitions without checking real responses.