You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support external repository sources for plugins (don't require content to live in this repo) #15
marketplace.json requires all plugin content to live inside this repo via relative paths. This forces plugin authors to duplicate content here rather than pointing to their canonical source repo.
Use Case
We maintain AzureCosmosDB/cosmosdb-agent-kit - 57+ Cosmos DB best-practice rules in the standard skill format (SKILL.md + AGENTS.md). The same skill is consumed by Claude Code, Gemini CLI, Cursor, and other agents via Agent Skills. We want it discoverable through this registry without duplicating content that would drift from the source.
Proposal
Support a repository field in marketplace.json that points to an external GitHub repo:
{
"name": "cosmosdb-best-practices",
"repository": "AzureCosmosDB/cosmosdb-agent-kit",
"path": "skills/cosmosdb-best-practices",
"description": "Azure Cosmos DB best practices — 57+ rules for data modeling, partitioning, queries, SDK patterns, and more.",
"version": "1.0.0"
}
This is the same pattern used by npm, Homebrew, and the VS Code Marketplace - the registry indexes, the external repo provides content. The workiq plugin already does this for its MCP server (npx @microsoft/workiq), so the precedent exists for skills too.
Happy to Help
We can submit a PR, help define the schema, and serve as a test case once this is supported.
+1 on this. We're building agent governance integrations — policy enforcement, trust scoring, and audit trails for AI agent frameworks (PydanticAI, CrewAI, OpenAI Agents). We also just built a governance skill, hook, and agent following the awesome-copilot format.
Our use case is similar to @TheovanKraay's — we want the canonical source to live in our repos while being discoverable through this registry. The proposed repository field schema makes a lot of sense.
What our external plugin entry would look like:
{
"name": "agent-governance",
"repository": "imran-siddique/awesome-ai-governance",
"path": "awesome-copilot-contributions",
"description": "Governance patterns, threat detection hook, and safety instructions for AI agent systems.",
"version": "1.0.0",
"skills": ["./skills/agent-governance"],
"hooks": ["./hooks/governance-audit"]
}
One addition to the proposal: it would be helpful to support hooks in addition to skills in external plugins. Our governance-audit hook scans prompts for threat signals (data exfiltration, privilege escalation, prompt injection) and maintains an audit trail — this is the kind of safety infrastructure that benefits from living in a maintained external repo where we can update threat patterns without waiting for a PR merge cycle.
Happy to help test this once it lands — we can serve as a second external repo test case alongside the CosmosDB agent kit.
Activity
imran-siddique commentedon Feb 18, 2026
+1 on this. We're building agent governance integrations — policy enforcement, trust scoring, and audit trails for AI agent frameworks (PydanticAI, CrewAI, OpenAI Agents). We also just built a governance skill, hook, and agent following the
awesome-copilotformat.Our use case is similar to @TheovanKraay's — we want the canonical source to live in our repos while being discoverable through this registry. The proposed
repositoryfield schema makes a lot of sense.What our external plugin entry would look like:
{ "name": "agent-governance", "repository": "imran-siddique/awesome-ai-governance", "path": "awesome-copilot-contributions", "description": "Governance patterns, threat detection hook, and safety instructions for AI agent systems.", "version": "1.0.0", "skills": ["./skills/agent-governance"], "hooks": ["./hooks/governance-audit"] }One addition to the proposal: it would be helpful to support hooks in addition to skills in external plugins. Our
governance-audithook scans prompts for threat signals (data exfiltration, privilege escalation, prompt injection) and maintains an audit trail — this is the kind of safety infrastructure that benefits from living in a maintained external repo where we can update threat patterns without waiting for a PR merge cycle.Happy to help test this once it lands — we can serve as a second external repo test case alongside the CosmosDB agent kit.
tlmii commentedon Feb 24, 2026
The plugin source can point to another repo. See e.g. https://github.com/github/copilot-plugins/pull/17/changes