copilot-manager
Copilot Manager
Manage existing GitHub Copilot customizations across both Copilot IDE (VS Code/JetBrains) and Copilot CLI (terminal agent). This skill gives you the ability to discover what exists, find conflicts, reconcile between the two environments, and surgically modify or remove customizations — all using file tools, no external dependencies.
How the Two Copilots Differ
Copilot IDE and Copilot CLI share some paths but have distinct discovery models. Understanding this is key to everything that follows.
Shared paths (both targets read these):
.github/copilot-instructions.md— project-level guidance.github/agents/*.md— custom agents.github/skills/*/SKILL.md— skills.github/hooks/*.json— hooksAGENTS.md— root-level agent definitions~/.copilot/agents/,~/.copilot/skills/— user-level artifacts
IDE-only features:
.github/prompts/*.prompt.md— prompt templates (CLI has no equivalent).vscode/settings.json,.vscode/mcp.json— VS Code settings & MCP.devcontainer.json— dev container MCP servers- Settings-driven custom paths (
chat.*Locationskeys) - Cross-reads
CLAUDE.mdandGEMINI.mdfrom repo root - Language model overrides via settings
CLI-only features:
~/.copilot/config.json— CLI-specific configuration~/.copilot/copilot-instructions.md— user-level guidance.claude/commands/*.md— command files- Parent directory chain walking (inherits from parent dirs)
- Environment variables:
COPILOT_CUSTOM_INSTRUCTIONS_DIRS,COPILOT_HOME - User-level agents override project-level (opposite of IDE)
Files read by both targets at repo root:
AGENTS.md,CLAUDE.md,GEMINI.md,.github/copilot-instructions.mdCLAUDE.local.mdis read by IDE only (not by CLI)
For complete path listings, read references/copilot-ide-paths.md and
references/copilot-cli-paths.md.
Operations
1. Discover — "What customizations exist?"
Scan the workspace and user home to build a complete inventory.
Workspace scan — use Glob to check each path family:
# Shared paths
.github/copilot-instructions.md
.github/instructions/*.instructions.md
.github/agents/*.md
.github/skills/*/SKILL.md
.github/hooks/*.json
.github/prompts/*.prompt.md
AGENTS.md
.agents/skills/*/SKILL.md
# IDE-specific paths
.vscode/settings.json
.vscode/mcp.json
.vscode/hooks/*.json
.devcontainer.json
.devcontainer/devcontainer.json
.github/chatmodes/*.chatmode.md
# Shared instruction files (read by both IDE and CLI)
CLAUDE.md
GEMINI.md
# IDE-only instruction files
CLAUDE.local.md
.claude/CLAUDE.md
.claude/rules/*.md
.claude/agents/*.md
.claude/skills/*/SKILL.md
.claude/commands/*.md
.claude/settings.json
.claude/settings.local.json
User-level scan — expand ~ to the actual home directory, then Glob:
# Copilot user tree
~/.copilot/config.json
~/.copilot/copilot-instructions.md
~/.copilot/instructions/*.instructions.md
~/.copilot/agents/*.md
~/.copilot/skills/*/SKILL.md
~/.copilot/mcp-config.json
# Claude user tree (cross-read)
~/.claude/CLAUDE.md
~/.claude/rules/*.md
~/.claude/agents/*.md
~/.claude/skills/*/SKILL.md
~/.claude/commands/*.md
# VS Code profile (Windows: ~/AppData/Roaming/Code/User/, Linux/Mac: ~/.config/Code/User/)
<vscode-profile>/agents/*.md
<vscode-profile>/prompts/*.prompt.md
<vscode-profile>/skills/*/SKILL.md
<vscode-profile>/hooks/*.json
<vscode-profile>/mcp.json
Plugin scan:
~/.copilot/installed-plugins/*/
~/.copilot/state/marketplace-cache/*/
Each plugin folder should contain a plugin.json (check .github/plugin/, .claude-plugin/, then root).
For each discovered file, read it and extract:
- Kind: guidance, agent, skill, prompt, hook, mcp, setting, command, plugin
- Target: which Copilot(s) see it (IDE, CLI, or both)
- Scope: user, repository, or directory
- Name: from frontmatter
name/idfield, or filename stem - Frontmatter: parse the YAML between
---delimiters (seereferences/frontmatter-schema.md)
Present results as a table grouped by kind, showing path, target visibility, scope, and name.
2. Audit — "Are there problems?"
After discovery, check for these issue categories:
Name collisions: Two artifacts of the same kind with the same logical name.
Group all discovered artifacts by (kind, lowercase_name). Any group with >1 entry
is a potential collision. Classify as:
- Same target, different scopes → shadowed (higher scope wins)
- Same target, same scope, different paths → ambiguous (error — needs resolution)
- Different targets, same scope → duplicate (warning — may be intentional)
Lossy mappings: Artifacts that exist for one target but not the other, where no cross-readability rule covers the gap:
.prompt.mdfiles → only IDE sees them, CLI has no equivalent.claude/commands/*.md→ only CLI sees them, IDE has no equivalent- VS Code settings-driven instructions → only IDE sees them
CLAUDE.local.md→ only IDE reads it, CLI does not.vscode/mcp.json→ only IDE sees it; CLI uses~/.copilot/mcp-config.json
Cross-read awareness: Both CLAUDE.md and GEMINI.md are read by both Copilot
IDE and CLI. CLAUDE.local.md is read only by IDE. Warn if these files contain
tool-specific instructions that don't make sense for all readers.
MCP drift: Compare .vscode/mcp.json (IDE) with ~/.copilot/mcp-config.json
(CLI user). Flag servers that exist in one but not the other. Note: CLI has no
standard repo-level MCP path equivalent to IDE's .vscode/mcp.json.
Orphaned legacy files: Check for .chatmode.md files — these still work but should
be migrated to .md agents.
Settings checks: If .vscode/settings.json exists, look for:
chat.useAgentsMdFile— isAGENTS.mdreading enabled?chat.useClaudeMdFile— isCLAUDE.mdcross-reading enabled?chat.useNestedAgentsMdFiles— are nestedAGENTS.mdfiles enabled?- Custom location overrides that might point to nonexistent paths
For the full reconciliation checklist, read references/reconciliation.md.
3. Reconcile — "Fix the gaps"
Based on audit findings, propose and execute fixes:
For duplicate agents across targets:
Choose a shared location (.github/agents/) so both targets see it, then remove
the target-specific copy.
For lossy mappings (prompts with no CLI equivalent):
Offer to create a corresponding .claude/commands/<name>.md with equivalent content
adapted for CLI context.
For MCP drift:
Offer to sync server definitions between .vscode/mcp.json (IDE) and
~/.copilot/mcp-config.json (CLI). Note: CLI has no standard repo-level MCP config
path — MCP is configured per-user or via --additional-mcp-config flag at runtime.
For shared instruction files (CLAUDE.md, GEMINI.md read by all Copilots): Review the content for tool-specific instructions. Offer to:
- Add a note at the top:
<!-- Note: This file is read by Claude Code, Copilot IDE, and Copilot CLI --> - Split Claude-specific content into
.claude/rules/(not read by Copilot) and keep only universal guidance inCLAUDE.md - For
CLAUDE.local.md: note it is read by Copilot IDE but not CLI
For shadowed artifacts: Explain which version wins (scope precedence: user < repo < directory) and offer to remove the shadowed version or rename it.
4. Modify — "Change a customization"
To modify an existing customization:
- Read the target file
- Parse frontmatter if present (YAML between
---lines) - Make the requested change to frontmatter or body
- Write back using the Edit tool (preserve existing formatting)
Common modifications:
- Update agent tools list: Edit the
tools:array in frontmatter - Change instruction scope: Modify or add
applyTo:glob - Update skill description: Edit the
description:field - Add handoffs: Add
handoffs:entries to agent frontmatter - Change MCP server config: Edit the server entry in the JSON file
- Move an artifact: Read from source, Write to destination, delete source
When modifying frontmatter, preserve the --- delimiters and any fields you're not
changing. Be careful with YAML formatting — use the same style (quoted vs unquoted,
flow vs block) as the existing file.
5. Delete — "Remove a customization"
Before deleting, always:
- Show what will be removed — display the file path and a summary of its content
- Check for references — search for the artifact's name in other files:
- Agent names referenced in
handoffs:,agents:,excludeAgent: - Skill names referenced in agent tool lists
- MCP server names referenced in
mcp-servers:
- Agent names referenced in
- Confirm with the user — deletion is not easily reversible outside of git
- Delete the file using bash
rm - Clean up empty directories if the deleted file was the only occupant
- Report what was deleted and any dangling references found
For skill folders (*/SKILL.md), delete the entire skill directory, not just the
SKILL.md file.
Reporting Format
When presenting discovery or audit results, use this structure:
## Copilot Customization Inventory
### Guidance (N files)
| File | Target | Scope | Applied To |
|------|--------|-------|------------|
### Agents (N files)
| File | Name | Target | Scope | Tools |
|------|------|--------|-------|-------|
### Skills (N folders)
| Folder | Name | Target | Scope |
|--------|------|--------|-------|
### MCP Servers
| Config File | Target | Servers |
|-------------|--------|---------|
### Issues Found
- [severity] description
Reference Files
Load these on demand — only when you need detailed path listings or schema info:
| File | When to read |
|---|---|
references/copilot-ide-paths.md |
Deep-dive into all IDE discovery paths |
references/copilot-cli-paths.md |
Deep-dive into all CLI discovery paths |
references/reconciliation.md |
Full conflict types, cross-read rules, and checklist |
references/frontmatter-schema.md |
Complete frontmatter field reference by artifact type |
More from thomasrohde/marketplace
drawio diagram creation
This skill should be used when the user asks to "create a diagram", "make a flowchart", "generate a .drawio file", "draw.io diagram", "diagrams.net", "architecture diagram", "sequence diagram", "ER diagram", "class diagram", "network diagram", "org chart", "workflow diagram", "UML diagram", "ArchiMate diagram", "C4 diagram", "C4 model", "enterprise architecture", or mentions "drawio", "mxGraph", or diagram visualization. Provides comprehensive knowledge for creating production-ready DrawIO XML files.
38archimate model quality
This skill should be used when the user asks about "ArchiMate naming conventions", "model quality", "EA smells", "anti-patterns", "ArchiMate best practices", "model review", "abstraction levels", "viewpoints", "model organization", or needs guidance on creating high-quality ArchiMate models.
20archimate relationships
This skill should be used when the user asks about "ArchiMate relationships", "composition vs aggregation", "realization relationship", "serving relationship", "assignment relationship", "triggering", "flow relationship", "access relationship", "influence", "specialization", "cross-layer relationships", or needs help connecting ArchiMate elements correctly.
18archimate modeling fundamentals
This skill should be used when the user asks about "ArchiMate elements", "which element to use", "ArchiMate layers", "business layer", "application layer", "technology layer", "motivation layer", "strategy layer", "active structure", "passive structure", "behavior elements", or needs help selecting the correct ArchiMate element type for modeling enterprise architecture.
16archimate architecture patterns
This skill should be used when the user asks about "ArchiMate patterns", "microservices in ArchiMate", "cloud architecture ArchiMate", "API gateway pattern", "event-driven architecture", "container architecture", "Kubernetes ArchiMate", "data architecture pattern", "security architecture", "capability mapping", "value stream", or needs to model modern architecture patterns in ArchiMate.
16jarchi scripting
This skill should be used when the user asks to "create a jArchi script", "write an Archi script", "automate ArchiMate", "export from Archi", "query ArchiMate elements", "create ArchiMate views", "run Archi headlessly", "Archi CLI", "batch process ArchiMate model", or mentions "jArchi", ".ajs script", "Archi automation", or ArchiMate scripting. Provides comprehensive jArchi API knowledge and CLI automation support.
13