For Agents · MCP

Your task.
The right skill.

The tunnel uses the same cards as the catalogue. Browse only as deep as needed — or load a broad bundle immediately.

No local installationNo M11 loginRead-only

Broad task

Load 5–10 and go

SEO, Sales, Agents or another broad area → one bundle call → work.

MCP endpoint: https://skills.m11.ch/mcp

Read-only access to published skills. Default 8, maximum 10 skills / 120,000 characters.

Task Packs

Marketing Foundation

Compact two-skill starter: clarify positioning and choose a lead magnet. Use Marketing Launch for the broader eight-skill go-to-market workflow.

Marketing Launch

Build an evidence-led marketing plan from ICP and competition through positioning, campaigns, growth and measurement.

Agent Audit Essentials

Diagnose architecture and context, plan agent-team responsibilities, then organize project context and session handoffs. Memory and cost-runtime reviews remain outside this pack.

Conversion and Activation Review

Review the journey from landing page and lead capture through registration, first value and transparent upgrades.

Campaign Content and Brand Review

Plan a campaign, draft its channel content and review the work against actual brand guidance.

Content and Launch Planning

Prioritize an editorial roadmap and plan how to launch and distribute it across suitable channels.

Customer, Market and Community Research

Understand customer needs, compare competitors and plan a community around real member value.

Lead Magnet to Lifecycle Nurture

Choose a relevant lead magnet, then draft a permission-based nurture journey with entry, suppression and exit rules.

API Contract and Observability

Define the API contract, then plan how to observe its latency, failures and retries. Guidance and checklist; no production changes.

Data Analysis Foundation

Profile a dataset, choose and interpret statistical methods, then validate calculations and conclusions before sharing.

Choose an area

01 · Category

What the MCP returns at this step

01 · Development · API Contracts

API Contracts and Interface Design

Define API contracts, pagination, error semantics and safe retry behavior; choose this for interface design, then Observability for evidence of runtime behavior.

apiinterfacecontractidempotencypaginationvalidationschnittstellenvertragschnittstellendesignidempotenzapi-entwurf

API Contracts and Interface Design · Original SKILL.md

---
name: api-and-interface-design
description: Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.
---

# API and Interface Design

## Overview

Design stable, well-documented interfaces that are hard to misuse. Good interfaces make the right thing easy and the wrong thing hard. This applies to REST APIs, GraphQL schemas, module boundaries, component props, and any surface where one piece of code talks to another.

## When to Use

- Designing new API endpoints
- Defining module boundaries or contracts between teams
- Creating component prop interfaces
- Establishing database schema that informs API shape
- Changing existing public interfaces

## Core Principles

### Hyrum's Law

> With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody, regardless of what you promise in the contract.

This means: every public behavior — including undocumented quirks, error message text, timing, and ordering — becomes a de facto contract once users depend on it. Design implications:

- **Be intentional about what you expose.** Every observable behavior is a potential commitment.
- **Don't leak implementation details.** If users can observe it, they will depend on it.
- **Plan for deprecation at design time.** See `deprecation-and-migration` for how to safely remove things users depend on.
- **Tests are not enough.** Even with perfect contract tests, Hyrum's Law means "safe" changes can break real users who depend on undocumented behavior.

### The One-Version Rule

Avoid forcing consumers to choose between multiple versions of the same dependency or API. Diamond dependency problems arise when different consumers need different versions of the same thing. Design for a world where only one version exists at a time — extend rather than fork.

### 1. Contract First

Define the interface before implementing it. The contract is the spec — implementation follows.

```typescript
// Define the contract first
interface TaskAPI {
  // Creates a task and returns the created task with server-generated fields
  createTask(input: CreateTaskInput): Promise<Task>;

  // Returns paginated tasks matching filters
  listTasks(params: ListTasksParams): Promise<PaginatedResult<Task>>;

  // Returns a single task or throws NotFoundError
  getTask(id: string): Promise<Task>;

  // Partial update — only provided fields change
  updateTask(id: string, input: UpdateTaskInput): Promise<Task>;

  // Idempotent delete — succeeds even if already deleted
  deleteTask(id: string): Promise<void>;
}
```

### 2. Consistent Error Semantics

Pick one error strategy and use it everywhere:

