Design API and module boundaries with clear contracts, error semantics, pagination, and additive compatibility. Use before implementing REST/GraphQL endpoints, SDKs, or public module APIs.
Scanned 9/6/2026
Install to Claude Code
npx -y skills add charlieviettq/awesome-agent-skill --skill api-and-interface-design --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Api And Interface Design?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/charlieviettq-api-and-interface-design-awesome-agent-skill)More formats (shields.io, HTML) on the badges page.
---
name: api-and-interface-design
description: "Design API and module boundaries with clear contracts, error semantics, pagination, and additive compatibility. Use before implementing REST/GraphQL endpoints, SDKs, or public module APIs."
allowed-tools: Read, Glob, Grep
---
# API and Interface Design
Contract-first design for HTTP APIs, GraphQL, CLI surfaces, and library module boundaries. Complements `secure-api-design` (security) and `agent-tool-contracts` (LLM tools) with general interface ergonomics and evolution rules.
## When to use
- New public or cross-team API
- Breaking-change review
- Designing pagination, filtering, idempotency, or error shapes
## When not to use
- Internal refactor with no boundary change
- Security-only audit (use `secure-api-design`)
- Agent tool schema only (use `agent-tool-contracts`)
## Design checklist
### Contract
- Resource naming consistent (nouns, plural collections)
- Versioning strategy documented (URL prefix, header, or additive-only)
- Request/response schemas with examples for happy path + common errors
- Idempotency keys for mutating operations where retries matter
### Errors
- Stable machine-readable codes separate from human messages
- HTTP/status mapping documented; no stack traces in client responses
- Validation errors: field-level detail when safe (no PII leakage)
### Pagination and lists
- Cursor-based preferred for large/live datasets; offset only when bounded
- Default and max page size documented
- Sort/filter params explicit; reject unknown params predictably
### Compatibility
- Additive changes only in minor versions
- Deprecation headers or sunset dates for removals
- Consumer migration notes in changelog
### Observability
- Correlation/request IDs in responses or logs
- Rate-limit headers where applicable
## Workflow
1. Draft resource model and primary use cases
2. Write example requests/responses (including errors)
3. Run `doubt-driven-review` or `secure-api-design` for high-risk surfaces
4. Implement with tests locked to contract examples
## Output
- Short design note or OpenAPI/GraphQL schema sketch
- Compatibility and deprecation table if evolving an existing API
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!