Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/ericrisco/rsc-harness/api-designnpx skills add ericrisco/rsc-harness --skill api-designgit clone --depth 1 https://github.com/ericrisco/rsc-harnessWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/ericrisco/rsc-harness/api-design)<a href="https://agentmods.dev/skills/ericrisco/rsc-harness/api-design"><img src="https://agentmods.dev/badge/skills/ericrisco/rsc-harness/api-design.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00105 | $0.03080 |
| Opus 5 | $0.00053 | $0.01540 |
| Sonnet 5 | $0.00021 | $0.00616 |
| Haiku 4.5 | $0.00011 | $0.00308 |
Grade A, and why
api-design scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 183 lines — stays where its author put it; the contents beside it link to each section on GitHub.
API design
Your one job
You design the contract an API exposes. You do not write the handler. The deliverable is a set of decisions a backend skill can implement directly: resource shapes, URLs, methods, the status-code map, one error envelope, pagination params, versioning rules — ideally captured as an OpenAPI 3.1 document.
When the user names a framework (FastAPI, NestJS, Go, Node), they own the build; you are pulled in for contract questions. Settle the contract first, then hand off (see Handoff). Keep every decision framework-neutral: nothing here should mention an ORM, a router, or a DI container.
REST vs GraphQL vs hybrid
Pick on traffic shape, not fashion. Decide once, write it down.
| Situation | Choose | Why |
|---|---|---|
| CRUD-ish resources, public API, HTTP caching matters | REST | URLs map to resources; CDN/proxy caching works on GET + ETag out of the box |
| Many client shapes, deep nested graphs, mobile over-fetch is real | GraphQL | one round-trip, client picks fields; no N endpoints per screen |
| Stable resource API + one rich read surface for a client app | Hybrid | REST for the system of record, a GraphQL read layer on top |
Operational gotcha that decides monitoring: GraphQL returns HTTP 200 even when a field errored — failures live in an errors[] array next to partial data. Your dashboards cannot alert on 5xx; you must alert on the errors[] payload. REST signals failure with the HTTP status itself. If your ops team lives on status-code SLOs, that is a point for REST. Schema/nullability design, mutation and error-union conventions, and this error model in full: references/graphql-design.md.
Resource & URL modeling
Resources are nouns; HTTP methods are the verbs. Never put a verb in a path.
Rules, each with its reason:
- Plural collections, consistent everywhere —
/projects,/projects/{id}. Pick plural and never mix singular in; inconsistent naming is the most-cited design smell. - Nest sub-resources one level —
/projects/{id}/tasks. Deeper than one level (/projects/{p}/tasks/{t}/comments/{c}) gets unreadable; link to the flat resource instead (/comments/{c}). - Methods carry intent —
GETread,POSTcreate,PUTfull replace,PATCHpartial update,DELETEremove. A path never says what it does. - Filter/sort/select via query string, not new paths —
?status=open&sort=-created_at&fields=id,title. OneGET /projectshandles all of it; don't mint/projects/openand/projects/byDate.
What ships with it
7 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 183 lines · 105 tokens per session scan A 4758665caa06
api-design is a skill published in the GitHub repository ericrisco/rsc-harness (60 stars, last pushed yesterday), licensed MIT. It adds 105 tokens to every session and 3,080 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
api-design
API contract design for REST and GraphQL, covering resource shape, URL and header versioning with deprecation windows, RFC 9457 Problem Details error handling, and OpenAPI specs. Use when specifying the wire contract an endpoint exposes, choosing a versioning scheme, or standardizing error response bodies across…
api-design
Use when designing REST or GraphQL APIs, defining endpoints, implementing pagination/filtering, handling API versioning, or establishing API documentation with OpenAPI/Swagger.
api-design
Design REST APIs with consistent naming, error handling, versioning, and pagination. Use when designing a new API, reviewing an existing one, or writing an OpenAPI spec.
api-designer
Designs production-grade APIs — REST, GraphQL, gRPC, and AsyncAPI patterns including pagination, versioning, error handling, rate limiting, and API governance. Use when the user asks to design APIs, create endpoints, build an API layer, write OpenAPI specs, or needs help with REST/GraphQL/gRPC service design.
api-design
Design and implement RESTful APIs with proper routing, validation, error handling, and documentation. Use when building new API endpoints, designing API architecture, or improving existing APIs.
api-design
REST API design patterns. URL naming, HTTP status codes, pagination, RFC 7807 error responses, versioning, and OpenAPI.