agent-api-contract-designer

Designs contract-first OpenAPI platform APIs with versioning, error taxonomies, and STRIDE threat modeling for agent consumers.

Updated Jul 16, 2026
One-click install
npx skills add https://github.com/Cloud-Byte-Consulting/plugins --skill agent-api-contract-designer-cloud-byte-consulting
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: agent-api-contract-designer
Source: https://github.com/Cloud-Byte-Consulting/plugins/tree/main/adp-enablement/skills/agent-api-contract-designer
Command: npx skills add https://github.com/Cloud-Byte-Consulting/plugins --skill agent-api-contract-designer-cloud-byte-consulting

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? AI agents are high-volume, low-judgment API consumers that retry aggressively, follow documentation literally, and propagate ambiguity into action, so platform APIs designed for human developers fail them constantly. This Skill produces agent-consumable API contracts that are explicit, versioned, recoverable, and threat-modeled with the agent treated as an untrusted caller. ## Core Features & Use Cases - Contract-first OpenAPI design: Strict schemas, enums, idempotency keys, and machine-readable error-code taxonomies with retryability classes, scored against the Richardson maturity ladder (L2 minimum). - Versioning and consumer-driven contracts: Expansion-only changes, semver policy, side-by-side majors with deprecation windows, and Pact-style consumer-driven tests wired into provider CI as fitness functions. - Security for agent callers: STRIDE-per-element threat modeling over the API data-flow diagram plus a seven-point API checklist adapted to prompt-injected or compromised agents, with OAuth2 client credentials over static API keys and per-agent-class BFF facades. - Use Case: A platform team exposing GPU job and dataset APIs to an experiment-runner agent uses this Skill to score existing endpoints, design the BFF contract, define the error taxonomy, and produce a threat-model table before the MCP tool layer is built on top. ## Quick Start Use the agent-api-contract-designer skill to review our platform's job submission API and produce a contract pack with an OpenAPI spec, error taxonomy, versioning policy, and threat model.

Frequently Asked Questions about agent-api-contract-designer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design APIs that AI agents can consume reliably?

Write the OpenAPI contract before implementation with strict typed schemas, enums, and idempotency keys on all mutating endpoints. Target Richardson maturity level 2 so agents can infer retry-safety from HTTP verbs and status codes, and publish a machine-readable error taxonomy with retryability classes.

How to version APIs without breaking agent consumers?

Allow only expansion changes within a major version: add endpoints, optional fields, and enum values, but never rename, remove, or retype. Semver the contract, run majors side by side with deprecation windows and sunset headers, and document tolerant-reader obligations for consumers.

OAuth2 vs API keys for machine-to-machine API authentication?

OAuth2 client credentials are preferred for machine-to-machine calls because they are scoped, short-lived, and attributable. Static API keys are unscoped, unexpiring, and unattributable, acceptable only for low-risk read-only telemetry at most.

What are consumer-driven contract tests for platform APIs?

Consumer-driven contracts are executable expectations each consumer class contributes describing the fields and behaviors it relies on. The provider's CI runs all of them on every change, turning potential breaking changes into build failures rather than review-time guesses.

Why treat AI agents as untrusted API callers in threat modeling?

Agents may be prompt-injected, running compromised models, or fed poisoned context, so their requests are attacker input with valid credentials. The skill applies STRIDE-per-element over the data-flow diagram plus a seven-point checklist covering server-side revalidation, TOCTOU, non-leaking errors, and per-identity quotas.

When should I use a backend-for-frontend pattern for agent APIs?

Create a BFF per consumer class when different consumers genuinely need different payloads, scopes, and rate limits, such as an experiment-runner agent versus a human portal. Each BFF trims payloads to that class's needs and versions independently, but avoid multiplying BFFs beyond real consumer classes.