feat(skills): per-skill model preference via hermes.model frontmatter

[alf3lobster]

What this does

Adds two composable pieces so skill authors can declare which model a skill works best with, and callers can honour that when delegating.

1. metadata.hermes.model in SKILL.md frontmatter

Parsed by extract_skill_conditions alongside the existing toolset conditions. Surfaced in _find_all_skills output (and GET /api/skills). Skills that omit the field default to "" — fully backward-compatible.

metadata:
  hermes:
    model: "anthropic/claude-opus-4-7"
    requires_toolsets: [web]

2. model parameter on delegate_task

A per-call override threaded through the task loop and _build_child_agent. Works for single-task and batch modes; in batch mode each task can set its own model independently.

Precedence: per-call model > delegation.model (config) > parent_agent.model

delegate_task(goal="Run account-research for Yettel", model="anthropic/claude-opus-4-7")

What this doesn't do (intentional scope)

Automatic model injection without LLM involvement. A follow-up could add a skill parameter that looks up the model from frontmatter automatically without the LLM needing to pass it explicitly.

Files changed

• agent/skill_utils.py — extract_skill_conditions returns model key
• tools/skills_tool.py — _find_all_skills surfaces model in output
• tools/delegate_tool.py — model in schema (top-level + per-task) and function signature; per-task model resolution in build loop; registry handler updated
• run_agent.py — _dispatch_delegate_task threads model through
• tests/agent/test_skill_utils.py — three updated assertions + two new tests

[alt-glitch]

Related to #8485, #19270, #5508, #5997 — multiple prior attempts at per-skill model routing. This PR is narrower-scoped (frontmatter field + delegate_task param) compared to #8485 (full routing + supervisor/execution model config).

[alf3lobster]

Thanks for the context, @alt-glitch.

Aware of those issues — this PR is intentionally a minimal slice of what #8485 proposed, covering only mechanisms 1 and 2 (the model= param on delegate_task and the hermes.model frontmatter field). The automatic skill-to-model lookup (delegate_task(skill='...') resolving the model without the caller passing it) is explicitly out of scope here and noted in the PR description as a follow-up.

The goal was to get the lowest-risk piece merged first: pure data (frontmatter parsing) and a single optional parameter that preserves full backward-compat. The config aliases from #8485 mechanism 3 are a separate concern.

If there's a preferred approach or concerns about the schema surface (e.g. whether model should live under metadata.hermes vs top-level frontmatter), happy to adjust.

[teknium1]

This would cause too much confusion to users, feel free to build a standalone plugin that makes this possible if you'd like