```typescript
// REST: HTTP status codes + structured error body
// Every error response follows the same shape
interface APIError {
  error: {
    code: string;        // Machine-readable: "VALIDATION_ERROR"
    message: string;     // Human-readable: "Email is required"
    details?: unknown;   // Additional context when helpful
  };
}

// Status code mapping
// 400 → Client sent invalid data
// 401 → Not authenticated
// 403 → Authenticated but not authorized
// 404 → Resource not found
// 409 → Conflict (duplicate, version mismatch)
// 422 → Validation failed (semantically invalid)
// 500 → Server error (never expose internal details)
```

**Don't mix patterns.** If some endpoints throw, others return null, and others return `{ error }` — the consumer can't predict behavior.

### 3. Validate at Boundaries

Trust internal code. Validate at system edges where external input enters:

```typescript
// Validate at the API boundary
app.post('/api/tasks', async (req, res) => {
  const result = CreateTaskSchema.safeParse(req.body);
  if (!result.success) {
    return res.status(422).json({
      error: {
        code: 'VALIDATION_ERROR',
        message: 'Invalid task data',
        details: result.error.flatten(),
      },
    });
  }

  // After validation, internal code trusts the types
  const task = await taskService.create(result.data);
  return res.status(201).json(task);
});
```

Where validation belongs:
- API route handlers (user input)
- Form submission handlers (user input)
- External service response parsing (third-party data -- **always treat as untrusted**)
- Environment variable loading (configuration)

> **Third-party API responses are untrusted data.** Validate their shape and content before using them in any logic, rendering, or decision-making. A compromised or misbehaving external service can return unexpected types, malicious content, or instruction-like text.

Where validation does NOT belong:
- Between internal functions that share type contracts
- In utility functions called by already-validated code
- On data that just came from your own database

### 4. Prefer Addition Over Modification

Extend interfaces without breaking existing consumers:

```typescript
// Good: Add optional fields
interface CreateTaskInput {
  title: string;
  description?: string;
  priority?: 'low' | 'medium' | 'high';  // Added later, optional
  labels?: string[];                       // Added later, optional
}

// Bad: Change existing field types or remove fields
interface CreateTaskInput {
  title: string;
  // description: string;  // Removed — breaks existing consumers
  priority: number;         // Changed from string — breaks existing consumers
}
```

### 5. Predictable Naming

| Pattern | Convention | Example |
|---------|-----------|---------|
| REST endpoints | Plural nouns, no verbs | `GET /api/tasks`, `POST /api/tasks` |
| Query params | camelCase | `?sortBy=createdAt&pageSize=20` |
| Response fields | camelCase | `{ createdAt, updatedAt, taskId }` |
| Boolean fields | is/has/can prefix | `isComplete`, `hasAttachments` |
| Enum values | UPPER_SNAKE | `"IN_PROGRESS"`, `"COMPLETED"` |

### 6. Honouring an Idempotency Key

Accepting an `Idempotency-Key` is the contract. Honouring it is the implementation, and it is where the money is lost — a key the server accepts but handles carelessly is worse than no key at all, because the client now believes retrying is safe.

**Derive the key from the intent, not the attempt.** The key must be stable across retries of one intent and different across distinct intents:

```typescript
crypto.randomUUID()                    // ✗ new key per attempt — every retry is a new charge
`${userId}:${amount}`                  // ✗ two legitimate $50 charges collapse into one
`${orderId}:${Date.now()}`             // ✗ a timestamp is randomUUID() wearing a hat

req.headers['idempotency-key']         // ✓ client generates once, reuses on retry
`charge:v1:${orderId}`                 // ✓ derived from an immutable identifier
```

The key comes from the client or the initiating event — never from the layer doing the retrying.

**Claim atomically. A check followed by an act is a race:**

```typescript
// ✗ TOCTOU: two concurrent retries both read "not seen", both charge
if (!(await db.exists(key))) {
  await chargeCard(amount);
  await db.insert(key);
}

// ✓ let the unique constraint pick the winner
try {
  await db.insert({ key, state: 'in_progress', requestHash });
} catch (e) {
  if (isUniqueViolation(e)) return replayOrReject(key);
  throw;
}
const result = await chargeCard(amount);
await db.update({ key, state: 'succeeded', response: result });
```

