Build once, run on any agent: A practical guide to agent skills

An agent skill carries instructions from one agent to another, but it does not carry the power to act on them. That is the line running through a practitioner guide on the GitHub Blog by Andrea Griffiths of GitHub. She defines a skill as a versioned folder built around a SKILL.md file that tells an agent when to do a repeatable task and how. The same folder can be used by different agents, but the tools, credentials and permissions still come from whatever environment runs the agent. In her example, a skill can explain how to query a database without granting access to it. The format itself began at Anthropic, which handed the Agent Skills standard to the Agentic AI Foundation in October and says more than 70 agent platforms, GitHub Copilot and Cursor among them, have adopted it. Most of Griffiths' advice is about deciding what goes in the skill's text and what has to live somewhere else.

Her main example, Data Forge, shows that split in a set of four skills that build data pipelines, prepared for the GitHub Universe 2026 session she gave with Shishir Tewari of Procore. Project facts sit in a manifest file. A setup skill, forge-init, inspects the warehouse and codebase for details such as source tables and naming conventions and writes them into the manifest, and the other skills read it instead of each making its own assumptions about the project. Griffiths' test for whether this worked is whether another team could use the same skills with its own manifest without rewriting them. Team standards are kept apart from those discovered facts in a separate skill, forge-lint, because a pattern found in a repository is not automatically a rule worth keeping, and people are asked to confirm discovered details where business judgment is needed. Access to the data platform goes through one shared skill, forge-dbx, which reads the manifest and picks a Databricks or DuckDB adapter so no other skill needs its own connection logic. The manifest can choose DuckDB, but it cannot install DuckDB or grant database access. In her words, "The manifest picks the engine; the host provides the access."

Enforcement follows the same rule: a skill can tell an agent to stop and ask, but anything that must hold has to be configured outside it. Data Forge runs its build in seven phases with a human checkpoint at each, checks that a phase is complete before the next starts, and asks for approval before schema changes. The second example, Proof Agent, rests on the idea that "self-verification is not verification." A GitHub Actions workflow gives a separate verifier the original request and the code changes, but not the coding agent's own account of its work, and the verifier returns PASS, FAIL or PARTIAL with evidence from the changed files. It only reads the diff; it does not run code or tests. Whether a FAIL actually blocks a merge depends on the repository's own rules, which is where Griffiths says test results and merge requirements belong. She also draws the outer boundary: when a workflow needs a stable interface, shared state, an audit trail, long-running control or permissions enforced outside the model, she recommends building an application instead.

"Run on any agent" therefore means one source of instructions, with each agent's setup still checked separately. Data Forge keeps each skill's SKILL.md as the single original and uses a packaging script to generate the files that Claude Code, Cursor and GitHub Copilot each expect, with a check mode that can run in CI. Because those clients differ in models, tools, credentials and permissions, Griffiths advises confirming after installation that each one recognizes the skill, loads its references, can use the tools it needs and returns the evidence the skill asks for. Her guide is about skills a team writes for itself. For skills installed from someone else, a recent talk by Roey Ben Chaim of Zenity argues that reading a SKILL.md cannot show what an agent will actually do, since instructions can fetch more instructions and install scripts can pull in packages, and he treats skills as software dependencies whose access should be restricted. Both reach the same practical point from different directions: what an agent can do depends on the environment it runs in, and that environment is where access has to be limited.