A skill is "an organized collection of prompts and instructions for an LLM" (OpenAI n.d.). That framing is correct but incomplete. The moment a skill runs, it spends capability: it executes code, reads and writes files, reaches the network, and uses credentials. The right first-class frame for a 2026 skill is therefore not the prompt — it is the sandbox.

Agent control in 2026 spans three registers:

1. Probabilistic — prompts, system instructions, alignment (what the model is trained to do).
2. Explicit-deterministic — hooks, permission classifiers, wire-level policy (what the harness enforces).
3. Implicit-deterministic — a skill's tool-scope, an MCP server's surface, a schema (what the design permits at all).

Skills live in (3). A skill with a restricted tool list cannot exfiltrate a file not because a policy refused it but because the action was never on the menu. That is a sandbox boundary expressed as authoring convention.

The SKILL.md convention (Anthropic-originated) is the closest thing to a cross-harness standard, read by Claude Code, Copilot CLI, and OpenCode (CLI coding agents, 2026 Q2). OpenAI Codex ships skills as bundled, reusable behaviours (e.g. a setup-demo-app skill) (OpenAI n.d.). GitHub ships gh skill — a search/preview/install/publish/update lifecycle for skills sourced from repositories, shipped as a preview command ("subject to change without notice") not yet present in a stable gh release (GitHub n.d.). The unit is converging; the governance is not.

The reference decomposition: "sandbox" names at least four isolations — compute boundary, filesystem custody, network egress, secret custody — and "capability is structural; safety is declarative" (Agent sandbox architectures). Splitting filesystem into read and write gives the five axes the operator actually reasons about. Every skill can be scored on them:

The central observation: a skill's tool-list restriction is a sandbox policy written in the skill, one register earlier than the harness. But it is the weakest of the three registers — it constrains what the model is offered, not what the process can do. The corpus reference axiom holds: filesystem AND network isolation are both required, and the compute boundary alone is "a launchpad" (Agent sandbox architectures). So a skill's tool-scope is necessary context hygiene, never the security boundary.

Two failure modes the sandbox notes make concrete, both relevant to skills:

• The credential axis is the asymmetric risk. The secret-custody "empty cell" — a locally-run agent that materialises secrets only at approved-host egress — is unoccupied as a product, and the documented containment incidents land exactly there (Agent sandbox architectures, Containment mapping). A skill that calls an authenticated API inherits this: if the credential is readable, a prompt-injected skill exfiltrates it.
• Skill inputs are tainted. "If a third party could have written any part of it, it's tainted" (Tainted data in LLM pipelines). A skill that reads logs, issues, or tool output is reading attacker-writable text; its tool-scope is the only thing bounding the blast radius when that text is interpreted as instructions.

The permission story that closes the gap is three-layer — identity to session scope to wire-level — and the MCP authorization gap is real: the MCP spec makes auth optional and excludes stdio transports (the common dev case), so most skills reaching MCP tools run with session-wide grants and no per-operation scope (Agent permission guardrails).

The sandbox lens is one of nine surfaces a skill is in contract with when it ships. In practice — observed by porting a populated agent directory into a vetted skill repo — the surfaces line up like this:

1. Invocation. The description frontmatter is the only thing the model sees pre-invocation; trigger logic does not live in the body.
2. Permissions. allowed-tools as least-privilege (marked (Experimental) in the spec — see disputed), matched to what the body actually does.
3. Sandbox. Compute / fs-read / fs-write / egress / credential — the five-axis decomposition this note is built around.
4. MCP. Server-independence is a design constraint: a vendored skill works without the MCP server reachable; MCP tools are accelerants that degrade gracefully.
5. Hooks. No silent dependency on settings.json automation; any required hook is documented and optional.
6. Skills composition. Anatomy is SKILL.md + optional scripts/ (deterministic code), references/ (depth docs loaded on demand — one level only, see disputed), assets/ (output templates), agents/ (sub-agent definitions); bodies stay under ~500 lines.
7. Memory. Recalled memory is background context, not user instructions. A memory naming a file is a claim, not a guarantee — verify before acting; write only on explicit intent.
8. Providers. Hard provider/model assumptions are stated; otherwise the skill reads as portable across Claude / LiteLLM-fronted providers / local Ollama.
9. Remote. Headless by default; the distribution channel is named so reviewers can score the right egress profile.

Two independent authoring tracks landed on this same decomposition in the same week — the surfaces appear to be approximately stable.

Skills are prompt-cache-aware primitives — named templates with tool scopes that expand at call time (Claude Code features, 2026 Q2). Three corpus facts make composition cheap: prompt caching is opt-in with a 1-hour TTL (ENABLE_PROMPT_CACHING_1H, 2.1.108) and dynamic system-prompt sections can be excluded for cache reuse (--exclude-dynamic-system-prompt-sections, 2.1.98) (Claude Code workshop); the CLAUDE.md hierarchy is itself a cache strategy (global-static / repo / session-dynamic) (Agentic workflow); and context compression outperforms full-context agents on long-horizon tool use (Morning Brief, 2026-06-10). The open question the corpus poses and does not answer: at 1M context, is curated memory still necessary, or does it become the signal in a sea of raw context?

