api-design
/api-design
Buduje gotowe do produkcji API HTTP z cienkimi handlerami, spójnymi kopertami błędów, health checkami, CORS, idempotencją, limitami zapytań i łagodnym zamykaniem, z orpc i schematami Zod.
- Autor
- jagreehal ↗
- Repozytorium
- jagreehal-claude-skills ↗
- Licencja
- MIT
- Ostatnia zmiana repozytorium
- 30.07.2026
Ocena i bezpieczeństwo
- Pliki w paczce
- 3
- Skrypty
- 0
- Komentarze HTML
- 0
- Adresy URL w SKILL.md
- 0
Brak sygnałów. Repozytorium zmienione 30.07.2026, bez odwołań do wycofanych modeli i API.
MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.
Co robi i kiedy
Buduje gotowe do produkcji API HTTP z cienkimi handlerami, spójnymi kopertami błędów, health checkami, CORS, idempotencją, limitami zapytań i łagodnym zamykaniem, z orpc i schematami Zod.
Oryginalny opis (EN)
Builds production-ready HTTP APIs with thin handlers, consistent error envelopes, health checks, CORS, idempotency, rate limiting, and graceful shutdown. Use this skill when designing or implementing HTTP endpoints, orpc routes, Zod request/response schemas, or mapping domain errors to status codes. Do not use when/for pure domain logic without HTTP (use fn-args-deps and result-types) or frontend data fetching alone.
Jak działa
- Critical rules
- Workflow
- Resources
- Validation
- Constraints
Podgląd SKILL.md
---
name: api-design
description: >-
Builds production-ready HTTP APIs with thin handlers, consistent error
envelopes, health checks, CORS, idempotency, rate limiting, and graceful
shutdown. Use this skill when designing or implementing HTTP endpoints, orpc
routes, Zod request/response schemas, or mapping domain errors to status
codes. Do not use when/for pure domain logic without HTTP (use fn-args-deps
and result-types) or frontend data fetching alone.
version: 1.3.0
libraries: ["@orpc/server", "zod"]
---
# API Design Patterns
## Critical rules
- Handlers only translate HTTP ↔ domain: validate at the edge, call `fn(args, deps)` / Result, map to response. No business logic in handlers.
- One error envelope everywhere; `ORPCError(code)` must match `ErrorResponse.code`.
- Shared domain-error → status mapping; `/health` and `/ready`; `X-Request-ID` in middleware once.
- Mutations require `Idempotency-Key`; 429 includes `Retry-After`; drain with 503 on shutdown.
- One file per route with co-located tests; compose routers via factories.
- Before implementing routes or ops concerns, read [references/patterns.md](references/patterns.md).
## Workflow
1. Define Zod input/output schemas at the framework boundary.
2. Create a route factory `createX({ deps })` that delegates to domain functions.
3. Map domain errors through the shared status table and consistent envelope.
4. Add health/ready, CORS, request ID middleware, idempotency, rate limits, shutdown — see [references/patterns.md](references/patterns.md).
5. Compose routers at module boundaries (`createPostsRouter` → `createApiRouter`).
6. Write co-located tests with `call()` — see [references/testing.md](references/testing.md).
## Resources
- [references/patterns.md](references/patterns.md) — factories, errors, health, CORS, idempotency, organization. Read when designing endpoints.
- [references/testing.md](references/testing.md) — route unit tests with mocked deps. Read when writing route tests.
## Validation
- [ ] Routes are factories with injected deps; handlers stay thin
- [ ] Errors use one envelope; codes match
- [ ] Shared status mapping; `/health` and `/ready` exist
- [ ] Mutations honor Idempotency-Key; 429 has Retry-After; shutdown → 503
- [ ] X-Request-ID set in middleware
- [ ] Co-located success and error tests per route
## Constraints
- Internal calls and background jobs without HTTP are out of scope. Retry policy belongs in `resilience`.
- Related: `fn-args-deps`, `validation-boundary`, `result-types`, `resilience`, `observability`.
Pliki w paczce (3)
- SKILL.md 3 KB
- references/patterns.md 4 KB
- references/testing.md 1 KB
Wersje
| Repozytorium | Wynik | Licencja |
|---|---|---|
| Ta strona · jagreehal/jagreehal-claude-skills | 100 | MIT |
| proyecto26/system-design-skills | 100 | MIT |
| ericrisco/rsc-harness | 100 | MIT |
| yonatangross/orchestkit | 100 | MIT |
| travisjneuman/.claude | 100 | MIT |
| wrongstack/wrongstack | 100 | MIT |
| komluk/scaffolding | 100 | MIT |
| OKHP3/skillz | 100 | MIT |
| event4u-app/agent-config | 100 | MIT |
Migawka bazy z 28.10.2026 · wersja paczki 54307dc829cb (skrót SHA-256 całej paczki)
Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.
Podobne skille
- 100go-api-design
Projektuje API HTTP i REST w Go: handlery, routing ServeMux, middleware, walidacja żądań, paginacja, idempotentność, health checki, odpowiedzi błędów i łagodne zamykanie. - 100api-forge
Projektuje API REST i GraphQL z OpenAPI 3.1, obsługą błędów, paginacją, limitami, webhookami i idempotencją. - 100rest
Projektuje REST API: OpenAPI 3.1, semantykę HTTP, zasoby, stronicowanie, cache, negocjację treści, CORS, limity i obsługę błędów. - 100api-designer
Generuje gotowe do produkcji specyfikacje endpointów REST API dla dowolnego systemu lub domeny opisanej przez użytkownika. - 100orpc-contract
Projektuje API oRPC v2 metodą contract-first: kontrakt przez oc z @orpc/contract, implementacja przez implement z @orpc/server oraz typowani klienci korzystający z kontraktu. - 100errors-and-status-codes
Pomaga projektować odpowiedzi błędów API: dobór kodów HTTP, koperty błędów, walidację z komunikatami per pole, RFC 9457 Problem Details oraz korelację identyfikatorów żądań i śladów.