| name | api-review |
| role | library |
| description | Evaluates API surface design, consistency, and exemplar alignment. Use when reviewing public API changes or before releasing a new API surface. |
| alwaysApply | false |
| category | code-review |
| tags | ["api","design","consistency","documentation","versioning"] |
| tools | [] |
| usage_patterns | ["api-design-review","consistency-audit","documentation-governance"] |
| complexity | intermediate |
| model_hint | standard |
| estimated_tokens | 400 |
| progressive_loading | true |
| dependencies | ["imbue:proof-of-work","imbue:review-core","imbue:structured-output"] |
| modules | ["modules/consistency-audit.md","modules/exemplar-research.md","modules/surface-inventory.md"] |
API Review Workflow
When NOT To Use
- Internal refactors behind a stable surface (use
pensive:code-refinement)
- Coupling and layering questions (use
pensive:architecture-review)
Table of Contents
- Usage
- Required Progress Tracking
- Workflow
Usage
Use this skill to review public API changes, design new surfaces, audit consistency, and validate documentation completeness. Run it before any API release to confirm alignment with project guidelines.
Required Progress Tracking
api-review:surface-inventoryapi-review:exemplar-researchapi-review:consistency-auditapi-review:docs-governanceapi-review:evidence-logapi-review:findings-verified
Workflow
Step 1: Surface Inventory
Catalog all public APIs by language. Record stability levels, feature flags, and versioning metadata. Use tools like rg to find public symbols (e.g., pub in Rust or non-underscored def in Python). Confirm the working tree state with git status before starting.
Step 2: Exemplar Research
Identify at least two high-quality API references for the relevant language, such as pandas, requests, or tokio. Document their patterns for namespacing, pagination, error handling, and structure to serve as a baseline for the audit.
Step 3: Consistency Audit
Compare the project's API against the identified exemplar patterns. Analyze naming conventions, parameter ordering, return types, and error semantics. Identify duplication, leaky abstractions, missing feature gates, and documentation gaps.
Step 4: Documentation Governance
Validate that documentation includes entry points, quickstarts, and a complete API reference. Verify that changelogs and migration notes are maintained. Check for SemVer compliance, stability promises, and clear deprecation timelines. Confirm that documentation is generated automatically using tools like rustdoc, Sphinx, or OpenAPI.
Step 5: Evidence Log
Record all executed commands and findings. Summarize the final recommendation as Approve, Approve with actions, or Block. Include specific action items with assigned owners and due dates.
API Quality Checklist
