api-ui-contract

Define and implement the contract between a user-facing interface and its backend API so user states, server semantics, validation, authorization, concurrency, and compatibility remain coherent across both sides.

Ir para a instalação

Repositório: Dadmin88/hermes-agency
Última atividade na origem: 16 de agosto de 2026 às 06:25
Idioma detectado do SKILL.md: inglês
Estrelas: 8
Forks: 2

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.

npx skills add https://github.com/Dadmin88/hermes-agency --skill api-ui-contract

O comando permanece em uma só linha. Role horizontalmente para revisá-lo antes de copiar.

Prefere uma cópia local? Baixe os arquivos disponíveis atualmente no SkillsMP.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

SKILL.md

Instruções da origem · Visualização somente leitura

Voltar à pesquisa Voltar à instalação

API to UI Contract

Use when one bounded feature spans frontend and backend and the two layers need a clear shared behavior contract.

Procedure

Start from the product flow and list every user-visible state/action the backend must support: load, empty, success, validation, permission, conflict, slow/pending, retry/recovery, and destructive confirmation where relevant.

Define backend operations around domain/user intent and map their inputs/outputs/errors to those UI states without leaking raw persistence or provider structures into components.

Specify field types, identifiers, optional/null behavior, enums/states, units, ordering, pagination, and timestamps clearly enough that both sides make the same assumptions.

Keep validation ownership explicit: client validation improves feedback, while server-side validation/authorization/domain invariants remain authoritative.

Define concurrency and stale-data behavior for edits, optimistic changes, duplicate submissions, conflicts, refresh, cancellation, and out-of-order responses where relevant.

Separate authentication state, authorization failures, missing resources, validation problems, conflicts, dependency failures, and unexpected server failures so the UI can respond appropriately.

Define compatibility when frontend/backend versions may roll independently or clients can remain cached. Avoid changes that require impossible lockstep deployment without an explicit plan.

Encode the contract using the project's normal schemas/types/fixtures and add tests on both client handling and server behavior for the most important states.

Validate the complete flow against the real assembled frontend/backend, including at least one negative/conflict/failure path.

Decision rules

The API is not merely a database-shaped transport for the UI.

Frontend state should reflect server truth without duplicating server authorization/business invariants as authority.

If the contract becomes a shared public/cross-team interface, involve agency-software-architect or the owning Backend/Frontend specialists rather than making a local full-stack decision silently.

Provider or Fleet node details should remain behind backend/runtime boundaries unless the product explicitly exposes them.

Quality gate

The contract is ready when every important UI state maps to explicit server behavior, types/errors/concurrency are understood on both sides, authorization and business invariants remain server-enforced, compatibility is workable, and client/server plus assembled-flow tests prove the shared semantics.