원클릭으로
orpc
ORPC APIs. Use when creating procedures, routers, middlewares, scoped errors, endpoint schemas, or route/domain API structure.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
ORPC APIs. Use when creating procedures, routers, middlewares, scoped errors, endpoint schemas, or route/domain API structure.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
Skill writing principles. Use when creating, editing, or reviewing any SKILL.md.
Skill rule extraction and creation. Use when the user says /learn.
Kysely database queries. Use when writing, reviewing, or debugging Kysely selects, mutations, joins, transactions, filters, or aggregates.
Frontend components and Tailwind. Use when creating, reviewing, refactoring, splitting, or organizing React components, shared components, component folders, or Tailwind classes.
TanStack Query in React. Use when implementing or reviewing queries, mutations, invalidation, or query hooks.
Lint and optimize existing skills. Use when the user says /skill-linter.
SOC 직업 분류 기준
| name | orpc |
| description | ORPC APIs. Use when creating procedures, routers, middlewares, scoped errors, endpoint schemas, or route/domain API structure. |
Use ORPC routers as transport wiring. Domain/database objects own behavior.
Global errors live on the base procedure. Compose middlewares with .use().
Endpoint-specific errors stay scoped to the endpoint with .errors({ CODE: {} }). Backend errors expose codes, not human-facing messages. Frontend owns translated/display text.
Use .input(schema) for input boundaries. Do not define output schemas by reflex; outputs are inferred from the handler result. No input means no .input(type({})).
Use one domain schema object per domain. Router and DB/manager code derive input types from the schema; do not redeclare input shapes.
Typical ownership:
schemas.ts: operation schemasdb.ts: database operations, authorization/visibility predicates in SQLrouter.ts: pure transport dispatchmanager.ts: orchestration when user/request context colors multiple operationsUse a Manager/class when identity or request context is reused across several methods. Do not pass user/headers through every function when they are the object identity.
Handlers that only call one owner should stay as bodyless arrow expressions and return the promise directly.
update: protectedProcedure
.input(ItemSchemas.update)
.handler(({ input, context }) => DbItems.update(context.user.id, input)),
Do not destructure input just to pass its fields onward. Pass the whole input.
If a handler validates, transforms, branches, catches errors, or coordinates more than one operation, move that logic to the domain owner or Manager.
Handlers must not return undefined. Suspense clients crash on undefined data.
If a DB read uses executeTakeFirst, wrap the result in an object such as { data }. The inner field may be absent; the endpoint result itself may not. Use executeTakeFirstOrThrow when absence is impossible or exceptional.
Read endpoints should match the visual/use-case contract. If one visual unit needs facts from multiple tables, prefer an aggregate read in the owning domain over assembling the contract in the component.
Use PATCH-like update endpoints with optional fields when fields can coexist.
Avoid updateName, updateStatus, updateType splits unless each operation has different authorization, side effects, or domain meaning.
Middleware puts request/response headers into context. Classes that manage auth/session behavior receive the relevant Headers in the constructor instead of threading headers through every method.
Do not test ORPC endpoints with raw curl. Use the typed ORPC client or automated tests, because protocol details like headers, serialization, and path encoding matter.