A skill is "an organized collection of prompts and instructions for an LLM" (??, ????). 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. This note reads skills through that lens, then covers the caching/context economics that make them cheap, and the eval + deployment tooling that makes them testable.

The SKILL.md convention (Anthropic-originated) is the closest thing to a cross-harness standard, read by Claude Code, Copilot CLI, and OpenCode (??, a). OpenAI Codex ships skills as bundled, reusable behaviours (e.g. a setup-demo-app skill) (??, ). GitHub ships gh skill — a search/preview/install/publish/update lifecycle for skills sourced from repositories (??, a). 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" (??, a). 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" (??, a). 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 (??, a, ??, a). 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" (??, a). 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 (??, a).

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, 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), 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.

Sandbox is one surface among nine; the lens is necessary but not sufficient. (The convergence signal: 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 (??, a). 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.114) (??, a); the CLAUDE.md hierarchy is itself a cache strategy (global-static / repo / session-dynamic) (??, a); and context compression outperforms full-context agents on long-horizon tool use (??, a). 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? (??, a)

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 (??, ). 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 (??, ).

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) (??, a). 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.

A skill set is an agent's externalised procedural memory. 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. Something has to operate on the set. 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? (??, a)
• 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.