| name | orpc |
| description | Use when building, reviewing, or debugging oRPC code — defining contracts, writing routers/procedures/middleware, wiring an RPCHandler or OpenAPIHandler, calling procedures via RPCLink or server-side clients, integrating TanStack Query / AI SDK / Better Auth, exposing Server Actions, or generating OpenAPI specs. Load when a file imports `@orpc/*` or the task involves type-safe RPC/OpenAPI APIs. |
oRPC
Use this skill to build and review oRPC code against the official documentation.
What it is: oRPC (OpenAPI Remote Procedure Call) defines and calls remote/local procedures through an end-to-end type-safe API that also adheres to the OpenAPI spec. Official docs: https://orpc.dev. Repo: https://github.com/unnoq/orpc.
How to use the references
oRPC ships LLM-friendly docs, not a code skill. Every reference below is a Markdown rendering of a docs page (.md suffix). Fetch only the pages relevant to the task.
Workflow
- Identify the surface: contract, router/procedure, handler (RPC vs OpenAPI), client (server-side vs link), or integration.
- Read only the relevant reference page(s) below — append
.md, don't guess APIs.
- Prefer contract-first when client and server are separate packages; co-located code can use the router directly.
- Match the project's existing handler and serializer choices before introducing new ones.
- Validate type-safety end to end; throw
Error instances, never literals.
Core Concepts
Contract First
Handlers
Clients
Adapters (server framework hosting)
Plugins
Integrations
Best Practices
Advanced
Guardrails
- Don't invent API surface — fetch the relevant
.md page; oRPC's API is versioned and changes between majors.
- Throw
Error instances, never literal values (oRPC error flow + type inference depend on it).
- Keep contract and implementation types in sync; let the contract drive client types.
- Respect the project's existing handler/serializer/adapter choices instead of mixing them.