Review an API's contract as a promise to consumers — detects breaking changes by diffing the before/after surface (removed/renamed fields, type changes, tightened requiredness, status-code changes), and judges design by the repo's OWN precedent (error envelope, naming, pagination, auth placement) with every consistency finding citing the in-repo convention being violated. Covers versioning, idempotency on retryable writes, pagination on collections, and status-code semantics. Use this skill whenever the user says "review this API", "review the endpoint", "API design review", "is this a breaking change", "check backward compatibility", "review the contract", "review this OpenAPI/swagger spec", or "/api-contract-review" — even if they don't name the skill. Distinct from code-review (implementation quality); this reviews the SURFACE consumers depend on.
Coding
Api Change Review
Try itReview an API change for compatibility, validation, auth, error shape, idempotency, and observability, and classify it as additive, behavior-changing, or bre...
What it does
Review an API change for compatibility, validation, auth, error shape, idempotency, and observability, and classify it as additive, behavior-changing, or breaking.
The skill document
API change review
A standalone development skill. Review an API change for compatibility, validation, auth, error shape, idempotency, and observability, and classify it as additive, behavior-changing, or breaking. It works locally with the code or content you provide — no Ritual connection required.
Run it (local, no setup)
Work the steps below; you need nothing beyond the task in front of you.
- Identify the contract surface: request, response, auth, errors, side effects, and compatibility expectations.
- Classify the change as additive, behavior-changing, breaking, or ambiguous.
- Review input validation/schema evolution, authorization and tenant/data boundaries, error-shape consistency, idempotency/retry, and observability.
- Assess backward compatibility and the migration plan.
- Prefer the smallest safe contract change; avoid speculative versioning or framework rewrites.
- Define verification: unit, contract, integration tests, and rollout checks.
Done when: A contract verdict (safe / risky / breaking / unclear), required changes, compatibility risks, a minimal test plan, and rollout notes.
Example prompt
Use api-change-review on this diff: classify the change, flag breaking behavior and the callers it affects, and give me a migration + rollout plan with the tests to add.
Working principles
Apply these throughout:
- Think before you edit — restate the task and the success criteria, and name any load-bearing assumption rather than silently guessing it.
- Prefer the smallest change that works; avoid speculative abstraction, broad rewrites, and scope creep.
- Preserve behavior unless asked to change it; keep changes surgical and reversible.
- Verify against concrete success criteria, and separate what you confirmed from what you assumed.
- Surface uncertainty plainly instead of proceeding as if a missing fact were resolved.
Optional knowledge capture
After the task, check whether the work revealed reusable knowledge — something a future agent would otherwise rediscover. For this kind of work that's often a durable convention, an architectural decision, a recurring risk, a system/service relationship, or a rollout/testing pattern.
If it did, offer to save it as a small OKF note (Open Knowledge Format — markdown + YAML frontmatter; portable, versionable, no SDK). Never write a file without the user's approval. Keep it small and cite the file(s) or evidence.
When approved, write knowledge/engineering/.md:
---
type: API Convention
title:
description:
resource: ./path/to/file-or-evidence
tags: [..]
timestamp:
---
# Summary
# Applies to
# Evidence
# Use in future agent work
These notes make the repo itself smarter over time, and a tool like Ritual can later reason over them as a structured knowledge layer.
Optional Ritual Cloud upgrade
This skill works locally with the context you provide — that's standalone mode. Upgrade with Ritual Cloud when the task needs deeper workspace context, structured exploration, recommendations, or team alignment:
- More context (discovery) — when the answer depends on things outside the files in front of you:
- the review needs all known clients/callers of the endpoint
- prior API conventions or related migrations/feature flags apply
- there are production incidents connected to this endpoint
- A structured decision (exploration) — when the work has become a decision to get right:
- a breaking change needs a rollout decision across teams
- the migration path is contested and needs a recommendation owners align on
Ritual turns the task into an exploration — clarify the problem, identify the key questions, gather evidence, compare options, and produce a recommendation or decision-ready artifact.
For this task: an API migration recommendation with affected callers, rollout options, compatibility risks, and a decision-ready summary.
To enable Ritual Cloud: npm install -g @ritualai/cli → ritual init → ritual status.
This skill is local-first and self-contained. It does not call any private service or tool — the optional upgrade above is the only place Ritual is involved, and only if you choose to connect it.
Related skills
Audit failure states, retries, validation, and idempotency in the code under review.
Evaluates API surface design, consistency, and exemplar alignment
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technic...
Review messy specs, policies, and handoff notes with source-linked findings instead of vague rewrite advice.
End-to-end GitHub PR review with inline diff comments, severity-grouped findings, and a merge recommendation.