Model Onboarding
Do not maintain a model catalog in this skill; it becomes stale faster than the
runtime. Establish the current contract for every change:
- Read
AGENTS.md, then core/llm/, provider adapters, configuration,
capability gates, model selection UI, pricing/context accounting, and their
tests. Search for every occurrence of the affected model or provider.
- Verify unstable facts against the provider's current primary documentation:
exact model ID, API surface, context/output limits, supported controls,
authentication route, retirement date, and pricing when cost accounting is
affected. Record the source and retrieval date in the PR.
- Separate model capability from account policy and route availability. Do
not infer support from a similar model name or an SDK type alone.
- Add the smallest characterization that fails on a stale ID, missing
capability, or wrong route. Run provider tests without live calls; live or
paid probes require explicit user approval.
- Update
CHANGELOG.md and user-facing model docs when behavior changes, then
follow the repository workflow and GitFlow gates.
For usage/cache field or cost changes, load the
usage accounting contract
to check provider denominators, missing detail, and billing authority.
Credentials come only from the existing provider configuration path. Never ask
for, print, commit, or copy API keys, OAuth tokens, or credential files into a
prompt, test fixture, log, PR, or research note.
1---2name: model-onboarding3description: Add or update a GEODE model or provider from current primary documentation and repository call-site evidence. Use for model IDs, context limits, pricing, reasoning controls, provider routes, capability gates, or fallback changes.4---56# Model Onboarding78Do not maintain a model catalog in this skill; it becomes stale faster than the9runtime. Establish the current contract for every change:10111. Read `AGENTS.md`, then `core/llm/`, provider adapters, configuration,12 capability gates, model selection UI, pricing/context accounting, and their13 tests. Search for every occurrence of the affected model or provider.142. Verify unstable facts against the provider's current primary documentation:15 exact model ID, API surface, context/output limits, supported controls,16 authentication route, retirement date, and pricing when cost accounting is17 affected. Record the source and retrieval date in the PR.183. Separate model capability from account policy and route availability. Do19 not infer support from a similar model name or an SDK type alone.204. Add the smallest characterization that fails on a stale ID, missing21 capability, or wrong route. Run provider tests without live calls; live or22 paid probes require explicit user approval.235. Update `CHANGELOG.md` and user-facing model docs when behavior changes, then24 follow the repository workflow and GitFlow gates.2526For usage/cache field or cost changes, load the27[usage accounting contract](../../../docs/architecture/usage-accounting.md)28to check provider denominators, missing detail, and billing authority.2930Credentials come only from the existing provider configuration path. Never ask31for, print, commit, or copy API keys, OAuth tokens, or credential files into a32prompt, test fixture, log, PR, or research note.