The unique constraint *is* the mechanism. A store that cannot enforce uniqueness in one operation cannot back this.

**Guard the payload.** Same key with a different body is a client bug, and must fail loudly rather than serving the first response to a second request:

```typescript
if (existing.requestHash !== hash(req.body)) {
  return res.status(422).json({ error: 'idempotency key reused with a different payload' });
}
```

**Decide what an in-flight duplicate gets.** The first request is still running when the second arrives — the common case under retry storms:

| Strategy | Response | Use when |
|---|---|---|
| Reject | `409 Conflict` | Client can retry later; simplest and safest |
| Wait | Block for the result, bounded | Caller needs it synchronously |
| Return pending | `202` + status URL | Long-running effects |

Never let the second caller through because the first "seems stuck". A stalled attempt whose fate is unknown is exactly when duplicating costs most.

**Every call has three outcomes, not two: success, failure, and _unknown_.** A timeout tells you nothing about whether the effect applied. Record the intent *before* calling out, so a crash between the call and the response leaves evidence something must resolve later — rather than a silently retried charge.

**Set retention from the longest retry chain**, not from disk cost. Keys must outlive every path that can re-deliver the same intent, including a dead-letter queue replayed a week later and any provider dispute window. A 24-hour key TTL behind a 7-day DLQ is a duplicate waiting to happen.

## REST API Patterns

### Resource Design

```
GET    /api/tasks              → List tasks (with query params for filtering)
POST   /api/tasks              → Create a task
GET    /api/tasks/:id          → Get a single task
PATCH  /api/tasks/:id          → Update a task (partial)
DELETE /api/tasks/:id          → Delete a task

GET    /api/tasks/:id/comments → List comments for a task (sub-resource)
POST   /api/tasks/:id/comments → Add a comment to a task
```

### Pagination

Paginate list endpoints:

```typescript
// Request
GET /api/tasks?page=1&pageSize=20&sortBy=createdAt&sortOrder=desc

// Response
{
  "data": [...],
  "pagination": {
    "page": 1,
    "pageSize": 20,
    "totalItems": 142,
    "totalPages": 8
  }
}
```

### Filtering

Use query parameters for filters:

```
GET /api/tasks?status=in_progress&assignee=user123&createdAfter=2025-01-01
```

### Partial Updates (PATCH)

Accept partial objects — only update what's provided:

```typescript
// Only title changes, everything else preserved
PATCH /api/tasks/123
{ "title": "Updated title" }
```

## TypeScript Interface Patterns

### Use Discriminated Unions for Variants

```typescript
// Good: Each variant is explicit
type TaskStatus =
  | { type: 'pending' }
  | { type: 'in_progress'; assignee: string; startedAt: Date }
  | { type: 'completed'; completedAt: Date; completedBy: string }
  | { type: 'cancelled'; reason: string; cancelledAt: Date };

// Consumer gets type narrowing
function getStatusLabel(status: TaskStatus): string {
  switch (status.type) {
    case 'pending': return 'Pending';
    case 'in_progress': return `In progress (${status.assignee})`;
    case 'completed': return `Done on ${status.completedAt}`;
    case 'cancelled': return `Cancelled: ${status.reason}`;
  }
}
```

### Input/Output Separation

```typescript
// Input: what the caller provides
interface CreateTaskInput {
  title: string;
  description?: string;
}

// Output: what the system returns (includes server-generated fields)
interface Task {
  id: string;
  title: string;
  description: string | null;
  createdAt: Date;
  updatedAt: Date;
  createdBy: string;
}
```

### Use Branded Types for IDs

```typescript
type TaskId = string & { readonly __brand: 'TaskId' };
type UserId = string & { readonly __brand: 'UserId' };

// Prevents accidentally passing a UserId where a TaskId is expected
function getTask(id: TaskId): Promise<Task> { ... }
```

## Common Rationalizations

