feat(skills): discover installed user, project, and plugin skills (#362)

[Jason Robert (jrob5756)]

Closes #362.

runtime.skill_discovery picks up skills already installed on the machine, so a workflow can use a personal or team skill library without enumerating each one. Off by default.

workflow:
  runtime:
    skills: [conductor]
    skill_discovery:
      sources: [personal, project, plugins]   # default: [] (disabled)
      exclude: [scratch-notes]

Source	Locations scanned
personal	~/.copilot/skills, ~/.claude/skills
project	.github/skills and .claude/skills, from the workflow file's directory up to the repo root
plugins	~/.copilot/installed-plugins/*/*/skills, ~/.claude/plugins/*/*/skills

Why Conductor scans instead of each provider

This is the substance of the change, not an implementation detail. #350 deferred discovery precisely because discovery locations are provider-specific — a single discover_skills: true flag would surface different skill sets to different agents inside one run, depending on which provider each resolved to.

Scanning the union centrally means every agent sees the identical set whatever provider it uses, and all of #350's machinery (frontmatter validation, collision handling, native vs. eager delivery, the injection budget) applies unchanged. It also keeps the providers' own discovery switched off — Copilot's enable_config_discovery would additionally auto-load MCP servers from any .mcp.json in the working directory, which is the constraint #362 carried over.

The organising principle: strict/lenient asymmetry

The author wrote the explicit entries; they did not write the discovered ones. So the same problem is reported differently:

Problem	Declared skill	Discovered skill
Broken SKILL.md frontmatter	error	warning, skipped
Name already taken	error	warning, skipped
Directory unreadable	error	warning, skipped
Provider cannot load it	error	warning, skipped

That last row is load-bearing rather than theoretical: only 1 of 13 installed Copilot plugins on a real machine ships .claude-plugin/plugin.json, so erroring would bury a claude-agent-sdk user in failures for content they never wrote.

Answers to the three questions #362 left open

1. Config shape — a category enum, not a boolean and not per-provider blocks. Categories are what a user recognises; which CLI owns each path is what Conductor unions over.
2. Cost on eager-injection providers — claude and hermes refuse discovery at validation time. Measured, the discovered set is 260,182 bytes ≈ 65K tokens: 2× the default max_bytes, and machine-dependent. There is no limit to tune that makes this safe, so the error names the remedy (enumerate in runtime.skills, or move those agents to a progressive-disclosure provider). Same call Skills: discover user-installed, project, and standalone skills (follow-up to #215) #350 made for non-plugin path skills on claude-agent-sdk.
3. Default — off.

Other decisions

• Declared skills win a name collision; the discovered copy is skipped with a warning. Required, not cosmetic: installing Conductor's own plugin puts a second conductor skill on the machine, and resolve_skills would otherwise hard-error.
• Discovery joins the workflow-level default set, so the tri-state is unchanged and skills: [] stays the one opt-out. No new per-agent knob.
• Fixed canonical scan order (project → personal → plugins) independent of YAML order, so reordering sources: cannot change which of two same-named skills wins.
• The project walk stops at the repo root, and does not walk at all when there is no .git — an unversioned tree must not sweep in whatever sits above it.

Visibility

conductor validate lists what was found and what it would cost:

Skill discovery (personal, plugins): 3 skill(s)
  • acme-widgets — /home/dev/.copilot/skills
  • triage — /home/dev/.copilot/installed-plugins/team/tools/skills
  Total if eagerly injected: 41,204 bytes (~10,301 tokens)

An ambient set is the one part of a workflow the YAML does not capture, so making it inspectable is part of the feature.

Implementation notes

• New skills/discovery.py; expand_skills_root extracted from registry.py::_resolve_path_entry so discovery adds no second opinion about what a skill directory is.
• resolve_effective_skills is the single composition point used by both AgentExecutor and conductor validate, so a run and its validation cannot disagree.
• ResolvedSkill.discovered: bool carries provenance, so callers branch on a field rather than sniffing a string.
• discover_skills(..., home=...) takes the home directory as a parameter specifically so no test reads the developer's real ~.

Testing

• 99 new tests (4850 passed / 29 skipped, up from 4751 on main).
• 13 mutation tests, all caught — including both engine AgentExecutor sites (the mutation that escaped review in Skills: discover user-installed, project, and standalone skills (follow-up to #215) #350), the explicit-wins precedence, the claude/hermes refusal, the repo-root walk bounds, and the canonical ordering. Registry mode is now covered by a stub-registry test, which is the only way to exercise the second executor site.
• make check clean; make validate-examples exit 0.