Skill support for agents: no way to distribute or install a skill

[yjc801]

Filed on behalf of @yjc801 (JC) from #buzz-dev.

Problem

There is no way to give a Buzz agent a new skill. Skills work at the runtime layer, but nothing distributes them.

What exists today

• buzz-agent discovers skills from SKILL_DIRS under the session cwd plus ~/.agents/skills, renders an "Available Skills" list into the prompt, and exposes a built-in load_skill tool for on-demand loading of the body — crates/buzz-agent/src/hints.rs:204, crates/buzz-agent/src/builtin.rs:13.
• Desktop provisions exactly one skill, and it is hardcoded: BUZZ_CLI_SKILL_MD = include_str!("nest_skill.md") written to .agents/skills/buzz-cli/SKILL.md, then symlinked into each harness's own skill dir (.goose/skills, .claude/skills, .codex/skills) — desktop/src-tauri/src/managed_agents/nest.rs:44,59,448,493 and managed_agents/discovery.rs:97,130,163.
• Persona packs can declare skills: skills: in persona frontmatter, resolve_skills() maps skill → persona, validate checks the directory — crates/buzz-persona/src/pack.rs:249, src/validate.rs:377. But nothing ever copies them anywhere. The spec says so outright: "resolution to SKILL.md name: fields and runtime copying to $AGENT_CWD/.agents/skills/ is planned" — crates/buzz-persona/PERSONA_PACK_SPEC.md:312.

The gap

• No relay-side representation of a skill, so no event kind, no fan-out, no auth pipeline.
• No CLI surface (buzz skills … does not exist) and no desktop UI to attach a skill to a managed agent.
• No versioning or update path — the one hardcoded skill uses a .skill-version file bumped by hand in Rust source.
• Pack-declared skills silently do nothing at runtime, which is worse than not supporting them: buzz pack prints "Skills: …" for a persona whose agent will never see them (crates/buzz-cli/src/commands/pack.rs:119).

Proposed direction

Per CLAUDE.md's "prefer a new event kind over a new HTTP endpoint":

1. New addressable event kind for a skill in crates/buzz-core/src/kind.rs — d = skill name, content = SKILL.md, owner-signed. Supporting files either inlined as a small manifest or referenced via Blossom for anything large.
2. Agent-side materialization at session start, modelled on crates/buzz-acp/src/engram_fetch.rs: fetch → verify → write .agents/skills/<name>/. Same failure discipline — a relay outage must never look like "no skills" and must never block session creation.
3. buzz skills set/ls/get/rm in buzz-cli (subcommand first, then client.rs), so an agent or its owner can publish one without a desktop build.
4. Close the pack loop: install skills_dir contents per resolve_skills() when a pack is applied, so the declared-but-inert case goes away.
5. Desktop: attach/detach skills per managed agent.

Trust boundary — needs a decision before implementation. The agent base prompt currently forbids loading relay-backed skills unless the authorizing human names the specific skill, and treats their content as untrusted. Any auto-install path has to be reconciled with that rule: the likely answer is that owner-signed skills addressed to that agent auto-install, and everything else stays opt-in by name — but that should be written down, not assumed.

Acceptance criteria

• Skill kind registered in kind.rs and handled by the relay.
• buzz skills CRUD in buzz-cli.
• Agent session start materializes owner-signed skills; relay failure is logged and non-fatal.
• Pack-declared skills are actually installed for the personas that declare them.
• Trust rules for relay-sourced skills documented in the base prompt.
• Unit tests for fetch/verify/materialize, and for the untrusted-source rejection path.

Open questions for JC

• Scope of a skill: per-owner (all my agents), per-agent, or per-community/team?
• Do skills need to reach buzz-acp agents (which run someone else's harness, e.g. Claude Code, and read .claude/skills) or only the in-house buzz-agent runtime? The symlink trick in nest.rs suggests both, but that decides the install layout.
• Should agents be allowed to author skills for themselves, or is publishing owner-only? (Overlaps with the self-evolve issue.)

[yjc801]

Related: #87 (remote memory), #88 (self-evolve — depends on this one).