GitHub Blog guide shows how to build portable agent skills for Copilot, Claude Code and Cursor

What an agent skill is

An agent skill, as the GitHub Blog defines it, is a versioned directory whose centerpiece is a SKILL.md file explaining when to perform a recurring task and how to carry it out. The instructions are portable between agents; the ability to act on them is not. Tools, credentials and permissions belong to the host environment, so a skill can explain the procedure for querying a database while access to that database stays with whoever runs the skill.

The post, tied to a GitHub Universe 2026 session delivered with Shishir Tewari, Senior Manager of Data Engineering at Procore, starts from a familiar annoyance: the same task gets re-explained to an agent again and again, and some of that knowledge exists only in one colleague's head. Skills move both into files that teams can review, version and reuse, so a personal skill written one evening can later become part of a team pipeline.

One skill, one job

GitHub recommends giving each skill a single clear job with defined inputs and outputs. Its first example, Proof Agent, is a verifier for AI-generated changes. The guiding idea is that an agent grading its own work does not amount to a real check, so the skill spawns an independent verifier. Frontmatter in SKILL.md names the skill and describes its purpose, and a dedicated section states when verification should trigger.

The verification runs in a GitHub Actions workflow that hands the verifier the original request and the code diff, but deliberately withholds the coding agent's own account of what it did. The verifier answers with PASS, FAIL or PARTIAL and must point to evidence in the changed files. The action only reviews the diff statically; it executes no code or tests. In the demo the check was configured so failures were advisory, though by default a FAIL fails the check and can block a merge when the check is required. Test results and merge rules, GitHub argues, belong in the repository's CI.

Composing skills into a workflow

The second example, Data Forge, targets data pipelines where the judgment that makes a pipeline correct is spread across several people, making those people the bottleneck for every change. A forge-init skill inspects the project, including source tables and naming conventions, and records its findings in a resolved manifest that every other skill reads. A forge-builder skill then drives the work from issue to pull request, calling on forge-dbx to query the data platform and forge-lint to apply team standards. A person reviews the proposed decisions along the way, and the resulting pull request carries the pipeline code, schema changes and tests.

The support-desk demo runs seven phases with a human checkpoint in each, and the workflow confirms a phase is complete before starting the next and asks for approval before schema changes run. Because each skill owns one responsibility and they share project context rather than rediscovering it, a change to one step means editing one skill and leaving the rest alone.

GitHub is also explicit about limits. Skills suit bounded, repeatable work that benefits from reusable judgment, such as checklists, releases, migrations and metric pipelines. When a workflow needs a stable interface, shared state, an audit trail, long-running control or permissions enforced outside the model, an application is the better fit.

Manifests and multi-client packaging

Project-specific details, such as names, schemas, conventions and the data engine, belong in a manifest rather than in the skills themselves. In the demo the manifest selects DuckDB and a Spark-based Python pipeline framework, but it cannot install the DuckDB CLI or grant database access; installation and access remain the environment's job. GitHub also separates discovered facts from team rules: forge-init records what it finds, forge-lint supplies the standards, and people confirm or override discoveries where business judgment applies. The portability test is whether another team could run the skills against its own manifest without rewriting them.

For teams supporting several agent clients, the skills directory serves as the source of truth, and a packaging script generates client-specific files: .claude-plugin/plugin.json for Claude Code, .cursor-plugin/plugin.json for Cursor and .github/agents/*.agent.md for GitHub Copilot. The script includes a check mode for CI. Since clients differ in models, tools and permissions, GitHub advises verifying after installation that the client recognizes the skill for its intended task, loads its references, can use the required tools and returns the evidence the skill calls for.

Why it matters

The post closes with three practices: keep business context in one visible file, give related skills a single shared path to the platform, and use instructions to guide work while checks verify it. The larger signal is standardization. If SKILL.md becomes a common format across Copilot, Claude Code and Cursor, reusable agent work becomes reviewable like any other code, teams stop rewriting the same prompts per client, and institutional knowledge moves out of chat threads and individual heads into versioned files, with humans kept at the decision points and CI enforcing the outcomes.