Skills

A Skill is a named, lattice-aware unit of capability. Where most frameworks tie a “skill” or “tool” to one agent that calls it directly, Axocoatl Skills are routed by the lattice — they declare what events they emit and react to, and the system wires them automatically.

Runnable example

examples/skills-lattice shows one CodeReady event fanning out to every agent that holds a reacting skill, then chaining ReviewComplete → a deploy gate — cargo run, no API keys.

Anatomy

- id: code-review-checklist
  name: "Code Review Checklist"
  description: "Structured 12-point review."
  emits: ["ReviewComplete", "BlockingIssueFound"]
  reacts_to: ["CodeReady", "PullRequestOpened"]
  agents: [reviewer, coder]
  prompt: |
    Review the code against: correctness, edge cases, error handling,
    performance, security, style, naming, tests. Return JSON with
    `issues` and `severity`.

Five knobs:

• emits — events this Skill publishes when it completes.
• reacts_to — events that, when published by anyone, fire this Skill.
• agents — which agents hold this Skill. Any of them can activate when the Skill fires.
• prompt — what the agent gets told when this Skill activates.
• description — surfaces in the dashboard.

Holder selection

When PullRequestOpened lands on the lattice, every Skill that lists it in reacts_to is a candidate. For code-review-checklist, the lattice finds two holders (reviewer, coder). Today the lattice activates the holders directly — fan-out, no central picker. You don’t pre-assign.

Why there’s no skill auction

A natural question: when several holders contend, shouldn’t the system score them and pick a single winner? Axocoatl treats skill-selection arbitration as a non-goal — fan-out is the intended behavior for a Skill. Activating every holder is composable and predictable; you add a holder and it participates, no hidden scoring to reason about.

Auctioning does exist in Axocoatl, but in a different place: the coordinator role runs a capability + budget auction to assign subtasks to a pool of worker agents it spawns. That’s where “pick the single best fit” belongs — a coordinator decomposing one task across workers, not the lattice choosing among Skill holders. See The event lattice for how the coordinator’s auction works.

Manual fire

In the dashboard’s Skills tab, click any Skill → Fire this Skill. This publishes the Skill’s emit events to the lattice. Anything that reacts to them activates.

From the CLI:

curl -X POST http://localhost:8080/api/skills/code-review-checklist/fire

Why this matters

The lattice routing is what makes Axocoatl composable. Add a new agent that also holds an existing Skill — no rewiring. Move a Skill from one agent to another — the lattice routes there next time. Add a new event that someone reacts to — fires automatically.

You’re not assembling a graph by hand. You’re declaring intent, and the lattice does the routing.