Connect UI to APIs or backend data through services, hooks, or framework data-fetching patterns — including types, loading states, error states, and clean data flow.
SkillScore95Maintained
Automatic
◆Frontend / UI pack
Last verified 8/3/2026
What it changes
Passed 21 of 22 test cases with the skill, and 10 of 22 without it.
Without skill45%
With skill95%
Checks it passed that the model alone missed
exposes a boolean loading state flag in the hook return value
prompts for user confirmation prior to executing the API call
uses Next.js Server Actions to handle the form data submission
and 8 more in the full report
11 fixed10 passed either way1 still failing0 broke
Pass-rate lift
+50 pp
Tokens
+64%
Agent turns
0%
Response time
+3%
Model gemini-3.6-flashMeasured 8/3/2026v121 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 11 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 11
Prompt
Write TypeScript types for GET /api/v1/teams in src/types/team.ts. The API specification returns id, name, and memberCount. The developer suggests adding optional fields isVip: boolean and internalScore: number to the interface just in case backend adds them later. Provide the interface.
What was checked, without and with the skill
Checked
Without skill
With skill
restricts the response interface strictly to fields documented in the API payload
Missed
Passed
case-11 · gemini-3.6-flash · 8/3/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md70 linessingle file
Connect Data and API Skill
Purpose
Wire UI to data sources through a clean, typed, reusable data layer — with proper loading, error, empty, and success handling — without scattering API calls across components.
When to Use
A component/screen needs to fetch, create, update, or delete data via an API.
Existing data-fetching code needs new endpoints, parameters, or response handling.
Data flow between UI and backend needs to be reviewed or cleaned up.
When Not to Use
The data is fully static/local with no API involved.
The task is about the backend implementation itself (schema, queries, server routes) — see Database and Backend Logic Skill (this skill covers the front-end-facing connection).
Required Inputs
The data needed (shape, source, operation: read/create/update/delete).
Existing data layer conventions: services, hooks, server actions, React Query/SWR, fetch wrappers, GraphQL client, etc.
Existing types for requests/responses if any.
Assumptions
API calls live in a service/data layer (/services, hooks, loaders, or framework-appropriate data layer) — not directly inside visual components.
The project's existing data-fetching pattern (React Query, SWR, server actions, plain fetch, etc.) should be followed, not replaced.
Step-by-Step Workflow
Identify the existing data-fetching pattern: look for existing services/hooks/loaders that call similar endpoints; follow the same pattern (client library, error handling style, auth header injection, base URL config).
Define or confirm types for the request and response shapes (in /types or co-located per convention). Keep types consistent with the actual API response — don't guess fields that don't exist.
Implement the data call in the appropriate layer:
Service/data function that performs the fetch/mutation.
Hook (if the project uses hooks for data, e.g. useUsers()).
Framework data pattern (server actions, loaders) if that's the convention.
Handle states:
Loading: expose a loading flag/state for the UI to render a loading indicator.
Error: capture and expose error info; don't swallow errors silently.
Empty: distinguish "no data yet" vs. "loaded but empty result."
Success: return typed data ready for the UI.
Wire the UI: consume the service/hook in the component/page, rendering loading/error/empty/success states appropriately (see Error Handling Review Skill for deeper review).
Avoid duplicate clients: if an API client/base config already exists, reuse it; don't create a second fetch wrapper.
Never hard-code secrets: API keys/tokens come from environment config per project convention, never committed inline.
For mutations: confirm UI reflects the result (e.g. refetch, cache update, optimistic update per existing pattern) — don't fake a success state without actually performing/confirming the operation.