Capabilities

uze routes four resource kinds. For each one, the question is: can this harness preserve the canonical semantics through its own native mechanism?

Agent Skills — one capability, invocation policy as semantics

A Skill is the canonical capability. Its portable semantics are who may invoke it:

---
invoke:
  model: true   # the model may invoke it on its own (background knowledge)
  user: true    # the user may invoke it explicitly
---

The invocation policy is never a separate capability kind and never a second surface: it is the invoke: {model, user} block in SKILL.md. Integrations translate that policy into their own encoding — Claude's frontmatter, Codex's agents/openai.yaml, OpenCode's metadata.opencode — or report the degradation honestly when it cannot be expressed.

Every UZE-projected skill gets a stable, plugin-qualified invocation label (flow:review, ADR-026), so installation order and other plugins can never change how it is invoked.

MCP servers

Delivered natively where the harness has a native mechanism (claude mcp add, codex mcp add, agy mcp add, OpenCode's global config) or inside the native/generated plugin when the package already ships the envelope.

Agents

Markdown agent definitions projected to each harness's native agent surface — Claude's agents directory, Codex's standalone TOML files, OpenCode's config agents, Antigravity's global agents.

Hooks (portable, ADR-033)

One authored hooks.json + a shell-command ABI (normalized stdin/stdout, bounded output and timeout, first-deny-wins) is the canonical hook surface. Each harness gets its own projection:

• Claude/Codex — merged entries in their own hook config (settings.json / hooks.json)
• Antigravity — named entries in the generated native plugin
• OpenCode — an owned, regenerable plugin bridge (no native declarative hook surface exists)

Projections are receipt-owned and content-identity inspected; foreign hooks, plugins, and ordering are never touched.