Agent Skills › xinity-ai/xinity-ai › integrate-model

integrate-model

GitHub

用于在集群中集成新推理模型。通过研究模型、组装元数据YAML文件，并使用run-model脚本进行实际运行验证和能力测试（如工具调用、视觉），确保模型可正常运行且数据准确。

.claude/skills/integrate-model/SKILL.md xinity-ai/xinity-ai

Trigger Scenarios

用户请求安装或集成特定模型需要生成新的模型条目以便后续集成

Install

npx skills add xinity-ai/xinity-ai --skill integrate-model -g -y

More Options

Non-standard path

npx skills add https://github.com/xinity-ai/xinity-ai/tree/main/.claude/skills/integrate-model -g -y

Use without installing

npx skills use xinity-ai/xinity-ai@integrate-model

指定 Agent (Claude Code)

npx skills add xinity-ai/xinity-ai --skill integrate-model -a claude-code -g -y

安装 repo 全部 skill

npx skills add xinity-ai/xinity-ai --all -g -y

预览 repo 内 skill

npx skills add xinity-ai/xinity-ai --list

SKILL.md

Frontmatter

{
    "name": "integrate-model",
    "description": "Integrate a new inference model into Xinity from a loose request like \"install\/integrate\/add model X\". Researches the model, assembles validated model data (the xinity-infoserver model entry), and verifies it actually runs via the daemon's run-model script, iterating on failures. Use whenever someone wants to make a specific model runnable on the cluster or to produce a model entry they can integrate themselves."
}

Integrate a model

Follow the canonical procedure in packages/xinity-infoserver/docs/integrating-a-model.md: research the model, assemble its model entry, verify it with run-model, and iterate on failures using the failure/fix table. The field reference is in that doc and in packages/xinity-infoserver/docs/model-fields.md.

When working through it as an agent:

Write the model entry to a YAML file OUTSIDE this repo (e.g. ~/modeloutputs/<model>.yaml) and point run-model --models <that file> at it for verification. NEVER edit or add to this repo's packages/xinity-infoserver/models.yaml: model metadata is tracked externally and the integrator decides where to apply what you produce. No model-data artifacts may land in this repository.
Run run-model with --json (--plan --json, then --start --json) so output is machine-readable; branch on .gate.reason and, on error, the non-zero exit with .code, instead of scraping text.
Confirm the entry by actually running it, not by reasoning alone, and that means a real request, not just /health.
Research and validate declared capabilities: check whether the model supports tool/function calling and vision, and if research says it plausibly does, add the tag (tools also needs providerArgs.vllm: ["--tool-call-parser", "<name>"]) and test it against the running server (a real tool_calls response; an image description). Skip a test only when research shows no realistic chance, and note that you checked.
Do not add custom_code (vLLM --trust-remote-code) preemptively; only after a load failure shows it is needed.
If the model is ambiguous (base vs instruct, size, quantization), ask the user before picking.