REST API

VerifiedSafe

Build production-ready REST APIs with contract-first design, secure auth, robust testing, and deployment runbooks.

Sby Skills Guide Bot
DevelopmentIntermediate
8/6/2026
Claude CodeCursorCodex
#rest-api#api-design#openapi#authentication#deployment

Recommended for

Automated summary

This skill drives an end-to-end workflow for designing, securing, testing, and shipping a REST API, from the OpenAPI contract through to the deployment runbook.

Strengths

  • Enforces a contract-first approach: resources, payload schemas, status codes, and error shapes are defined in OpenAPI before any handler is written.
  • Organizes project memory under ~/rest-api/ with distinct folders for contracts, architecture decisions, test plans, and runbooks.
  • Covers frequently skipped concerns: authentication and resource-level authorization, backward-compatible migrations, pagination, observability, and a pre-release checklist.
  • Ships a modular reference table so only the files relevant to the current task need to be loaded.

Limitations

  • No ready-made code and no framework dependency: the skill stays methodological and does not generate a runnable implementation.
  • Assumes the user accepts the overhead of a formalized workflow (contracts, ADRs, runbooks), which is overkill for a throwaway prototype.
  • Detailed guidance lives in companion files (api-contract.md, auth-and-security.md, etc.) that must be read separately to get the actual rules.
When to use it

Use it when starting a new REST API from scratch or when hardening an existing API before it goes to production.

When not to use it

Avoid it for a disposable script, for GraphQL or gRPC APIs, or when you only want paste-ready implementation code.

Security analysis

Safe
Quality score85/100

The skill provides architectural guidance, design rules, and best practices for building REST APIs. It does not instruct destructive actions, exfiltration, obfuscation, or use of undeclared external tools. It explicitly states no external endpoints are called by default and no secrets are stored automatically. The only file system activity mentioned is local memory under ~/rest-api/.

No concerns found

How this analysis is made

Examples

Design a new API from scratch
I need to build a REST API for a multi-tenant invoicing service. Start with the OpenAPI contract, define the error shapes and pagination, then walk me through auth and the test plan before we write any handlers.
Harden an existing API
Our existing REST API has auth checks scattered inside controllers and no rate limiting. Audit it against the security rules of this skill and propose a plan for resource-level authorization and failure-path handling.
Pre-release readiness gate
We're shipping v2 of our REST API next week. Run the deployment checklist: schema migration backward compatibility, contract validation tests, observability metrics, and the runbook for known failure modes.

name: REST API slug: rest-api version: 1.0.0 homepage: https://clawic.com/skills/rest-api description: Build production-ready REST APIs with contract-first design, secure auth, robust testing, and deployment runbooks. changelog: Initial release with end-to-end REST API build workflow from contract to deployment. metadata: {"clawdbot":{"emoji":"🌐","requires":{"bins":[]},"os":["linux","darwin","win32"]}}

Setup

On first use, read setup.md for integration behavior and memory initialization.

When to Use

Use this skill when the user wants to design, implement, secure, test, and ship a REST API from scratch or harden an existing API for production.

This skill covers contract-first design, endpoint conventions, authentication and authorization, persistence strategy, test plans, observability, and release checklists.

Architecture

Working memory lives in ~/rest-api/. See memory-template.md for structure and status behavior.

~/rest-api/
β”œβ”€β”€ memory.md                     # HOT: active API project context
β”œβ”€β”€ contracts/                    # WARM: OpenAPI specs and compatibility notes
β”œβ”€β”€ decisions/                    # WARM: ADR-style technical decisions
β”œβ”€β”€ tests/                        # WARM: test plans and quality gates
β”œβ”€β”€ operations/                   # WARM: runbooks and incident notes
└── archive/                      # COLD: closed projects and old versions

Quick Reference

Load only what is needed for the current API task.

| Topic | File | |-------|------| | Setup and activation behavior | setup.md | | Memory schema | memory-template.md | | Contract-first design | api-contract.md | | Endpoint conventions and errors | endpoint-design.md | | Auth and API security controls | auth-and-security.md | | Data model and migrations | persistence-and-migrations.md | | Test strategy and telemetry | testing-and-observability.md | | Pre-release readiness gate | deployment-checklist.md |

Core Rules

1. Start From the Contract, Not the Controller

Define resources, payload schemas, status codes, and error shapes in OpenAPI before writing handlers.

If the contract is unclear, implementation speed creates rework and breaks clients.

2. Keep Endpoint Semantics Predictable

Use stable naming, plural resources, and correct HTTP methods. Make idempotent behavior explicit for PUT, DELETE, and retryable POST operations.

Predictable semantics reduce client bugs and support safer retries.

3. Enforce Security by Default

Require authentication on non-public endpoints, apply authorization checks at resource boundary, validate input strictly, and sanitize output.

Never rely on frontend validation as a security control.

4. Design for Failure Paths First

Specify error classes, timeout strategy, rate-limit behavior, and fallback expectations before scaling happy-path code.

APIs fail in production at edges, not in demos.

5. Make Data Changes Backward Compatible

Use additive schema migrations first, backfill data safely, and only remove old fields after client migration windows close.

Breaking database or response changes without rollout planning cause outages.

6. Test Contract, Behavior, and Operations

Cover OpenAPI contract validation, integration tests against real infrastructure, and end-to-end tests for critical user journeys.

Unit tests alone do not prove API reliability.

7. Ship With Observability and Runbooks

Expose request metrics, structured errors, trace identifiers, and health indicators. Document recovery steps for known failure modes.

If an API cannot be observed, it cannot be operated safely.

Common Traps

  • Building endpoints before defining response and error contracts -> incompatible clients and patchwork fixes.
  • Mixing auth, business logic, and transport concerns in handlers -> brittle code and hidden security gaps.
  • Treating pagination and filtering as optional -> unstable list endpoints and expensive queries.
  • Returning inconsistent error bodies across services -> poor client DX and weak automation.
  • Shipping without migration rollback steps -> long incidents when a release fails.

Security & Privacy

Data that leaves your machine:

  • None by default.

Data that stays local:

  • API project context and decisions under ~/rest-api/.

This skill does NOT:

  • Call undeclared external endpoints by default.
  • Store secrets automatically.
  • Modify infrastructure without explicit user instruction.

Related Skills

Install with clawhub install <slug> if user confirms:

  • backend - System design and backend architecture decisions.
  • auth - Authentication, session strategy, and credential safety.
  • http - HTTP protocol details and request-response behavior.
  • api - Third-party API integration references.

Feedback

  • If useful: clawhub star rest-api
  • Stay updated: clawhub sync

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/rest-api-msh3uuay/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/rest-api-msh3uuay' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/rest-api-msh3uuay/download' --output '.skill-downloads/rest-api-msh3uuay/SKILL.md.part' && mv '.skill-downloads/rest-api-msh3uuay/SKILL.md.part' '.skill-downloads/rest-api-msh3uuay/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

Original excerpt: Setup

On first use, read setup.md for integration behavior and memory initialization.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

This file does not provide a usable name/description header for this native procedure. It remains available to download and inspect; use the manual method below.

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/rest-api-msh3uuay/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills