Add a model-agnostic skill for capability-based work routing

## Problem Statement

NemoClaw contributors use different agent runtimes and model providers. A shared workflow that hard-codes one runtime's controls, worker configuration, or specific model IDs would not be portable across the team and would become stale as model catalogs change.

The repository needs a reusable agent skill that routes work according to task characteristics and abstract capability requirements while leaving the concrete model or worker binding to each contributor's runtime. The skill must remain useful when a runtime cannot dynamically switch models or spawn a differently configured worker.

This is related to, but distinct from, #3123: that issue audits whether specific models work correctly across supported agent surfaces. This proposal defines a portable contributor workflow for choosing an available worker profile for a task without embedding provider- or model-specific policy.

## Proposed Design

Add a repository-shared skill:

```text
.agents/skills/nemoclaw-contributor-route-work/
├── SKILL.md
└── references/
└── policy-template.md
```

### Capability profiles

Route to logical profiles rather than model names. Profiles are team-defined and describe requirements or preferences such as:

- reasoning depth;
- coding and tool-use support;
- context capacity;
- latency;
- cost;
- privacy or data-handling constraints;
- domain specialization.

Illustrative profiles may include `fast`, `standard`, and `deep-review`, but the skill must not require those names.

Example policy:

```yaml
routes:
- when: "Mechanical searches, formatting, or low-risk edits"
profile: fast

- when: "Normal implementation and testing"
profile: standard

- when: "Security, architecture, or ambiguous high-risk work"
profile: deep-review

profiles:
fast:
prefer: [low-latency, low-cost]
standard:
require: [coding, tool-use]
deep-review:
require: [strong-reasoning, coding, tool-use]
prefer: [large-context]
```

Concrete bindings remain outside the shared skill. Each contributor or runtime may map `deep-review`, for example, to any available hosted or local model, specialized agent, or future system.

### Routing behavior

Apply policy in this order:

1. An explicit instruction for the current task.
2. Repository or team routing policy.
3. The configured default profile.
4. The active agent as a transparent fallback.

For each task:

1. Classify the work using only the stated routing conditions.
2. Resolve the matching capability profile.
3. Check whether the current runtime exposes a compatible worker or delegation mechanism.
4. Delegate when the binding exists and delegation is useful.
5. Otherwise continue with the active agent and disclose that routing was advisory only.
6. Never claim that a different model or worker was used unless the runtime confirms it.

### Portability constraints

The core skill must not depend on:

- a particular model or provider;
- a particular runtime's commands or configuration files;
- runtime-specific subagent configuration;
- a fixed model catalog;
- inferred pricing or capability rankings;
- dynamic model switching being available.

Runtime-specific examples can be added later as optional adapters, but they must not become requirements for the core workflow.

### Repository integration

Add the skill to `.agents/skills/nemoclaw-skills-guide/SKILL.md` as a contributor workflow. Keep the skill concise and put the reusable policy schema and examples in `references/policy-template.md`.

### Acceptance criteria

- [ ] The skill contains no hard-coded model IDs or provider requirements.
- [ ] Routing decisions use named capability profiles and explicit conditions.
- [ ] Concrete profile-to-worker bindings are supplied outside the core skill.
- [ ] Explicit task instructions override repository defaults.
- [ ] Unsupported dynamic routing falls back to the active agent with a clear disclosure.
- [ ] The skill never reports an unverified model or worker selection.
- [ ] The policy template supports team-defined profiles and fallback behavior.
- [ ] The skill is listed in the NemoClaw skill catalog.
- [ ] Skill validation passes.
- [ ] A forward test covers both a successful profile selection and the unsupported-routing fallback.
- [ ] Documentation review determines whether user-facing docs need an update.

## Alternatives Considered

1. **Runtime-specific workers with pinned models.** This can provide direct model selection where supported but excludes contributors using other runtimes.
2. **Hard-coded model names in the skill.** This is simple initially but couples policy to providers and rapidly changing model catalogs.
3. **Repository instructions only.** An `AGENTS.md` section could hold the policy, but a skill provides a reusable workflow, progressive disclosure, validation, and a policy template.
4. **Implement routing directly in NemoClaw runtime code.** That is substantially broader and would conflate contributor-agent workflow with NemoClaw's product inference routing.

## Category

Feature

## Checklist

- [x] I searched existing issues and this is not a duplicate
- [x] This is a design proposal, not a "please build this" request