What this prompt does
This prompt makes the model design a fully type-safe HTTP client built on advanced TypeScript generics, returning real code rather than a sketch. The goal is to push your API contract into the type system so the compiler — not a runtime crash — catches wrong payloads and unhandled status codes. Each endpoint is declared once in a registry, and request and response types are inferred from there, so callers never restate shapes by hand and a backend change shows up as a compile error instead of a production incident.
The [transport] variable sets the underlying fetch layer the client wraps, and [validator] chooses the schema library used to declare each route's request and per-status response schemas. [auth_scheme] controls how the auth header is attached, while [strictness] decides what happens on schema drift — for example throwing on unknown fields versus tolerating them. The standout feature is status-code narrowing: a 200 result and a 422 error become distinct types at the call site, so you cannot accidentally read a success field off an error.
When to use it
- Building a frontend (React, Next.js, or plain TS) against your own APIs and tired of renamed-field bugs.
- Centralising every endpoint definition so route shapes live in one typed registry.
- Forcing exhaustive error handling so 422s and 500s can't be silently ignored.
- Typing path params so
/users/:idis checked and built safely rather than string-concatenated. - Catching schema drift early when the backend contract changes underneath the client.
- Sharing one client across several frontends so they all stay in sync with the contract.
Example output
You receive the client core, two example endpoint definitions, and typed consumer code. The consumer example shows one successful call and one exhaustively-handled error path, demonstrating how status-code narrowing forces you to deal with each outcome. Const-generic route params make path building checkable, a shared error envelope unifies failures, and the chosen [strictness] mode determines how loudly the client reacts when the response doesn't match its schema. It's a working pattern you extend per route, not a finished SDK, so you keep ownership of the registry as it grows.
Pro tips
- Spend your attention on deliverable 3 (status-code narrowing) — that's exactly where untyped clients quietly swallow errors, so verify the 200 and 422 types really are distinct at the call site.
- Pick
[validator]to match what your codebase already uses so you don't add a second schema library just for the client. - Use the strict end of
[strictness]during development to surface backend drift, then decide per environment whether to keep throwing on unknown fields. - Confirm
[transport]matches your runtime; native fetch behaves differently across Node versions and browsers around things like timeouts and abort. - Set
[auth_scheme]to your real header convention so the client attaches credentials correctly without per-call boilerplate. - Keep the endpoint registry as the single source of truth — if you find yourself restating types in a caller, the inference setup needs fixing.
