api-contract
Skill3 starsChanged 4 months agoMITView on GitHub
Generate OpenAPI specs from code, validate API contracts, and check for breaking changes between versions.
- Installs packages
14 other projects use a version of this.
Adopted by
Most recently taken up by
- jDxve/avengers-kittheir own version, first seen Nov 8, 2026
- Echo-Scion/orioncortextheir own version, first seen Nov 8, 2026
- Eliahhango/nullbyte-securitytheir own version, first seen Nov 1, 2026
- Echo-Scion/portable-brainvibingtheir own version, first seen Oct 15, 2026
- ChenyCHENYU/Robot_Admintheir own version, first seen Oct 8, 2026
- gonimar/claude-web-studiotheir own version, first seen Sep 27, 2026
Used with
Projects with it also use design-system.
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.
AnthropicSkilldesign-system
Audit, document, or extend your design system. Use when checking for naming inconsistencies or hardcoded values across components, writing documentation for a component's variants, states, and accessibility notes, or designing a new pattern that fits the existing system.
Also in 3 projects that use this
Other versions14 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 14
- ChenyCHENYU/Robot_Admin★ 1ksame name
- Eliahhango/nullbyte-security★ 4same name
- gonimar/claude-web-studio★ 4same name
- digitaldreams/tuhin★ 3same name
- vndee/engineering-skills★ 3same name
- 1398281322-a11y/java-backend-guardrails★ 2same name
- Echo-Scion/orioncortex★ 2same name
- Echo-Scion/portable-brainvibing★ 2same name
- njt2810/claude-code-framework★ 1same name
- YouRen1320/agent-project-kit★ 1same name
4 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository67 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- optimize-contextSkill
- a11y-checkSkill
- backend-patternsSkill
- build-fixSkill
- checkpointSkill
- clickhouse-ioSkill
- code-review-eccSkill
- code-reviewSkill
- coding-standardsSkill
- config-auditSkill
- continuous-learning-v2Skill
- create-prdSkill
- deps-auditSkill
- e2eSkill
- eval-harnessSkill
- evalSkill
- evolveSkill
- executeSkill
- execution-reportSkill
- extract-sharedSkill
- firecrawlSkill
- frontend-designSkill
- frontend-patternsSkill
- golang-patternsSkill
- golang-testingSkill
- implement-fixSkill
- init-projectSkill
- instinct-exportSkill
- instinct-importSkill
- instinct-statusSkill
- iterative-retrievalSkill
- lazySkill
- learnSkill
- orchestrateSkill
- perf-profileSkill
- plan-eccSkill
- plan-featureSkill
- postgres-patternsSkill
- primeSkill
- project-guidelines-exampleSkill
- projectSkill
- prompt-auditSkill
- python-patternsSkill
- python-reviewSkill
- python-testingSkill
- rcaSkill
- refactor-cleanSkill
- releaseSkill
- security-reviewSkill
- seo-kitSkill
- set-working-dirSkill
- skill-createSkill
- strategic-compactSkill
- supadataSkill
- system-reviewSkill
- tddSkill
- tdd-workflowSkill
- test-coverageSkill
- testSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 5 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 12 edited versions we read keep these.
5
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 28
--breaking: Check for breaking changes between current code and last tagged version - Very specific: line 121
Write to openapi.yaml in the project root.
- Distinctive: line 125
If an OpenAPI spec exists, validate the live API against it:
- Distinctive: line 218
If no API routes found: "No API endpoints detected.
- Distinctive: line 219
If app not running (for validation): suggest starting the dev server first
- Distinctive: line 220
If no git tags (for breaking changes): compare against initial commit
- Distinctive: line 221
If OpenAPI spec is outdated: flag it and suggest regeneration
“Common” is measured: kept by at least 6 in 10 of the 12 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.
Files
API Contract Manager
Generate OpenAPI specifications from code, validate API responses against contracts, and detect breaking changes.
Supported Frameworks
Auto-detects the API framework in the current project:
| Framework | API Style | Route Discovery |
| FastAPI | REST | Auto-generated OpenAPI at /docs and /openapi.json |
| Flask | REST | Blueprint / app route decorators |
| Express | REST | Manual router/app route definitions |
Arguments
Parse $ARGUMENTS:
--endpoints: List all API endpoints in the current project (default)--generate: Generate or update an OpenAPI spec from code--validate: Validate API responses against the spec--breaking: Check for breaking changes between current code and last tagged version--diff: Show API changes since last commit/tag
Process
Mode 1: Endpoint Discovery (--endpoints)
Scan the current project for all API endpoints:
FastAPI:
# Find all router files
grep -rn "@router\.\(get\|post\|put\|delete\|patch\)" --include="*.py" <path> | sed 's/.*@router\.//' | sed 's/(.*//' | sort
# Also check app-level routes
grep -rn "@app\.\(get\|post\|put\|delete\|patch\)" --include="*.py" <path> | head -20
# Find router registrations
grep -rn "include_router\|add_api_route" --include="*.py" <path> | head -20Flask:
# Blueprint routes
grep -rn "@.*\.route\|@.*\.add_url_rule" --include="*.py" <path> | head -30
# Also check app-level
grep -rn "@app\.route" --include="*.py" <path> | head -20Express:
# Router definitions
grep -rn "router\.\(get\|post\|put\|delete\|patch\)\|app\.\(get\|post\|put\|delete\|patch\)" --include="*.ts" --include="*.js" <path> | grep -v node_modules | head -30Output:
## API Endpoints: <project-name>
| Method | Path | Handler | File |
|--------|------|---------|------|
| GET | /health | health_check | api/routers/health.py:12 |
| GET | /api/orders | list_orders | api/routers/orders.py:28 |
| POST | /api/orders | create_order | api/routers/orders.py:45 |
| GET | /api/orders/{id} | get_order | api/routers/orders.py:62 |
...
Total: X endpoints (Y GET, Z POST, W PUT, V DELETE)Mode 2: OpenAPI Spec Generation (--generate)
FastAPI projects (auto-generated): FastAPI auto-generates OpenAPI at runtime. Extract it:
# If the app is running locally
curl -s http://localhost:8000/openapi.json 2>/dev/null | python3 -m json.tool > openapi.json
# If not running, check for existing spec
test -f <path>/openapi.json && echo "Spec exists" || echo "No spec file"Flask/Express projects (manual generation): Scan route definitions and generate a spec skeleton:
- Collect all endpoints from Mode 1
- For each endpoint, check for:
- Request body schemas (Pydantic models, Zod schemas, JSON validation)
- Response types (return type hints, response models)
- Path parameters
- Query parameters
- Authentication requirements (decorators, middleware)
- Generate an OpenAPI 3.0 YAML skeleton:
openapi: "3.0.3"
info:
title: <project-name> API
version: <from-manifest>
paths:
/health:
get:
summary: Health check
responses:
"200":
description: Service healthy
/api/orders:
get:
summary: List orders
parameters: []
responses:
"200":
description: Order listWrite to openapi.yaml in the project root.
Mode 3: Contract Validation (--validate)
If an OpenAPI spec exists, validate the live API against it:
# Check if the spec exists
test -f openapi.json -o -f openapi.yaml
# For each endpoint in the spec, make a test request and verify:
# 1. Status code matches expected
# 2. Response content-type matches
# 3. Required fields are presentFor FastAPI, the built-in /docs endpoint validates interactively. Suggest:
FastAPI projects self-validate via /docs (Swagger UI) and /redoc.
For automated validation:
pip install schemathesis
schemathesis run http://localhost:8000/openapi.jsonMode 4: Breaking Change Detection (--breaking)
Compare current API surface with the last tagged version:
# Get the last tag
LAST_TAG=$(git describe --tags --abbrev=0 2>/dev/null)
# Check out the old version's routes to a temp comparison
git show $LAST_TAG:path/to/routes.py 2>/dev/null > /tmp/old_routes.py
# Compare endpoint lists
# Current endpoints
grep -rn "@router\." --include="*.py" <path> | sed 's/.*@router\.//' > /tmp/current_endpoints.txt
# Old endpoints (from tag)
git show $LAST_TAG -- $(git ls-files '*.py' | grep -E 'route|router|api') 2>/dev/null | grep "@router\." | sed 's/.*@router\.//' > /tmp/old_endpoints.txt
# Diff
diff /tmp/old_endpoints.txt /tmp/current_endpoints.txtClassify changes:
- Breaking: Removed endpoints, changed required parameters, narrowed response types
- Non-breaking: Added endpoints, added optional parameters, expanded response types
- Potentially breaking: Changed parameter types, renamed fields
Output:
## Breaking Change Analysis: v1.2.1 -> current
### Breaking Changes (0)
None detected.
### Non-Breaking Changes (3)
- ADDED: GET /api/reports/shipping
- ADDED: POST /api/verification/complete
- ADDED: GET /api/schedule/import
### Potentially Breaking (1)
- MODIFIED: POST /api/orders — new required field `shipping_method`
Safe to deploy: YES/NOMode 5: API Diff (--diff)
Show API surface changes since last commit:
# Files that define routes
ROUTE_FILES=$(git diff --name-only HEAD~1 | grep -E "route|router|api|endpoint" | head -20)
# For each changed file, show the route changes
for f in $ROUTE_FILES; do
echo "=== $f ==="
git diff HEAD~1 -- "$f" | grep -E "^\+.*@(router|app)\.(get|post|put|delete)|^\-.*@(router|app)\.(get|post|put|delete)"
doneReport
## API Contract Report: <project-name>
Endpoints: X total (Y GET, Z POST, W PUT, V DELETE)
OpenAPI spec: [exists/missing]
Last breaking change: [tag/date]
Contract health: [VALID/NEEDS_UPDATE/NO_SPEC]Error Handling
- If no API routes found: "No API endpoints detected. Is this an API project?"
- If app not running (for validation): suggest starting the dev server first
- If no git tags (for breaking changes): compare against initial commit
- If OpenAPI spec is outdated: flag it and suggest regeneration
Notes
- FastAPI projects get the most value since OpenAPI is auto-generated
- Flask/Express spec generation produces skeletons that need manual refinement
- Breaking change detection is heuristic — it catches route-level changes but not schema changes
- For full contract testing, recommend
schemathesis(Python) ordredd(Node) - This skill is read-only for analysis;
--generatewrites an openapi.yaml skeleton only
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
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.

