Add Copilot plugin manifest

[sbroenne]

Summary

Adds a Copilot CLI plugin.json manifest so Squad can be installed as a GitHub Copilot plugin.

Changes

• Adds root-level plugin.json with Squad metadata.
• Points plugin agents to .github/agents.
• Points plugin skills to .copilot/skills.

Validation

• Confirmed the current upstream repo cannot be installed with copilot plugin install bradygaster/squad because no plugin manifest exists.
• Confirmed the Copilot CLI looks for plugin.json, .github/plugin/plugin.json, .plugin/plugin.json, or .claude-plugin/plugin.json.
• Confirmed the manifest is available on this PR branch. Full copilot plugin install bradygaster/squad validation requires the manifest to be on the default branch because the CLI does not accept a branch ref in the plugin install spec.
• Confirmed copilot plugin install sbroenne/squad works from the fork default branch after adding this manifest there for testing.

[Copilot]

Pull request overview

Adds a root-level GitHub Copilot CLI plugin.json manifest so the Squad repository can be installed and discovered as a Copilot plugin, wiring the plugin to the repo’s existing agents, skills, and MCP server configuration.

Changes:

• Introduces plugin.json with plugin metadata (name/description/version/license/repo links).
• Configures plugin discovery paths for agents (.github/agents) and skills (.copilot/skills).
• Points MCP server configuration to .copilot/mcp-config.json.

[bradygaster]

OMG WE WERE JUST TALKING ABOUT THIS.

[bradygaster]

@sbroenne how are you feeling about this draft? we actually need this capability for an idea - you feeling like this is finished or want help getting it finished?

[tamirdresher]

Thanks @sbroenne
Not sure this will work as-is though. I think it will also take some of the skills we have that are part of the squad dev and not for the squad users

Have you tried it?

[tamirdresher]

@sbroenne thanks again for getting this started! Took a closer look and I want to flag a scoping concern before this lands, plus a bigger question about the end-user experience.

The scoping issue

The manifest points skills: ".copilot/skills", but that directory today is mostly squad-dev internals, not user-facing capabilities:

agent-collaboration       architectural-proposals    architectural-review
ci-validation-gates       cli-wiring                  client-compatibility
distributed-mesh          git-workflow                github-multi-account
history-hygiene           init-mode                   model-selection
pr-lifecycle              protected-files             release-process
reskill                   reviewer-protocol           secret-handling
security-review           squad-conventions           windows-compatibility
agent-conduct

Things like cli-wiring, release-process, ci-validation-gates, init-mode, protected-files, pr-lifecycle, reskill are about working on Squad, not using Squad in your project. If end-users install the plugin they inherit all of this, which leaks our own pipeline (changesets, template-sync, etc.) into their environment.

The Copilot plugin manifest only accepts a single skills directory (no globs/lists), so curation is required. Two options:

1. Split the dir. Move dev-only skills to something like .squad/dev-skills/ and keep .copilot/skills/ user-facing only. Manifest stays as-is. This is the right end state.
2. Ship v1 without skills. Omit the "skills" field — plugin installs the coordinator only; users add skills later. Fastest unblock; revisit curation in a follow-up.

.github/agents/ only has squad.agent.md and is the custom agent and not the template so not sure again we want it as-is

The bigger question
@bradygaster
Before we pick a path, can you walk us through how you imagine the workflow for someone who installs the squad plugin? Concretely:

• After copilot plugin install bradygaster/squad, what does day-one look like for them? Do they get a coordinator that runs init mode in their repo? Or is it expected to attach to an existing .squad/?
• How do they cast a team, configure routing, get the agents/decisions/log structure set up — does the plugin install the scaffolding, or is that still on squad-cli?
• What's the relationship between the plugin and the CLI going forward — does the plugin replace it, complement it, or are they two ways of doing the same thing?
• Which skills do you think a fresh user actually needs on day one vs. what they'd opt into later?

Asking because the answers there shape what "user-facing skills" even means, and whether option 1 or option 2 above is the right call. Have you tried the install end-to-end in a fresh repo to see what the experience feels like?