Engineering

API Review Checklist Prompt

Architecture review for the public surface: abstractions that earn their place, dependency direction, seams, and the patterns the codebase already has.

Open in Code Review Prompt Generator

Overview

An API surface is a promise — every exposed type and method is something callers will depend on and you will maintain. This setup reviews a client SDK's public surface under the architecture focus: layer violations, responsibilities in the right modules, abstractions earned by real variation rather than speculation, dependency direction from volatile toward stable, interface seams for testing, and consistency with the codebase's established patterns — with the TypeScript pack watching for any-leaks and assertion-hidden errors at the boundary.

How to use this resource

Review the surface, not the internals

Paste the public types and signatures — the architecture focus judges what callers see and depend on.
Challenge every abstraction

"Earned by real variation, or speculative generality?" — the question that shrinks APIs before they ship.
Hold new code to the old patterns

Consistency findings matter most at the surface: callers learn the API's patterns once and expect them everywhere.

Why This Works

Architecture focus reviews position and responsibility, which surface-level style review misses
The earned-abstraction test prevents the speculative generality that bloats public APIs
Pattern-consistency checks protect the API's learnability — its real usability metric

Best for

Client SDKs and shared libraries with real consumers
Public surfaces about to be frozen by semver
Teams whose API grew endpoint by endpoint without a review

Not for

Writing the API documentation — that's the Markdown Output Builder's api-documentation setup
Reviewing endpoint performance — switch focus to Performance

Use cases

Reviewing an SDK's public surface before the first external release
Catching speculative abstractions before they become permanent API
Checking that new endpoints follow the API's established patterns

FAQ

What does the API review checklist produce?

It reviews the public API surface for architectural soundness and returns findings only — layer violations, unearned abstractions, wrong dependency direction, missing interface seams, pattern breaks, and TypeScript any-leaks or unsafe assertions. Each finding is tagged [CRITICAL], [MAJOR], [MINOR], or [NIT] with the exact line or symbol, grouped critical-first, and it ends in a verdict: APPROVED, APPROVED WITH COMMENTS, or CHANGES REQUIRED.

How do I use this API review checklist with my code?

Paste the TypeScript file's public surface — the exported types and signatures callers depend on — and run the prompt in your own AI tool. It works through the fourteen checklist items but reports only the ones that fail, judging where the code sits in the system rather than rewriting it. Because it reviews only, you decide which findings to act on before you freeze the surface.

Does this replace a security review or a performance test?

No — its focus is architecture: position, responsibility, earned abstractions, and pattern consistency on the public surface. It doesn't run your code, load-test endpoints, or do a dedicated security audit; performance is a separate review you run by switching the focus. Treat the findings and the APPROVED / CHANGES REQUIRED verdict as a structured architecture read, not a guarantee the API is secure or fast.

Customize This Resource

Opens this setup in Code Review Prompt Generator. Generate to get the full review contract — then adjust the focus, scope, language, and style.

Open in Code Review Prompt Generator

Prompt Template

Copy it as-is, or use Open in Code Review Prompt Generator to load it pre-filled and customize it with your own context.

REVIEW OBJECTIVE
Review the public API surface of the client SDK for architectural soundness.
Primary focus: architecture — judge where this code sits in the system, not just what it does.
Review only — report findings; do not rewrite the code.

REVIEW SCOPE
You are reviewing a complete file — judge both the code and the file's structure: imports, ordering, and what this file owns.
Language: TypeScript.

REVIEW CRITERIA
- Layer violations and responsibility placement
- Abstractions: earned by real variation, not speculative
- Dependency direction and interface seams
- Transaction and consistency boundaries
- Consistency with the codebase's established patterns

SEVERITY RULES
- Tag every finding with exactly one severity: [CRITICAL], [MAJOR], [MINOR], or [NIT].
- CRITICAL: must be fixed before merge — bugs, vulnerabilities, data loss.
- MAJOR: should be fixed — real risk or real debt.
- MINOR: worth fixing — small risk or friction.
- NIT: style preference; fixing is optional.
- Severity reflects impact, not effort to fix.

REVIEW CHECKLIST
Work through every item; report only the items that fail:
1. Any layer violations — UI reaching into data access, domain importing infrastructure?
2. Is each responsibility in the right module, or convenient-but-wrong places?
3. Are the abstractions earned by real variation, or speculative generality?
4. Does the dependency direction point from volatile toward stable?
5. Are there interface seams where tests need to substitute behavior?
6. Is wiring/configuration externalized rather than hardcoded?
7. Is the error-handling strategy consistent with the rest of the system?
8. Are transaction boundaries placed where consistency actually requires them?
9. Are cross-cutting concerns (logging, auth, retries) centralized, not re-implemented?
10. Does this change follow or silently break the codebase's established patterns?
TypeScript-specific:
11. Any "any" types leaking through signatures?
12. Are type assertions (as) hiding real type errors?
13. Any non-null assertions (!) where a check belongs?
14. Do narrowed types survive across async boundaries?

REQUIRED OUTPUT FORMAT
- One finding per bullet: [SEVERITY] location — what is wrong and why it matters.
- Group findings by severity, CRITICAL first.
- Cite the exact line, function, or symbol for every finding.
- Do not mention checklist items that pass — findings only.
- Prioritize findings that matter; skip pure style nits unless they hurt readability.
- If something is done notably well, say so once — briefly.

FINAL VERDICT
- End with a verdict: APPROVED, APPROVED WITH COMMENTS, or CHANGES REQUIRED.
- Base the verdict only on the findings listed above.

CODE TO REVIEW
[Paste the file here]

More resources from Code Review Prompt Generator

Resource

Code Review Prompt — the Review Contract

"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.

Prompt Engineering

Resource

Security Code Review Prompt

Twelve security checks — injection, auth, secrets, SSRF, privilege escalation — reviewed the way an attacker would read the code.

Engineering

Resource

Authorization Review Prompt

Hunt the broken-access-control bug — review code for missing per-resource checks, IDOR, and 'logged in' mistaken for 'allowed', the vulnerability class that tops the OWASP list.

Engineering

Resources that pair well

Resource

Refactor Prompt — the Behavior Preservation Contract

"Refactor this code" invites silent behavior changes. The refactoring contract preserves business rules, outputs, and side effects — and flags uncertainty instead of deciding it.

Prompt Engineering

Resource

Playwright Test Prompt

getByRole over CSS chains, auto-wait over sleep, web-first assertions — Playwright tests written the way Playwright wants.

Engineering

Resource

Compare Two ChatGPT Prompts

A side-by-side way to decide between two ChatGPT prompt drafts — scored on clarity, specificity, output control, and risk instead of gut feeling.

Prompt Engineering

Related tools

Tool

Code Review Prompt Generator

Generate code review prompts for any scope — snippet, file, diff, or full pull request — with focused review rules.

Coding Workflows

Projects that use this resource

Project

Build a SaaS MVP with AI

The full path from idea to a shipped SaaS MVP — define and scope the requirements, design the architecture, API, and data model, then build it reviewed, tested, secured, cost-controlled, and deployed.

11 stages Product Build

Project

Build an API Backend with AI

The full path to a backend you can put clients on — define the requirements, design the architecture, API contract, data model, and access control, then build it reviewed, tested, secured, and shipped.

9 stages Software Development

Project

Build an AI Workflow Automation System with AI

The full path to automation that survives the real world — wire the integrations and triggers, design the control API, move the data through validated stages, evaluate the AI steps, then deploy.

5 stages AI Systems

Project

Build a Marketplace with AI

The full path to a two-sided platform — define the buyer-and-seller requirements, model the data, design the API, build roles and permissions, wire integrations, design the UI, then test, secure, and ship it.

10 stages Software Development

Project

Build a CRM with AI

The full path to a CRM that fits your sales process — define the contacts, deals, and pipeline, model the data that ties them together, then build the roles, integrations, and pipeline UI, and ship.

9 stages Business Systems

Project

Build an E-commerce Store with AI

The full path to a store you own end to end — model the catalog and orders, design the storefront and checkout, add customer accounts and payments, then secure it, test it, and ship.

10 stages Commerce

Project

Build a Data Pipeline with AI

The full path to a pipeline that moves data without corrupting it — design the ingestion and transforms, extract and structure the sources, gate the quality, store it, then deliver and ship it monitored.

6 stages Data Systems

Workflows that use this resource

Workflow

AI API Design Workflow

Design an API on its contract instead of discovering it endpoint by endpoint — model the resources, design the endpoints and payloads, pin the contract, then review it before code locks it in.

4 steps 40–70 minutes

Tip: Save time by exploring related resources and tools that integrate with this resource.