GitHub standardizes 'agent skills' to bring reusable instructions to any AI agent
New format based on versioned SKILL.md files lets teams capture repeatable tasks and share them across agents while keeping tools and permissions under each environment's control
GitHub has introduced a standardized format for capturing repeatable engineering work in files that teams can review and reuse across different AI agents. The proposal, detailed on the company's blog, revolves around a versioned directory whose core is the SKILL.md file, which describes when and how to execute a task.
The discussion was held live during GitHub Universe 2026, in a session with Shishir Tewari, Senior Data Engineering Manager at Procore, titled "Build once, run on any agent: a practical guide to agent skills".
What separates instruction from execution
The central premise is that the skill carries knowledge of the procedure but not the means to execute it. A skill can describe how to query a database, for example, but it does not grant access to that database — tools, credentials, and permissions remain specific to the environment hosting the agent.
This design solves a recurring problem: context that today gets lost in chats or stays trapped in a single specialist's head. By turning that knowledge into a versioned file, the instruction becomes reviewable like any other code artifact.
Adversarial verification as a principle
The text uses the example of the Proof Agent, aimed at checking AI-generated changes against the original request. The rule guiding the skill is direct: self-verification is not verification. Therefore, an independent verifier examines the changes and presents evidence for its conclusions.
The skill's frontmatter names the task and describes its purpose, while the "When to Verify" section defines when to trigger the procedure and the rest of the instructions detail what the verifier reviews and which evidence to include.
Data pipeline as a use case
The Data Forge example shows how multiple skills can work together. In a support pipeline, the forge-init skill discovers details such as source tables and naming conventions, writing them into a resolved manifest that the other skills read to obtain project context.
Next, forge-builder coordinates the work from issue to pull request, using 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 bundles pipeline code, schema changes, and tests.
Each skill has a defined responsibility and shares the project context instead of redesigning it independently. When a step changes, a single skill is altered — and the knowledge no longer depends on the availability of whoever held it.