| Rationalization | Reality |
|---|---|
| "We'll document the API later" | The types ARE the documentation. Define them first. |
| "We don't need pagination for now" | You will the moment someone has 100+ items. Add it from the start. |
| "PATCH is complicated, let's just use PUT" | PUT requires the full object every time. PATCH is what clients actually want. |
| "We'll version the API when we need to" | Breaking changes without versioning break consumers. Design for extension from the start. |
| "Nobody uses that undocumented behavior" | Hyrum's Law: if it's observable, somebody depends on it. Treat every public behavior as a commitment. |
| "We can just maintain two versions" | Multiple versions multiply maintenance cost and create diamond dependency problems. Prefer the One-Version Rule. |
| "Internal APIs don't need contracts" | Internal consumers are still consumers. Contracts prevent coupling and enable parallel work. |
| "Accepting the Idempotency-Key header is enough" | The header is the contract; storing the key against the result is the implementation. A key you accept but don't honour tells the client retrying is safe when it isn't. |
| "Our queue guarantees exactly-once delivery" | No queue does across a consumer crash — the broker's ack and your side effect are not in one transaction. Design for at-least-once with idempotent processing. |
| "Duplicate requests are rare" | They're *correlated*. Retries spike exactly when a dependency is degraded — the moment duplicates are most likely and most expensive. |

## Red Flags

- Endpoints that return different shapes depending on conditions
- Inconsistent error formats across endpoints
- Validation scattered throughout internal code instead of at boundaries
- Breaking changes to existing fields (type changes, removals)
- List endpoints without pagination
- Verbs in REST URLs (`/api/createTask`, `/api/getUsers`)
- Third-party API responses used without validation or sanitization
- A `SELECT` for an idempotency key followed by an `INSERT` — that's a race, not a guard
- An idempotency key derived from a UUID, timestamp, or anything else regenerated per attempt
- The same key accepted with a different request body, silently returning the first response
- A key retention window shorter than the longest path that can re-deliver the request

## Verification

After designing an API:

- [ ] Every endpoint has typed input and output schemas
- [ ] Error responses follow a single consistent format
- [ ] Validation happens at system boundaries only
- [ ] List endpoints support pagination
- [ ] New fields are additive and optional (backward compatible)
- [ ] Naming follows consistent conventions across all endpoints
- [ ] API documentation or types are committed alongside the implementation
- [ ] State-changing endpoints either honour an idempotency key or are documented as unsafe to retry
- [ ] The key is claimed in one atomic operation, guarded by a unique constraint
- [ ] A reused key with a different payload fails loudly rather than replaying the wrong response
- [ ] The in-flight-duplicate response is a deliberate choice (409, wait, or 202) rather than whatever falls out
- [ ] Key retention outlives the longest retry path, including dead-letter replay

When to use

Define API contracts, pagination, error semantics and safe retry behavior; choose this for interface design, then Observability for evidence of runtime behavior.

What you get

Input/output contracts, compatible evolution choices, pagination/error semantics and an idempotency test plan.

How it works

Inspect the actual system and constraints, identify invariants and failure cases, draft the design, then define observable acceptance checks.

Requirements

Existing consumers, authentication/tenant model, endpoint requirements, retry paths and the actual stack/version constraints.

Delivery and review notes

This is design guidance with illustrative snippets, not a tested payment or API implementation. Database-origin values and internal typed values are not automatically trustworthy: stored user input, stale schemas and trust-boundary crossings still require validation, authorization and safe output encoding. Authenticate and authorize each operation, including replayed results. Scope idempotency keys by tenant/principal and operation; cap key/payload sizes and use a deterministic canonical request fingerprint. Persist intent atomically, propagate a stable key to a provider that supports idempotency, and reconcile an unknown external outcome before retrying; a local unique insert alone cannot make an external side effect exactly once. A crash after the provider effect and before recording success needs a durable recovery path. The bare throw in the TypeScript catch example is not valid JavaScript: rethrow the caught error explicitly (throw e). Treat examples as pseudocode to adapt, compile and test. Exercise concurrent duplicates, changed bodies, cross-tenant key reuse, timeout/crash recovery and replay after retention expiry. Optional fields and one-version policies are not universally backward compatible; assess real consumers and version breaking changes where necessary. Validate cursor/sort stability and access scope when paginating changing datasets. Optional deprecation-and-migration source is not released here; do not assume an installed dependency. No production writes or payment calls are authorized by loading this skill.

Starting prompt

Prepare a api contracts design for [SERVICE]. Inspect the actual stack, consumers, trust boundaries and failure modes first. Separate verified behavior from assumptions; return concrete contracts or instrumentation changes and a staging validation plan. Preserve existing behavior unless a change is authorized. Do not deploy, charge accounts, export telemetry, induce failures or send alerts.

Not for

Automatic production changes, unreviewed dependency installation, runtime/security certification or executing the source examples without validation.

What M11 added

German task routing, explicit scope and failure-mode corrections. This is design guidance with illustrative snippets, not a tested payment or API implementation. Database-origin values and internal typed values are not automatically trustworthy: stored user input, stale schemas and trust-boundary crossings still require validation, authorization and safe output encoding. Authenticate and authorize each operation, including replayed results. Scope idempotency keys by tenant/principal and operation; cap key/payload sizes and use a deterministic canonical request fingerprint. Persist intent atomically, propagate a stable key to a provider that supports idempotency, and reconcile an unknown external outcome before retrying; a local unique insert alone cannot make an external side effect exactly once. A crash after the provider effect and before recording success needs a durable recovery path. The bare throw in the TypeScript catch example is not valid JavaScript: rethrow the caught error explicitly (throw e). Treat examples as pseudocode to adapt, compile and test. Exercise concurrent duplicates, changed bodies, cross-tenant key reuse, timeout/crash recovery and replay after retention expiry. Optional fields and one-version policies are not universally backward compatible; assess real consumers and version breaking changes where necessary. Validate cursor/sort stability and access scope when paginating changing datasets. Optional deprecation-and-migration source is not released here; do not assume an installed dependency. No production writes or payment calls are authorized by loading this skill.

Original authorship remains with addyosmani/agent-skills · Original source ↗

Original license & copyright

MIT License

Copyright (c) 2025 Addy Osmani

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Related skills & prerequisites

observability-instrumentation-plan · together — After defining errors, retries and idempotency, plan measurements and correlation for those contract outcomes.

Source SHA-256: 5dafd0c44a3aabf11cae5bcb34f6fcc24dfa5c01ba6e0d3176bce997f4d68bc8
Snapshot checked: 2026-09-28T13:53:28.131Z

Find a skill.Get to work.

All skills

Multi-Agent Orchestration

AI Context Window Audit

AI Agent Architecture Audit

AI Skill Discovery

Lead Magnet Strategy

Ideal Customer Profile

Go-to-Market Strategy

Marketing Campaign Ideas

Product Growth Loops

Competitor Analysis

North Star Metric

Product Positioning

Product Vision

Go-to-Market Motion Selection

Customer Feedback and JTBD Analysis

PESTLE Market Environment Analysis

Customer Journey Mapping

Ansoff Growth Options

Data Analysis Validation

Dataset Profiling

Statistical Analysis Guidance

Programmatic SEO Planning

Landing Page and Form Conversion Review

Paywall and Upgrade Planning

Signup and Registration Review

User Onboarding and Activation

Popup and Modal Planning

Email Sequence Copy and Flow

Marketing Campaign Planning

Marketing Content Drafting

Brand Voice and Content Review

Marketing Performance Reporting

Sales Company Research

Company and Contact Enrichment

Website Information Architecture

Content Strategy and Editorial Roadmap

Product Launch Planning

Customer Research and Voice of Customer

Community Growth and Member Experience

Competitor Research Profiles

Roadmap and Release Communication

Lifecycle Email Sequences

API Contracts and Interface Design

Observability and Instrumentation Planning

Agent Context and Session Handoff

Product Discovery Sprint

Deal Quality Scoring

Enrichment Waterfall Design

Customer Retention Playbook

Sales Coaching Practice

Revenue Cohort Analysis

Intent Signal Scoring

Customer Identity Matching

Segment Activation Planning

Sales Call Review

Retention Dashboard Design

Sales Coaching Competencies

Let your chat find the right skill.

Your task.The right skill.

Task Packs

Marketing Foundation

Marketing Launch

Agent Audit Essentials

Conversion and Activation Review

Campaign Content and Brand Review

Content and Launch Planning

Customer, Market and Community Research

Lead Magnet to Lifecycle Nurture

API Contract and Observability

Data Analysis Foundation

Choose an area

API Contracts and Interface Design

When to use

What you get

How it works

Requirements

Delivery and review notes

Not for

Find a skill.
Get to work.

Your task.
The right skill.