Skip to main content

Agent Skill-Bundle Governance

Use when governing skill bundles across agent fleets. Define role-specific skill bundles once, propagate them across heterogeneous agent harnesses, and verify actual loading and tool capability. A policy document is not deployment evidence.

Core contract​

Keep four concerns explicit and separate:

  1. Bundle policy — ordered mandatory skills by role, plus conditional skills selected by observable task shape.
  2. Harness loading — the supported mechanism each runtime uses to load or read those skills.
  3. Tool capability — required MCP/tools configured and connected in the worker runtime.
  4. Evidence — exact loaded bundle and prerequisite lookups recorded in the worker handoff.

Procedure​

  1. Inventory roles and launchers: planner/coordinator, implementer, reviewer and verifier; Hermes, OpenCode, Claude Code, Codex or another harness.
  2. Put the canonical ordered bundles in one machine-readable policy. Keep provider/model routing separate so a model rebind does not change coding standards.
  3. For Hermes sessions, preload the role bundle with the supported --skills interface from reviewed config. Validate the list as nonempty, unique strings and test the generated argv.
  4. Do not assume skills cross process boundaries. A planner loading a skill does not give it to a child, and Hermes-local skills do not automatically load in OpenCode. The assignment brief must name the bundle and require the worker to load/read it or receive an equivalent exact contract.
  5. Configure prerequisite tools in each worker transport. For library documentation, Context7 must be connected before dispatch; workers resolve the library ID, query current version-relevant docs before coding, and record library/version/topic. If coverage is inadequate, record that and use official current docs.
  6. Attach conditional skills only when the task predicate matches. Avoid loading every platform, security, UI and migration skill on every task.
  7. Update durable managers and scheduled planners through supported APIs, then read back the exact targets. Existing sessions retain their original context; do not restart productive incumbents solely to retrofit a bundle.
  8. Verify focused adapter tests, policy/schema checks, transport capability and readback. Run broader gates where appropriate and report unrelated failures without suppression.
  9. Distinguish local activation from fleet publication. A local skill edit or policy file does not prove other hosts pulled it.

Required handoff evidence​

  • Role and launcher used.
  • Exact mandatory and conditional skills loaded/read.
  • External-library documentation evidence: Context7 library ID, relevant version and queried topic, or a recorded coverage limitation plus official source.
  • Candidate identity and actual verification commands/results.
  • Any fleet hosts or scheduled jobs not yet updated.

Pitfalls​

  • Prompt prose without runtime preload/read evidence.
  • Adding skills to a planner but not its spawned worker.
  • Treating an MCP policy as proof the MCP server is connected.
  • Mixing model routing and skill policy in hard-coded launch code.
  • Restarting in-flight work merely to apply future-assignment standards.
  • Calling a local documentation edit fleet-wide deployment.

See references/heterogeneous-worker-bundles.md for a concrete seven-skill worker, five-skill planner and conditional product bundle pattern.

Supporting files: this skill's supporting files are held in the docsite at docs/15-skills/_support/autonomous-ai-agents/agent-skill-bundle-governance/ — fetch them fresh from jknash/docsite main alongside this page. Source: jknash/hermes-shared-skills · branch hermes-jkdev001 @ 1d0d545c3970 · skills/autonomous-ai-agents/agent-skill-bundle-governance/ · view source · Imported 2026-10-03. Supporting files (references, scripts) remain in the source repository.

version 0.1.0.

Published by Muse · 2026-10-03.