Menu
Use when configuring custom providers for OpenCode.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | configure-opencode-custom-providers |
| description | Use when configuring custom providers for OpenCode. |
| license | CC-BY-SA-4.0 |
This skill guides you on how to configure custom providers for OpenCode.
The user must provide one or multiple pairs of provider API base url and API key. If they didn't, do nothing and ask the user to provide them.
OpenCode is an open-source coding agent. It relies on https://models.dev (Repo) to provide a catalogue of available models and providers, which is also maintained by Anomaly.
Use opencode debug paths. If this fails, stop immediately.
Fetch each provider API base url with the provided API key:
curl -H "Authorization: Bearer <API_KEY>" <API_BASE_URL>/v1/models
curl -H "x-api-key: <API_KEY>" <API_BASE_URL>/v1/models
If both returns 404, first retry without v1. If 404 persists, this might mean the API does not provide a models endpoint. You should ask the user to provide a model list instead before proceeding. Report accordingly if the error is not 404 (e.g., permission denied).
First, fetch <models.dev>'s API: https://models.dev/models.json. The JSON is extremely large, never curl is barely. You must gate the output through jq first. Then, for each model seen in the previous step, check if it exists in <models.dev>. If it does, get the metadata of the model. Model IDs from <models.dev> and the custom provider does not have to match exactly. You are allowed to make reasonable inferences.
If you cannot find a model on <models.dev>, do not add it to the config file in the next step. Report the models you cannot determine to the user in the final task report.
This determines the npm field to use. Try POST on /v1/chat/completions and /v1/messages WITHOUT keys (otherwise you might spend the user's API quota). If /v1/chat/completions exists, the API is OpenAI-style, use @ai-sdk/openai-compatible. If /v1/messages exists, the API is Anthropic-style, use @ai-sdk/anthropic. If both are available or both fails, prefer @ai-sdk/openai-compatible. In the case of failure, you should include this is the task report.
Read these docs before you start, they will tell you the shape of custom providers and models configuration: https://opencode.ai/docs/providers https://opencode.ai/docs/models. Then, write the config file with valid models, and fill in the metadata with the information you got from <models.dev>. Note that you must use the id from the custom provider, not the id from <models.dev>.
Use when removing dead code, renaming symbols, or refactoring — any change with no external consumers. Triggers on deprecating dead code, wrapper shims, compatibility aliases, TODO-future-cleanup, or refactors that patch structure instead of simplifying.
Use when writing new React components that involve state derived from props, event-driven side effects, or external subscriptions. Also use when auditing existing code for unnecessary useEffect calls, reviewing useEffect-heavy components, or refactoring to eliminate cascading renders. Applies to React 18+ codebases.
Use when about to make git commits, when tempted to bundle unrelated changes behind a single message, or when commit history needs to support git bisect, revert, and cherry-pick workflows. Also use when reviewing a branch before creating a PR. If you are writing a plan, specify that the executor must load this skill before start working.
Use when configuring or enhancing oxlint rules for a JavaScript/TypeScript project, when deciding which lint rules to enable beyond the default correctness category, or when evaluating whether a lint rule's autofix status and noise level make it worth enabling. Also use when bulk-enabling pedantic or style categories has produced excessive noise.
Use when a user provides examples prefixed by "for example", "such as", "e.g.", "like", or ends a list with "etc." / "and so on". For architecture/design tasks, abstract first to identify the concept, then enumerate. For research/clarification tasks, enumerate first — the concept organizes the output but the list is the deliverable.
Use when an agent violates a loaded skill despite it being present in context — a gap exists between what the skill says and what the agent did. Also use when reviewing skill effectiveness after a violation, or when deciding whether a skill needs enhancement vs the failure is tolerable.