Skills, packages, and delegation contracts
Skills are validated instruction modules with catalog identity and runtime metadata. Packages group skills and add domain-level selection and team guidance. Neither mechanism can grant tools that runtime policy denies.
Skill lifecycle
- 01Discover
Read bundled, user, and Project skill sources through registered providers and validate their entrypoints.
- 02Catalog
Store identity, revision, source locator, description, dependencies, tool metadata, and multi-agent metadata.
- 03Select
Bind a typed skill selection to the owner and dispatch input. Plain text that resembles a skill name does not activate it.
- 04Preflight
Validate trust, dependency, provider, resource, tool, and prompt-budget requirements.
- 05Inject
Load the complete selected skill body for the owning agent. Other skills remain compact catalog hints until explicitly read or selected.
Multi-agent skills
A skill that opts into multi-agent operation uses validated frontmatter and must include an explicit ## Multiagent Setup section. The current strategies are constrained by the skill schema rather than accepted as arbitrary control text.
---
name: citation-proof
description: Verify references and cited claims.
multiagent: true
multiagent-strategy: supervisor-workers
multiagent-output: reference ledgers and final summary
allowed-tools:
- read_text_file
- search_repo
- fetch_url
---
## Multiagent Setup
Describe:
- when delegation is useful
- how work is partitioned
- what each worker must return
- which artifacts the owner verifies
- how failures are recovered
- how the final result is synthesizedSkill packages
A package selects a group of skills for a domain and can provide run-level multi-agent guidance. Its manifest may describe a strategy, recommended roles, role-specific skills, synthesis policy, artifact expectations, and notes.
{
"name": "security-review",
"skills": ["auditor", "citation-proof"],
"multiagent_setup": {
"strategy": "evidence-first",
"recommended_roles": [
{
"name": "evidence-worker",
"purpose": "Verify one bounded claim",
"skills": ["citation-proof"],
"artifact_expectations": ["evidence ledger"]
}
],
"synthesis_policy": "Use verified artifacts only"
}
}Package guidance is applied only after package selection. For a selected skill, the skill's own Multiagent Setup remains the authoritative domain workflow.
Runtime routing
The runtime context contains a budgeted catalog summary. Inferred matches can be prioritized for discovery, but inference does not activate a skill. Selected skills are pinned by catalog identity and revision so a Project edit or package update cannot silently change instructions inside an active attempt.
| Input | Runtime treatment |
|---|---|
| Typed selected skill | Eligible for full-body injection after preflight. |
| Inferred match | Catalog hint only; no activation. |
| Skill name in user or tool text | Inert unless converted through the supported selection boundary. |
| Package multi-agent recipe | Planning guidance after package selection. |
| Skill Multiagent Setup | Authoritative domain delegation instructions for that selected skill. |
Tool authority
A skill-level allowed-tools list can narrow its owning worker's tool surface. It cannot add a tool denied by the Project module policy, runtime profile, namespace policy, provider availability, authentication state, path boundary, or Guardian decision.
The effective module, package, profile, skill inventory, tools, and provider metadata are resolved at a dispatch boundary and retained with identity hashes. Later edits apply only at a new safe dispatch; they do not widen an already-running attempt.