agentleFS
ProfSynapseProfSynapse/nexus/.claude/skills/nexus-model-updates/SKILL.md

nexus-model-updates

Skill158 starsChanged 10 days agoMITView on GitHub

Add, change or verify a Nexus LLM model definition — the registry entry, the provider default, and proof the model id actually works against the live endpoint. Use when adding a newly released model, editing model metadata such as pricing, context window or capability flags, promoting a provider default, standing up a model registry for a new provider, or checking whether a model id resolves through the live provider smoke lane.

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    MUST get a zero exit from scripts/check_model_registry.py --repo-root .

    line 49

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Nexus model updates

Each provider keeps a static model catalog at src/services/llm/adapters/<provider>/<Provider>Models.ts: an array of ModelSpec literals plus a *_DEFAULT_MODEL export. Two aggregators read those arrays, and between them they decide what the model picker offers, what a call costs, and which UI affordances appear.

Nothing here holds model ids, prices, context windows or provider lists — the registries are the truth and they change weekly. This skill holds the procedure and the checks. To see what the tree currently declares:

python3 .claude/skills/nexus-model-updates/scripts/check_model_registry.py \
  --repo-root . --list

Workflow

  1. A model in a provider that already has a registry — follow protocols/add-model.md. Get every number from the provider's own source; values carried over from another gateway's entry are wrong more often than they are right.
  2. Moving a provider's default — follow protocols/change-default.md. The default is written in several independent places and TypeScript checks none of them against each other, so you MUST work that protocol rather than editing the one you happened to find.
  3. A provider with no registry yet — follow protocols/add-provider-registry.md. Adapter wiring belongs to nexus-llm-adapters; only the catalog and its aggregator entries are yours.
  4. An image generation model — follow protocols/add-image-model.md. Image models live in the image adapters' own catalogs, not in <Provider>Models.ts, the structural gate does not see them, and the committed tool catalogs embed their enum.
  5. A video generation model — follow protocols/add-video-model.md. They live in one static array in src/services/llm/types/VideoTypes.ts. The structural gate does not see them, and an id missing from that array is rejected even when the provider lists it.
  6. A Live / realtime voice model (Google *-live*, OpenAI gpt-realtime*) — follow protocols/add-realtime-voice-model.md. These ids answer only over a WebSocket session, so they do not belong in <Provider>Models.ts, the structural gate does not see them, and the provider smoke lane cannot prove them; the realtime smoke lane drives the shipped session instead.
  7. Before calling any of the above done — run protocols/verify-model.md. You MUST get a zero exit from scripts/check_model_registry.py --repo-root . <provider>, and you MUST NOT report a model as working on the strength of a registry entry: the entry is a claim about an id, and only a live call tests it.
  8. End of a session that used this skill — run protocols/self-refine.md.

Map

  • protocols/ the procedures: add-model, add-image-model, add-video-model, add-realtime-voice-model, change-default, add-provider-registry, verify-model, self-refine.
  • references/ mechanism, read on demand: registry-anatomy.md (what a ModelSpec field means and how to fill it), consumers.md (who reads the registries and what silently breaks when metadata is wrong), smoke-harness.md (the live provider smoke lane in detail), provider-listings.md (how to ask a provider what it serves right now — run this before saying a model does not exist).
  • scripts/check_model_registry.py — the structural gate: required fields, provider/directory agreement, unreachable duplicate ids, defaults that point at nothing, adapter literals that drifted from the registry, and registries wired into one aggregator but not the other. Run it; do not re-derive it by reading source.

Siblings — do not duplicate them here

  • nexus-llm-adapters owns adapter wiring: transport, streaming, reasoning rendering, and the provider registration points outside the model catalog.
  • nexus-model-eval owns grading a model on Nexus tool use. A smoke test proves the id returns text; it proves nothing about tool calling, and a model that passes smoke can still be unusable in chat.
  • nexus-eval-harness owns running and changing the eval harness itself.
  • nexus-testing owns which Jest lane to use and what a mock can prove.

Refine

At the end of a session that used this skill, run protocols/self-refine.md and append to refinement-log.md.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.