Skip to content

Instantly share code, notes, and snippets.

@zircote

zircote/Feature-Request.md

Created January 16, 2026 15:56
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save zircote/c202e4d9f87215e4a5191b45543bb8cf to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save zircote/c202e4d9f87215e4a5191b45543bb8cf to your computer and use it in GitHub Desktop.
Download ZIP
GitHub Feature Request: Marketplace-Style Skill References for Copilot Workflows
Raw
Feature-Request.md

GitHub Feature Request: Marketplace-Style Skill References for Copilot Workflows

Submitted by: Robert Allen, VP of DevOps Engineering, Houghton Mifflin Harcourt
Date: January 16, 2026
Priority: High
Category: GitHub Copilot / Agentic Workflows / Enterprise Extensibility

Executive Summary

We request the ability to reference Agent Skills from a marketplace or registry using declarative YAML syntax analogous to GitHub Actions' uses: directive. This would enable enterprise teams to share, version, and compose AI agent capabilities across repositories with the same governance and reproducibility patterns established by GitHub Actions.

Problem Statement

Current State

GitHub Copilot coding agent and GitHub Agentic Workflows support Agent Skills through filesystem discovery (.github/skills/ or .claude/skills/). While this works for repository-local skills, enterprises face significant challenges when scaling skill adoption across hundreds of repositories:

  1. No declarative skill dependencies — Skills must be manually copied or maintained via git submodules, creating version drift and maintenance overhead.

  2. Inconsistent versioning — Unlike Actions (uses: actions/checkout@v4), skills lack SHA pinning or semantic versioning for reproducible builds.

  3. No centralized discovery — While the GitHub MCP Registry provides discovery for MCP servers via gh aw mcp add, no equivalent exists for Agent Skills.

  4. Governance gaps — Enterprise security teams cannot enforce allowlists of approved skills the way they can with Actions.

  5. Duplication across repositories — Organizations maintaining 350+ services (as we do) must replicate skills manually, leading to inconsistency and technical debt.

The Gap Illustrated

Capability GitHub Actions MCP Servers Agent Skills
Declarative YAML reference ✅ uses: owner/repo@v1 ✅ gh aw mcp add ❌ Manual copy
Version pinning ✅ SHA/tag/branch ✅ Container tags ❌ None
Marketplace/Registry ✅ GitHub Marketplace ✅ MCP Registry ❌ None
Enterprise allowlists ✅ Actions policies ✅ MCP policies ❌ None
Cross-repo sharing ✅ Native ✅ Native ⚠️ Submodules/plugins

Proposed Solution

1. Introduce skills: Block in Workflow Frontmatter

Enable declarative skill references in GitHub Agentic Workflows and Copilot configurations:

---
name: incident-response-workflow
on: 
  issues:
    types: [labeled]

skills:
  - uses: anthropics/skills/pdf@v1
  - uses: anthropics/skills/docx@v1.2.0
  - uses: my-org/internal-skills/incident-response@main
  - uses: my-org/observability-skills/datadog-triage@sha-abc1234

mcp-servers:
  datadog:
    url: "https://mcp.datadoghq.com/sse"
    
tools:
  github:
    toolsets: [default, actions]
---

# Workflow instructions here

2. Extend GitHub MCP Registry to Include Skills

Leverage the existing MCP Registry infrastructure (api.mcp.github.com) to support skill discovery:

# Proposed CLI commands
gh aw skill search "pdf processing"
gh aw skill add my-workflow anthropics/skills/pdf --version v1
gh aw skill list my-workflow
gh aw skill update my-workflow --all

3. Enterprise Governance Controls

Mirror the existing Actions and MCP policy framework:

  • Organization-level skill policies — Allow all, registry only, or explicit allowlist
  • Enterprise-level inheritance — Cascade policies across organizations
  • Audit logging — Track skill usage across repositories
  • Private skill registries — Host internal skills with organizational scoping

4. Skill Lockfile for Reproducibility

Generate .github/skills.lock.yml similar to dependency lockfiles:

