agentleFS
weininghuiweininghui/skills/api-development/SKILL.md

api-development

Skill1 starsChanged 12 days agoMITView on GitHub

Meta-skill that orchestrates the full API development lifecycle — from design through documentation — by coordinating specialized skills, agents, and commands into a seamless build workflow.

10 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use git-workflow.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • Microsoft AzureSkill

    git-workflow

    Squad branching model: dev-first workflow with insiders preview channel

    Also in 4 projects that use this

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 6 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 9 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Follow these steps in order.

    line 22
  2. Distinctive:

    Write service-layer logic with input validation, authorization checks, database queries, and proper error propagation.

    line 44
  3. Distinctive:

    Write tests at three levels:

    line 50
  4. Distinctive:

    Deliverables: Test suite with coverage for happy paths, error cases, edge cases, and auth

    line 55
  5. Distinctive:

    Rule of thumb: Default to REST for public APIs.

    line 86
  6. Distinctive:

    Run through this checklist before marking any API work as complete.

    line 92

“Common” is measured: kept by at least 6 in 10 of the 9 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

API Development

Orchestrate the full API development lifecycle by coordinating design, implementation, testing, and documentation into a single workflow.

When to Use This Skill

  • Building a new API from scratch
  • Adding endpoints to an existing API
  • Redesigning or refactoring an API
  • Planning API versioning and migration
  • Running a complete API development cycle (design → build → test → document → deploy)

Orchestration Flow

Follow these steps in order. Each step routes to the appropriate skill or tool.

1. Design the API

Load the api-design skill to establish resource models, URL structure, HTTP method semantics, error formats, and pagination strategy.

Deliverables: Resource list, endpoint map, request/response schemas, error format

2. Generate OpenAPI Spec

Produce a machine-readable OpenAPI 3.x specification from the design. Use the OpenAPI template in api-design/assets/openapi-template.yaml as a starting point.

Deliverables: openapi.yaml with all endpoints, schemas, auth schemes, and examples

3. Scaffold Endpoints

Generate route files, request/response types, and validation schemas for each endpoint. Group routes by resource.

Deliverables: Route files, type definitions, validation schemas per resource

4. Implement Business Logic

Write service-layer logic with input validation, authorization checks, database queries, and proper error propagation. Keep controllers thin — business logic lives in the service layer.

Deliverables: Service modules, repository layer, middleware (auth, rate limiting, CORS)

5. Test

Write tests at three levels:

  • Unit tests — service logic, validation, error handling
  • Integration tests — endpoint behavior with real DB
  • Contract tests — response shapes match OpenAPI spec

Deliverables: Test suite with coverage for happy paths, error cases, edge cases, and auth

6. Document

Generate human-readable API documentation with usage examples and SDK snippets. Ensure every endpoint has description, parameters, request/response examples, and error codes.

Deliverables: API docs, changelog, authentication guide

7. Version and Deploy

Apply a versioning strategy, tag the release, update changelogs, and deploy through the pipeline. Follow the api-versioning skill for deprecation and migration guidance.

Deliverables: Version tag, changelog entry, deployment confirmation


API Design Decision Table

Choose the right paradigm for your use case.

CriteriaRESTGraphQLgRPC
Best forCRUD-heavy public APIsComplex relational data, client-driven queriesInternal microservices, high-throughput
Data fetchingFixed response shape per endpointClient specifies exact fieldsStrongly typed protobuf messages
Over/under-fetchingCommon problemSolved by designMinimal — schema is explicit
CachingNative HTTP caching (ETags, Cache-Control)Requires custom cachingNo built-in HTTP caching
Real-timePolling or WebSocketsSubscriptions (built-in)Bidirectional streaming
ToolingMature — OpenAPI, Postman, curlGrowing — Apollo, Relay, GraphiQLMature — protoc, grpcurl, Buf
Learning curveLowMediumMedium-High
VersioningURL or header versioningSchema evolution with @deprecatedPackage versioning in .proto

Rule of thumb: Default to REST for public APIs. Use GraphQL when clients need flexible queries across related data. Use gRPC for internal service-to-service communication.


API Checklist

Run through this checklist before marking any API work as complete.

Authentication & Authorization

  • Authentication mechanism chosen (JWT, OAuth2, API key)
  • Authorization rules enforced at every endpoint
  • Tokens validated and scoped correctly
  • Secrets stored securely (never in code or logs)

Rate Limiting

  • Rate limits configured per endpoint or consumer tier
  • RateLimit-* headers included in responses
  • 429 Too Many Requests returned with Retry-After header
  • Rate limit strategy documented for consumers

Pagination

  • All collection endpoints paginated
  • Pagination style chosen (cursor-based or offset-based)
  • page_size bounded with a sensible maximum
  • Total count or hasNextPage indicator included

Filtering & Sorting

  • Filter parameters validated and sanitized
  • Sort fields allow-listed (no arbitrary column sorting)
  • Default sort order defined and documented

Error Handling

  • Consistent error response schema across all endpoints
  • Correct HTTP status codes (4xx for client, 5xx for server)
  • Validation errors return field-level detail
  • Internal errors never leak stack traces or sensitive data

Versioning

  • Versioning strategy selected and applied uniformly
  • Breaking vs non-breaking change policy documented
  • Deprecation timeline communicated via Sunset header

CORS

  • Allowed origins configured (no wildcard * in production with credentials)
  • Allowed methods and headers explicitly listed
  • Preflight (OPTIONS) requests handled correctly

Documentation

  • OpenAPI / Swagger spec generated and up to date
  • Every endpoint has description, parameters, and example responses
  • Authentication requirements documented
  • Error codes and meanings listed
  • Changelog maintained for each version

Security

  • Input validation on all fields
  • SQL injection prevention
  • HTTPS enforced
  • Sensitive data never in URLs or logs
  • CORS configured correctly

Monitoring

  • Structured logging with request IDs
  • Error tracking configured (Sentry, Datadog, etc.)
  • Performance metrics collected (latency, error rate)
  • Health check endpoint available (/health)
  • Alerts configured for error rate spikes

Skill Routing Table

NeedSkillPurpose
API design principlesapi-designResource modeling, HTTP semantics, pagination, error formats
Versioning strategyapi-versioningVersion lifecycle, deprecation, migration patterns
Authenticationauth-patternsJWT, OAuth2, sessions, RBAC, MFA
Error handlingerror-handlingError types, retry patterns, circuit breakers, HTTP errors
Rate limitingrate-limitingAlgorithms, HTTP headers, tiered limits, distributed limiting
CachingcachingCache strategies, HTTP caching, invalidation, Redis patterns
Database migrationsdatabase-migrationsSchema evolution, zero-downtime patterns, rollback strategies

NEVER Do

  1. NEVER skip the design phase — jumping straight to code produces inconsistent APIs that are expensive to fix
  2. NEVER expose database schema directly — API resources are not database tables; design around consumer use cases
  3. NEVER ship without authentication — every production endpoint must have an auth strategy
  4. NEVER return inconsistent error formats — every error response must follow the same schema
  5. NEVER break a published API without a versioning plan — breaking changes require a new version, migration guide, and deprecation timeline
  6. NEVER deploy without tests and documentation — untested APIs ship bugs, undocumented APIs frustrate developers

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.