just-vibeAPIs · apply by default
/api-client
Build a typed client with authentication and error handling
Use for a typed transport boundary to a known API, including clients or SDKs generated from an OpenAPI spec; integrate handles wider product wiring.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select api-client from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv api-client, /just-vibe api-client and /jv:api-client in Claude. See shortcut setup and context examples.
/just-vibe:api-client Build a typed API client with bounded retries and useful errors./just-vibe:api-client Build a client for paginated responses and retry-after throttling./just-vibe:api-client Implement against supplied contracts without paid or mutating live requests.What the agent does
- Resolve the API version, authentication and schema.
- Generate or write a narrow client that isolates credentials, validates runtime response shape and preserves actionable status, retry-after and request IDs without leaking credentials.
- Exercise controlled successful, refused, timed-out and malformed responses.
Inputs
- API specification, language/runtime, authentication source, and consumer needs.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Typed client boundary, serialization, errors, pagination, and permitted retries.
- 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 specification, language/runtime, authentication source, and consumer needs.
- 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
- Client interface with usage and configuration names, and timeout, refusal and malformed-response contract checks.
How the work is checked
- Valid responses decode correctly; rate limits/timeouts produce bounded behavior without duplicating unsafe requests.
When to stop or clarify
- Do not embed tokens or assume generated types prove runtime validity. Live paid or mutating requests need explicit scope.
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
- Inspect API version, runtime response shape, token destination, retryable operations and timeout ownership.
- Method
- Separate transport, protocol and domain failures; validate untrusted responses where needed and restrict credential forwarding across redirects/origins.
- Pitfall
- Static types disappear at runtime; automatically retrying every POST can repeat an external effect.
- Check
- Exercise malformed response, cancellation, rate limit and uncertain mutation, verifying bounded retry, typed failure and no credential leakage.
Situational decisions
When a mutating request times out: Retry only under a supported idempotency/reconciliation contract, not generic automatic retry.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.