name	API Consumption Contract
description	Verify and document how the user-facing surface consumes the agreed backend/API contract.
when-to-use	Use before frontend implementation and during integration with a backend/API/service.
user-invocable	false
context	inline

Use this skill to keep frontend work from drifting into direct-file, mock-only, or independent behavior.

Required contract artifacts:

Read INTERFACE_CONTRACT.md before implementation when it exists.
If the contract was only sent through A2A, collaborate with Backend to write <project_root>/INTERFACE_CONTRACT.md.
Keep frontend assumptions in FRONTEND_PLAN.md aligned with the contract.

Frontend consumption checklist:

Data loading
- Exact endpoint/command/event used.
- Request method, headers, body shape, and timeout/retry behavior.
- Loading, empty, and error UI states.
Data mutation
- Validation before request.
- Payload shape.
- Success update behavior.
- Failure behavior that preserves user input when appropriate.
Rendering
- Field mapping from contract to UI.
- Date/number/status formatting.
- Missing/null/unknown value behavior.
Integration evidence
- Smoke command or browser/manual steps proving real backend consumption.
- For subprocess/CLI tests, storage fixtures and overrides must be visible to the spawned process through the agreed contract. Use env vars, cwd, config files, flags, or fixture paths; do not rely on in-process monkeypatches that the subprocess cannot see.
- Evidence to add to INTEGRATION_REPORT.md.
Boundaries
- Do not directly read/write backend persistence files.
- Do not hardcode fixture data except for explicitly marked demos/tests.
- Do not redesign backend internals.

Más de este repositorio

mismo repositorio

Convert source notes into claim-level evidence with confidence and limitations.

Verify source traceability, artifact completeness, and citation correctness before citation_qa gate.

Write an evidence-backed final research report from sources and the evidence matrix.

Review research method quality, source diversity, bias, and conclusion strength.

Convert a broad research request into subquestions, assumptions, and source criteria.

Design and execute a multi-round SearxNG/arXiv search strategy.

name	API Consumption Contract
description	Verify and document how the user-facing surface consumes the agreed backend/API contract.
when-to-use	Use before frontend implementation and during integration with a backend/API/service.
user-invocable	false
context	inline

Use this skill to keep frontend work from drifting into direct-file, mock-only, or independent behavior.

Required contract artifacts:

Read INTERFACE_CONTRACT.md before implementation when it exists.
If the contract was only sent through A2A, collaborate with Backend to write <project_root>/INTERFACE_CONTRACT.md.
Keep frontend assumptions in FRONTEND_PLAN.md aligned with the contract.

Frontend consumption checklist:

Data loading
- Exact endpoint/command/event used.
- Request method, headers, body shape, and timeout/retry behavior.
- Loading, empty, and error UI states.
Data mutation
- Validation before request.
- Payload shape.
- Success update behavior.
- Failure behavior that preserves user input when appropriate.
Rendering
- Field mapping from contract to UI.
- Date/number/status formatting.
- Missing/null/unknown value behavior.
Integration evidence
- Smoke command or browser/manual steps proving real backend consumption.
- For subprocess/CLI tests, storage fixtures and overrides must be visible to the spawned process through the agreed contract. Use env vars, cwd, config files, flags, or fixture paths; do not rely on in-process monkeypatches that the subprocess cannot see.
- Evidence to add to INTEGRATION_REPORT.md.
Boundaries
- Do not directly read/write backend persistence files.
- Do not hardcode fixture data except for explicitly marked demos/tests.
- Do not redesign backend internals.