The unit of progress is the eval. OpenAI's framing defines success in four categories — outcome (did the task complete), process (right tools, right order), style (conventions), efficiency (no wasted tokens/commands) — and keeps the must-pass list small (OpenAI n.d.). The harness is layered: deterministic checks against JSONL traces (codex exec --json — "did it run npm install?"), model-assisted rubric grading with a structured --output-schema, and small prompt sets (10–20 cases) spanning explicit invocation, implicit triggering, contextual variation, and negative controls (OpenAI n.d.).

Read through this note's lens, "good context" for a skill is the minimal context that passes the must-pass checks — which is also the minimal sandbox surface. The efficiency goal and the implicit-guardrail goal point the same way: a skill that needs fewer tools and less context is both cheaper and safer.

gh skill gives skills a software lifecycle: search (discover), preview (test before install), install (deploy from a repo namespace), publish --dry-run (validate before release), update (bulk upgrade) (GitHub n.d.). preview and --dry-run are the testing/rollout seams — the place an eval suite (above) should gate. A skill rollout is then: eval locally to gh skill preview to publish --dry-run → publish → update across the fleet.

The lifecycle is not channel-neutral. The three distribution channels above (vendored / MCP-served / fetched-then-local) impose different rollout properties — vendored skills update with the repo, MCP-served skills update when the server does, gh skill update is explicit. Eval gates are identical; rollback semantics are not.

Verdicts produced 2026-06-24. correct = the cited term/claim was found in the cited corpus note by REPL (wal-sh.site.org/read-all + slurp + substring); attributed = sourced from a fetched primary document, not independently executed.

Three disputed verdicts were added 2026-10-29 from a re-check against primary sources, and are the last three claims below. disputed here means a primary source contradicts the claim as written without settling what should replace it; each :FINDING: records what was fetched and what it said. The claims they dispute are flagged inline at the point they are made rather than silently rewritten.

The unit of design is the set rather than the skill: a skill that contradicts or duplicates another corrupts the shared vocabulary every agent in the repo assumes. A meta-skill is a skill whose argument is other skills. Four kinds, by what they check:

• Eval — does the skill still work? Invoke it, or dry-run its commands, and confirm the described outcome. Catches drift from the code it documents (a renamed target, a moved path).
• Audit — coverage and freshness. Which boundaries have no skill; which skills cite files or URLs that no longer exist; which overlap.
• Consistency — contract conformance: frontmatter shape, a usage block, rationale present. Mechanical; a linter for SKILL.md.
• Tone — house-style conformance over the skill corpus rather than the prose corpus.

An earlier draft (2026-06-01) recorded two facts that no longer hold. It described the local contract as plain markdown with no YAML frontmatter; the skills in this repo now open with YAML frontmatter carrying name, description, and user_invocable (see research-audit/SKILL.md), which is the SKILL.md convention above. It also stated that no meta-skill existed. Three do. skills-guardrail audits and enforces resource constraints on skills (egress, process, filesystem access): the sandbox lens applied to the skill corpus, and the audit kind above. research-audit is a read-only tone and annotation check over published notes. /skill-doctor reports on a skill's structure and triggering: the consistency and eval kinds. What remains open is a tone check over .claude/skills/** itself.

The tension the taxonomy resolves is between messy creation and a curated set. Skills should be cheap to write; friction kills the habit, and an unwritten skill is procedural memory lost. The cost of mess is paid not at creation but in composition: drift, overlap, contradiction, staleness. The resolution is not gatekeeping the write path. It is a messy write path and an audited read path, with meta-skills reconciling the set on a cadence.

• Is a skill's tool-scope observable as a sandbox profile — can a harness derive the compute/fs/egress/credential footprint from a SKILL.md and refuse it? Partial answer: where authors carry fs-access=/=egress=/=process-access keys in custom frontmatter, the footprint is already declared; the gap is harness adoption of a standard schema.
• Does 1M context enable a new class of whole-repo skills, or just make existing skills cheaper?
• Where does eval "efficiency" (minimal context) and security (minimal surface) diverge, if ever?
• When the same framework ships under both generic-label and human-name invocation surfaces, does triggering quality degrade (description collision), or does the disambiguation by conversational register hold?

Core external links:

• anthropics/skills — the SKILL.md convention.
• Antithesis: Agent Skills (2026).
• OpenAI: Evaluating agent skills.
• gh skill — deploy / rollout / test lifecycle.

Internal:

• Agent sandbox systems — the four-isolation decomposition.
• Containment mapping.
• Agent permission guardrails.
• Annotation systems — the verdict methodology.