Ship the agent plugin sub-agents to GitHub Copilot clients - #8821
Merged
Conversation
Agent Plugins 1.0 standardizes skills, auto-discovered from skills/, but not sub-agents: Copilot clients load those from com.github.copilot/agents, as <name>.agent.md files. The plugin only declared them in the Claude Code and Cursor manifests, which Copilot never reads, so a Copilot user got no sub-agent at all while both the skill and its INSTALL.md told the agent to skip installing them "because the plugin ships them". The three definitions are now generated into com.github.copilot/agents from the Claude Code ones, so the bodies can not drift, and validate_agent_plugins.py fails when they are out of sync. Only the frontmatter differs: Copilot tool aliases already accept the Claude tool names (Read -> read, Grep/Glob -> search, Bash -> execute), but "haiku" is not a Copilot model id, so it is dropped. Also corrected in the skills: - installing the sub-agents by hand on Copilot needs the .agent.md suffix in .github/agents/ and no model override; tools are valid and portable as-is - the install mode is no longer inferred from skill naming (only some platforms namespace plugin skills, and none exposes a skill's origin): it is read from the filesystem, and the user is asked when it stays ambiguous - the frontmatter key `licence` is corrected to `license`, which is the spelling the agents actually read CI now loads the repository as an external plugin in the GitHub Copilot CLI and asserts it is accepted with no manifest error. It runs offline through --plugin-dir, with no marketplace and no authentication. `plugins list` never enumerates the skills a plugin provides, verified against a control plugin, so the check asserts the plugin loads, not that each skill is exposed.
nvuillam
requested review from
Kurt-von-Laven,
bdovaz and
echoix
as code owners
August 28, 2026 14:40
Contributor
✅
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
Raised while reviewing feedback on the awesome-copilot marketplace submission: the skills look Claude-designed, the setup skill's install-mode detection and sub-agent installation look fragile on Copilot, and nothing had been tested in a Copilot harness.
Investigating confirmed one real defect, plus smaller portability issues.
The defect: Copilot users got no sub-agents
Agent Plugins 1.0 standardizes skills — auto-discovered from
skills/, no declaration needed — but not sub-agents. Copilot clients load those fromcom.github.copilot/agents/<name>.agent.mdat the plugin root (spec, VS Code docs).The three definitions were declared only in
.claude-plugin/plugin.jsonand.cursor-plugin/plugin.json, which Copilot never reads. Meanwhile bothmegalinter-setup/SKILL.mdandagents/INSTALL.mdtold the agent to skip installing them, "because the plugin already ships the three definitions". On Copilot that was false, so the user ended up with no sub-agents and no fallback that would install them.They are now generated into
com.github.copilot/agents/from the Claude Code definitions, so the bodies cannot drift, andvalidate_agent_plugins.pyfails when they are out of sync. Only the frontmatter differs: Copilot's tool aliases are case-insensitive and already accept the Claude tool names (Read→read,Grep/Glob→search,Bash→execute,WebFetch/WebSearch→web), buthaikuis not a Copilot model id, so themodeloverride is dropped.The
$schemaand strict Agent Plugins 1.0 compliance ofplugin.jsonare untouched — the schema isadditionalProperties: falseand permits noskills/agentskeys, which is exactly why the components live in the namespaced directory.Other corrections
.agent.mdsuffix in.github/agents/(without it Copilot does not load the file), and droppingmodel:. The previous "droptools/modelif your Copilot version doesn't accept them" was wrong — both are valid fields, andtoolsis portable as-is.licence:→license:in the four skills.licenseis a recognized CopilotSKILL.mdfield; the British spelling was silently ignored everywhere.Testing in a Copilot harness
CI now loads the repository as an external plugin in the GitHub Copilot CLI and asserts it is accepted with no manifest error. It runs offline via
--plugin-dir— no marketplace, no authentication:Scope of that assertion, deliberately stated:
copilot plugins listnever enumerates the skills a plugin provides — verified against a control plugin with and without askillskey, both listing nothing — so this proves the plugin loads and its manifest is valid, not that each skill is exposed. There is also noagentkind inplugins list --kind, so agent loading cannot be asserted from the CLI either. Documented in a comment on the step so nobody reads more into a green check than it earns.Validation