Skip to content

Feature Request: Auto-import skills and agents from user's .github repo #1633

@sandeeprawat

Description

@sandeeprawat

Summary

Allow Copilot CLI to automatically discover and load skills and agents from a user's <username>/.github repository on GitHub, similar to how .github repos already serve as a convention for profile READMEs and org-wide configurations.

Problem

Today, personal skills and agents must be manually placed in ~/.copilot/skills/ and ~/.copilot/agents/. This means:

  • Skills/agents aren't synced across machines — if I switch between a laptop, desktop, and codespace, I have to manually copy files to each environment.
  • There's no easy way to share a curated set of skills/agents with teammates ("just clone my .github repo").
  • New machine setup requires extra steps beyond just installing Copilot CLI.

Proposed Solution

Option A — Automatic sync:
If the authenticated user has a .github repository (e.g. sandeeprawat/.github), Copilot CLI automatically fetches (or git-clones/pulls) it and loads:

  • skills/ → as personal skills
  • agents/ → as personal agents

This would happen at CLI startup (with caching so it doesn't slow things down on every launch). A config flag could control the behavior: "importGitHubHomeRepo": true | false.

Option B — Manual command:
A new slash command like /skills import-github or /import-dotgithub that fetches the user's .github repo on demand and registers the skills/agents found in it.

Ideally both — auto-sync by default with a manual command for on-demand refresh.

Benefits

  • Zero-config portability — Skills and agents follow the user across machines, codespaces, and environments automatically.
  • Leverages existing GitHub convention — The <user>/.github repo is already a well-known pattern.
  • Shareability — Users can point colleagues to their .github repo as a curated skill/agent collection.
  • Org-level extension — Could naturally extend to org .github repos (.github-private) for org-wide skills, complementing the existing org-level agent support.

Open Questions

  • Should this be opt-in or opt-out?
  • How to handle conflicts between repo-fetched skills and locally defined skills with the same name?
  • Caching/refresh strategy — pull on every startup vs. periodic vs. manual only?
  • Security: should there be a trust prompt before loading remotely-fetched skills for the first time?

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions