frontend-data-contracts
Helps your agent ensure data security in the frontend. It creates a system to check data types in communication with the backend.
What it does
This tool helps ensure that data entering your web or mobile app is reliable and safe. It creates a single barrier where data is checked and transformed into a secure format before being used.
When to use it
- ✓When you want to be sure that data received from a server is correct.
- ✓When building apps that require data security and reliability.
- ✓To prevent errors caused by unexpected data in React or React Native apps.
Example of what to ask your AI
“Check invoice data before showing it in the app.”
Want more? Open the sections below.
How to use
The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.
Skill link
Ready-to-paste message
How it works
It works by defining a single entry point for all data requests. At this point, raw data from the internet is converted into a safe and trusted format, or a clear error is returned.
Installation
Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.
In the terminal (Claude Code, Codex, Cursor), in your project folder:
npx skills add sickn33/agentic-awesome-skills --skill frontend-data-contractsOr download just the file:
curl -L https://raw.githubusercontent.com/sickn33/agentic-awesome-skills/main/plugins/agentic-awesome-skills-claude/skills/frontend-data-contracts/SKILL.md -o SKILL.mdTechnical content (original SKILL.md)
Original text by the author, straight from GitHub.
Frontend Data Contracts (typed network boundary)
When to Use
Use this skill when you need a portable, framework-agnostic discipline for type safety at the network edge of any React or React Native app. Establishes one typed API client as the single fetch boundary, a parse-don't-validate rule that turns wire JSON into trusted domain types before it enters the app, runtime parsing, normalized errors and branded identifiers.
Portable skill — readable by Claude Code, OpenCode, Codex, Cursor, Windsurf, and others. This skill describes a discipline at the network edge — one client, one envelope, one error type, validated types — not a state library or a styling system. It pairs with the frontend-architecture skill (the client lives in
shared/api-client/) and is the foundation the frontend-optimistic-mutations skill builds on.
The goal: the moment data crosses from the network into the app, it stops being any-shaped wire
JSON and becomes a trusted, typed domain value — or it becomes a single, typed error.
There is exactly one place this transformation happens, and nothing untyped escapes it.
Example contract
The snippets marked “essence” are architecture sketches with omitted project dependencies and methods, not a complete client. A generic get<Invoice> type parameter is only a compile-time assertion: it cannot establish runtime validity. Require the actual schema parse before treating a value as an Invoice, normalize parser failures into the project error type, and keep authorization independent of both schema validation and branded IDs. Bind adapter behavior to the installed library version; do not assume an unsupported per-query callback exists.
0. The five core ideas
- One client is the only fetch boundary. A single typed
apiClientwrapsfetch. Components and hooks never callfetch/axiosdirectly — the boundary is enforceable in review and lint. - Parse, don't validate. Wire JSON is parsed into domain types at the boundary. After the client returns, the value is trusted everywhere downstream — no defensive
?.chains, no re-checking shapes in components. - One envelope. Every response is
{ data }on success or{ error }on failure. The client unwrapsdataand throws onerror, so callers receive the payload directly or a typed throw. - One normalized error type. Server error envelope, non-2xx status, malformed body, network failure, and abort all become a single
ApiErrorwith a machine code, status, and optional per-field errors. Callers handle one shape. - Identifiers are branded. Domain IDs are nominal types (
InvoiceId,CustomerId) so the compiler rejects passing one where another is expected — the most common silent bug in data-heavy UIs.
1. Directory layout
The boundary is one folder in shared/ (per the frontend-architecture skill).
src/shared/api-client/
├── index.ts ← barrel: apiClient, ApiError, types
├── client.ts ← the fetch wrapper: buildUrl, headers, parse, verbs
├── config.ts ← base URL resolution, default headers
├── error.ts ← the ApiError class + code→message-key mapping
├── types.ts ← envelope types, HttpMethod, RequestOptions, field errors
└── client.test.ts ← boundary behavior tests (envelope, errors, network)
Domain entity types and their schemas live with their feature module
(modules/{feature}/types/) or a shared contract package; the client is generic over T.
2. One client, the only fetch boundary
Every verb returns the unwrapped data payload typed by the caller, and throws an
ApiError on any failure. Components never see envelopes or raw responses.
// shared/api-client/client.ts (essence)
export const apiClient = {
get<T>(path: string, options?: RequestOptions): Promise<T> {
return request<T>("GET", path, undefined, options);
},
post<T>(path: string, body?: unknown, options?: RequestOptions): Promise<T> {
return request<T>("POST", path, body, options);
},
patch<T>(path: string, body?: unknown, options?: RequestOptions): Promise<T> {
/* … */
},
put<T>(path: string, body?: unknown, options?: RequestOptions): Promise<T> {
/* … */
},
delete<T>(path: string, options?: RequestOptions): Promise<T> {
/* … */
},
} as const;
export type ApiClient = typeof apiClient;
// CORRECT — a feature hook wraps the client, typed by the caller
…
FAQ
What does 'type safety' mean?
It means the code knows exactly what kind of information to expect (like a number, text, or date), preventing unexpected errors.
What is the 'network' or 'network edge'?
It's the point where data enters your application from the outside, such as from a server on the internet.
Why 'parse, don't validate'?
Validating only checks if data is correct, but 'parsing' transforms it into a safe and trusted format that the app can use securely.
Details
Original description by the author
A portable, framework-agnostic discipline for type safety at the network edge of any React or React Native app.
Popularity
- GitHub stars
- 48k
- Ranking position
- #3049
- License
- MIT
- Updated
- 10/15/2026
Comments
- …
More skills from this repository
00-andruia-consultant
Helps your agent start or improve AI projects. It analyzes code, suggests tools, and creates action plans in Spanish.
sickn33/agentic-awesome-skills
007
Lets your agent perform security audits and threat modeling. It's useful for protecting projects against attacks and vulnerabilities.
sickn33/agentic-awesome-skills
10-andruia-skill-smith
Helps your agent create or improve AI tools. It defines how tools work, writes documentation, and validates the structure.
sickn33/agentic-awesome-skills
20-andruia-niche-intelligence
Lets your agent create a summary about a specific industry. It's useful for understanding the context, rules, usage patterns, and risks of a project, using reliable sources.
sickn33/agentic-awesome-skills
Similar skills
angular-developer
Helps your agent create Angular code and give project structure advice. Useful for starting new projects, creating code parts, or improving performance and accessibility.
affaan-m/ECC
frontend-a11y
Helps your agent make web interfaces accessible to everyone. It ensures websites and apps work well with screen readers and keyboard navigation.
affaan-m/ECC
frontend-patterns
Has your agent apply modern patterns in frontend development. It optimizes performance, manages state, and follows best practices in React and Next.js.
affaan-m/ECC