What happened
GitHub published a practical guide to agent skills, describing each as a versioned directory centered on a SKILL.md file. That file explains when and how to perform a repeatable task. The guide’s central boundary is explicit: instructions may travel across agents, but the environment that runs a skill must provide tools, credentials, and permissions. A skill can explain how to query a database; it cannot grant database access.
The guide recommends giving each skill a clear job, input, and output. Its Proof Agent example uses a separate verifier to inspect AI-generated changes for false claims, broken code, and security issues. The verifier is meant to be independent of the coding agent’s self-assessment. In the GitHub Actions example, it receives the original request and code changes, but not the coding agent’s assessment, and returns PASS, FAIL, or PARTIAL with evidence from changed files. GitHub says the demonstrated action statically reviews the diff; it does not execute code or run tests. The example sets block-on-fail: false, making findings advisory; GitHub says a FAIL fails the check by default and can block a merge when that check is required.
A second example, Data Forge, combines skills to build a support-desk metrics pipeline. An initialization skill discovers details such as source tables and naming conventions and writes them to a resolved manifest. Other skills read that project context. A builder coordinates work from issue to pull request, while separate skills query the data platform and apply team standards. The process includes human review, and the resulting pull request contains pipeline code, schema changes, and tests. GitHub describes seven workflow phases, with a human checkpoint at each; schema changes require approval before running.
The manifest holds project-specific information, including the project and metric-store names and platform configuration. A shared forge-dbx skill reads it and selects a Databricks or DuckDB adapter. GitHub emphasizes that configuration is not setup: the manifest can select DuckDB for a local demo, but cannot install the DuckDB CLI or authorize database access. It also says bounded, repeatable work suits skills; workflows requiring a stable interface, shared state, an audit trail, long-running control, or permissions enforced outside the model are better handled by an application.
For client packaging, the guide keeps skills/*/SKILL.md as the source and uses a script to generate files for Claude Code, Cursor, and GitHub Copilot. The script’s CI check is node scripts/package.mjs --check. GitHub advises testing that each client recognizes the skill, loads references, can access required tools, and returns requested evidence. Its broader recommendations are to centralize project context in a manifest, give related skills a consistent platform-access path, and use tests and repository rules where a check must block a merge or deployment.
What the archive adds
New Runtime’s earlier coverage described Docker’s docker/skills repository as a distributable layer for coding-agent infrastructure procedures (October 1, 2026 note). GitHub’s guide is a new fact on the broader skills story: it gives a cross-client packaging workflow and spells out that skills do not carry host permissions.
Trend signal
This supports the pattern that agent skills are becoming a portable capability layer, while their usefulness depends on provenance, review, and evaluation. GitHub’s packaging guidance favors reuse, but its cautions about permissions and checks show why portability alone is not enough (Skills become a portable capability layer).
Why now
GitHub’s guide is dated November 12, 2026, and presents skills as a way to preserve repeatable engineering judgment that otherwise sits in conversations or individual colleagues’ knowledge. It frames portability as a practical response to teams using multiple agent clients, while stressing that each client still has distinct tools, credentials, and permissions.
Connections to other events
New Runtime’s earlier coverage also tracked a catalog of 74 game-development skills for coding agents (October 24, 2026 note). That catalog and GitHub’s guide meet at reuse, but the guide focuses on workflow composition, project context, approval, and packaging rather than a domain-specific collection.
Why it matters
Teams often mistake reusable instructions for a reusable execution environment. GitHub’s examples draw a useful line: skills can encode judgment, coordinate bounded work, and make expected evidence visible, while the host remains responsible for access and permissions. That makes a skill a potentially valuable unit for standardizing recurring tasks without pretending it is a complete agent application.
The guide also argues for separating project facts from team standards. A manifest can describe the current project, while a linting skill supplies rules; people can review discovered details before they become assumptions. Independent verification and required CI checks provide further controls, though the examples do not establish how reliably they catch failures in production. For teams adopting skills across clients, the practical implication is to version the source once, generate client-specific packages, then test behavior, access, and evidence in each host.
Limits and uncertainty
GitHub presents implementation examples and recommendations, not comparative measurements of skill portability, reliability, or time saved. It does not report an evaluation of Proof Agent’s defect-detection rate or the Data Forge workflow’s production outcomes. The verifier example performs static diff review and explicitly does not run code or tests. Skills also inherit the host’s available tools, models, credentials, and permissions, so the guide does not establish that one package will behave identically across clients.
Skill to build now
Choose one recurring task with clear inputs and outputs. Put its instructions in a SKILL.md, keep project-specific names and schemas in a separate manifest, and specify what a reviewer should see. Test it in a second client, confirm its required tools and permissions are actually available, then add a CI check for package drift. Keep merge-blocking behavior in repository rules rather than relying on the skill’s wording.
Reader takeaway
A portable skill packages repeatable judgment, not execution rights. Build the instructions once if the work is bounded and reusable, but treat host permissions, client packaging, human approval, and verifiable checks as separate parts of the system.