What is Skill?

How It Works

Skill in this entry means the open Agent Skills file format, not every capability that a model, tool, plugin, or agent framework happens to call a skill. The generic idea of reusable agent capabilities predates the format. In the open format, each skill is a directory whose required entry point is `SKILL.md`: YAML Frontmatter supplies at least `name` and `description`, and the Markdown body supplies instructions. Optional `scripts/`, `references/`, and `assets/` directories can carry executable helpers, detailed documentation, schemas, templates, or other resources. Fields such as `license`, `compatibility`, and string-valued `metadata` can describe the package; `allowed-tools` is experimental and cannot be treated as a universal authorization contract. Compatible runtimes use Progressive Disclosure. During Discovery, the runtime exposes compact metadata so the model can decide whether a skill is relevant. During Activation, it loads the selected `SKILL.md`. During Execution, the agent may read referenced files or run bundled scripts only when needed. This reduces initial Context Window cost, but activation is still a model and runtime decision. A vague description can cause false negatives; an overly broad one can cause false positives or consume context on unrelated tasks. Explicit invocation, implicit matching, directory scope, precedence, and context budgets remain implementation-specific. A Skill is not the same as a Prompt, ambient project guidance, Tool, MCP Server, Plugin, or Agent. A Prompt is an instruction in a particular interaction. Project guidance applies persistently within a configured scope. A Tool exposes an operation that code can execute. MCP standardizes how applications exchange context and invoke external capabilities; it does not define the Agent Skills package or automatically grant permission. A Skill can be instruction-only, call built-in tools, or guide an Agent through MCP Tools. A Plugin can distribute Skills and integrations, but its manifest and installation behavior belong to the product that defines it. The Agent or Host still owns model selection, context assembly, credentials, authorization, confirmation, side effects, and recovery. File portability is not behavioral equivalence. A package that satisfies the core specification can still depend on product-specific tool names, filesystem locations, optional metadata, network access, shell utilities, model behavior, or sandbox semantics. Before reuse, record a compatibility matrix for the target Runtime and test resource paths, dependencies, supported fields, Trigger Behavior, Tool Calls, outputs, cancellation, and failure handling. Keep nonportable extensions separate and declare prerequisites rather than silently assuming them. Treat every Skill as a software and instruction supply-chain artifact. Pin the source repository and Commit or package version, compute an Archive Hash, review every file and transitive dependency, verify License and Provenance, and reject hidden binaries, unexpected network access, secret collection, or instructions that weaken higher-priority policy. Run untrusted scripts in a constrained Sandbox with Least Privilege, scoped credentials, restricted egress, explicit approval for consequential actions, logs, time and budget limits, and a rollback path. A readable `SKILL.md` does not make bundled code or fetched content trustworthy. Evaluation must cover both routing and execution. Build positive, indirect, incomplete, negative, and adversarial Trigger cases; measure Trigger Precision and Recall separately from Task Success. Then test input validation, expected artifacts, prohibited actions, tool choice, permission enforcement, idempotency where required, error recovery, output quality, token use, latency, and cost. Bind results to a Skill Identity containing the source, artifact hash, Specification snapshot, Runtime and Model Revision, tool and dependency versions, Policy Revision, and Eval Suite Revision. A passing happy-path example does not prove portability, security, or reliable autonomous execution.

Key Characteristics

• File-based package — a directory contains required SKILL.md metadata and instructions plus optional scripts, references, and assets
• Progressive disclosure — runtimes can expose metadata first, load full instructions on activation, and fetch resources only when needed
• Workflow layer — a Skill encodes procedures, decision points, constraints, and output requirements rather than providing protocol connectivity
• Runtime-dependent behavior — invocation, tool names, optional fields, permissions, context budgets, and sandbox semantics can differ by client
• Evaluable routing — positive and negative Trigger cases must be measured separately from execution quality and task acceptance
• Supply-chain artifact — source, license, hash, dependencies, permissions, network access, review, and rollback require lifecycle governance

Common Use Cases

1. Repository workflows — package local architecture rules, review criteria, test commands, and deliverable formats for a specific codebase
2. Document operations — combine instructions, deterministic scripts, templates, and format-specific references for repeatable file work
3. Operational runbooks — guide diagnosis and remediation while leaving live access and authorization to approved tools and systems
4. Domain review — encode legal, security, data-quality, or content checklists with evidence requirements and escalation boundaries
5. Tool orchestration — teach an Agent when and how to sequence built-in or MCP Tools without embedding credentials or authorization in instructions

Frequently Asked Questions

Related Tools

Related Terms

Related Articles