befe-contract-design

Designs two-sided OpenAPI/AsyncAPI contracts enabling parallel backend and frontend development.

Updated Apr 26, 2026
One-click install
npx skills add https://github.com/Jin9/skillify-foundation --skill befe-contract-design-jin9
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: befe-contract-design
Source: https://github.com/Jin9/skillify-foundation/tree/main/treasury/befe-contract-design
Command: npx skills add https://github.com/Jin9/skillify-foundation --skill befe-contract-design-jin9

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Backend and frontend teams often block each other or drift apart when the API contract is undefined. This Skill designs a shared, machine-readable contract so both sides can build in parallel against a single source of truth. ## Core Features & Use Cases - Design-first source of truth: Authors an OpenAPI (sync) or AsyncAPI (events) spec shared by clients, mocks, and tests, reusing existing backend endpoint designs. - Parallel development enablers: Generates client types and a consumer mock/stub so the frontend can build and test before the backend exists. - Conventions and state binding: Defines cursor/keyset pagination, enumerated errors, BFF-per-client shaping, and loading/empty/error/optimistic frontend states. - Use Case: Given a set of user stories for a new feature, produce the shared OpenAPI contract, a mock server plan, and the frontend state-binding spec so web and backend teams start coding the same day. ## Quick Start Design the BE/FE contract for these user stories, including the OpenAPI source of truth, consumer mock, and frontend state-binding spec.

Frequently Asked Questions about befe-contract-design

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

FAQPage Schema
How do I design an API contract for parallel frontend and backend development?▼

Author a design-first OpenAPI or AsyncAPI spec as the single source of truth, generate client types from it, and provide a consumer mock so the frontend builds against the contract before the backend exists. This Skill produces exactly those artifacts from your user stories.

What is the difference between this and designing a single backend endpoint?▼

A single backend endpoint design covers only the provider side and belongs to api-contract-design. This Skill composes that with the frontend consumption side: client types, consumer mocks, BFF shaping, and state-binding contracts.

Does this Skill run contract tests or validate breaking changes?▼

No. It designs the contract only. Contract test execution (consumer pacts, provider verification) belongs to contract-testing-pact, and breaking-change validation belongs to universal-spec-validator.

What pagination convention does the contract use?▼

The contract uses cursor/keyset pagination with has_more and next_cursor fields, plus enumerated errors where each error carries a defined client action.

When should I not use a two-sided BE/FE contract design?▼

Avoid it when you only need one backend-exposed endpoint, when you want to execute contract tests, or when validating a tool/agent schema for breaking changes. Those cases map to api-contract-design, contract-testing-pact, and universal-spec-validator respectively.