# .github/skills.lock.yml (auto-generated)
skills:
  anthropics/skills/pdf:
    version: v1.2.0
    resolved: sha256:abc123...
    integrity: sha512-def456...
  my-org/internal-skills/incident-response:
    version: main
    resolved: sha-789xyz

Use Cases

Use Case 1: Enterprise DevOps Standardization

Scenario: HMH maintains 350+ microservices with Datadog observability. We need consistent incident response procedures across all repositories.

Current approach: Manually copy incident-response skill to each repository, leading to version drift.

Proposed approach:

skills:
  - uses: hmh-internal/devops-skills/incident-triage@v2
  - uses: hmh-internal/devops-skills/datadog-analysis@v2

Use Case 2: Compliance and Audit

Scenario: Security team needs to audit which AI capabilities are deployed across the organization.

Current approach: No visibility into skill usage; requires manual repository scanning.

Proposed approach: Query enterprise audit logs for skill installations and invocations.

Use Case 3: Skill Composition for Complex Workflows

Scenario: Build an agentic workflow that combines PDF processing, data extraction, and automated reporting.

Current approach: Copy multiple skill directories, manage dependencies manually.

Proposed approach:

skills:
  - uses: anthropics/skills/pdf@v1
  - uses: anthropics/skills/xlsx@v1
  - uses: anthropics/skills/pptx@v1
  - uses: community/data-visualization@v3

Use Case 4: Cross-Platform Skill Portability

Scenario: Skills authored for Claude Code should work in Copilot coding agent without modification.

Current approach: Skills in .claude/skills/ are auto-discovered by Copilot, but there's no versioning.

Proposed approach: Registry-based skills work identically across Claude Code, Copilot CLI, and Copilot coding agent with consistent versioning.

Technical Considerations

Compatibility with Existing Infrastructure

  • Leverage MCP Registry architecture — Extend api.mcp.github.com to serve skill metadata
  • Reuse Actions policy engine — Apply existing allowlist/blocklist mechanisms
  • Maintain filesystem fallback — Local .github/skills/ continues to work for development

Skill Resolution Order (Proposed)

  1. Explicit skills: references in workflow frontmatter (highest priority)
  2. Repository-level skills (.github/skills/)
  3. Organization-level managed skills
  4. Enterprise-level managed skills (lowest priority)

Security Model

  • SHA pinning required for production — Enforce immutable references in protected branches
  • Signature verification — Optional skill signing for verified publishers
  • Sandboxed execution — Skills inherit the existing Copilot coding agent sandbox model

Business Impact

For HMH Specifically

Metric Current State With Feature
Skill deployment time ~2 hours/repo (manual) ~2 minutes (declarative)
Version consistency ~60% (drift) 100% (lockfile)
Security audit capability Manual scanning Automated reporting
Cross-team skill sharing Ad-hoc Governed marketplace

For GitHub Enterprise Customers Generally

  • Reduced onboarding friction — New repositories inherit organizational skills automatically
  • Improved AI governance — Security teams gain visibility into agentic capabilities
  • Ecosystem growth — Marketplace incentivizes skill creation and sharing
  • Competitive differentiation — First-mover advantage in enterprise AI workflow orchestration

Alignment with GitHub Strategy

This feature request aligns with several announced GitHub directions:

  1. "Organization-level and enterprise-level skills coming soon" — Referenced in current documentation; this proposal provides a concrete implementation path.

  2. MCP Registry expansion — The registry infrastructure already exists; extending it to skills is a natural evolution.

  3. Agentic Workflows vision — The gh-aw framework already treats workflows as composable; skills should follow the same pattern.

  4. Actions-first design philosophy — Agentic Workflows explicitly builds on Actions patterns; skill references should mirror uses: syntax.

Requested Timeline

Phase Deliverable Target
Phase 1 RFC/Design document for public comment Q2 2026
Phase 2 Private preview for enterprise customers Q3 2026
Phase 3 Public preview with registry support Q4 2026
Phase 4 General availability with governance controls Q1 2027

Appendix: Related Resources

Contact

Robert Allen
VP of DevOps Engineering
Houghton Mifflin Harcourt

Available for follow-up discussion, technical deep-dive, or private preview participation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment