/api-errors

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select api-errors from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv api-errors, /just-vibe api-errors and /jv:api-errors in Claude. See shortcut setup and context examples.

What the agent does

1. Inventory existing client-visible codes and shapes and the compatibility they must preserve.
2. Map domain failures to stable public errors deliberately, redacting internal details while preserving safe correlation IDs.
3. Test representative client and server failures: validation, authorization, dependency and unexpected errors.

Inputs

• API scope, current error format, consumers, and logging requirements.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads

Error status, machine-readable codes, safe messages, propagation, and trace correlation.

Writes

Apply: only the requested local changes and relevant isolated verification. Inspect/plan requests remain inspection/planning. External actions require their exact action and target in session authorization.

Mode

Apply; API scope, current error format, consumers, and logging requirements.

Prerequisites

Interface definitions, producer/consumer source, authentication model, versioning constraints, and isolated test endpoints. External API calls must respect environment, credentials, rate limits, and side-effect scope.

Expected output

• Error taxonomy and documented contract, the mapping locations, and checks for validation, authorization and dependency failures.

How the work is checked

• Validation errors identify usable field problems; unexpected failures do not leak stack traces or credentials.

When to stop or clarify

• Do not turn all failures into success responses or change public codes silently. Unknown consumer reliance needs compatibility handling.

Handling missing context

Infer

Read producer/consumer schemas, error contracts, auth conventions and known supported client versions.

Assume

Keep compatible response and pagination semantics where the brief does not request a breaking change.

Ask

Ask when contract sources disagree or an unknown consumer changes compatibility; do not require live credentials to write or test an isolated client.

Technical guidance

Evidence

Inventory exception sources, status semantics, domain codes, request IDs and retry behavior.

Method

Map expected domain failures to stable public errors; redact internal details while retaining correlated server diagnostics.

Pitfall

Returning 200 with an error-shaped body or retryable status for a permanent denial misleads clients.

Check

Exercise invalid input, forbidden resource, dependency timeout and unexpected exception; verify public redaction and useful internal correlation.

Situational decisions

When changing a code would break a known consumer: Add a compatibility path or a versioned transition instead of silently normalizing it.

When no published error contract exists: Prefer RFC 9457 Problem Details (application/problem+json) with stable type URIs and extension members for field errors; never break an existing published shape.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring