Skills replace prompts.
Governance replaces improvisation.

The problem is not prompt quality

Prompt engineering is useful. A clear request can improve a single interaction, and task-specific context belongs close to the task. The architectural failure begins when an organisation treats a copied prompt as a production capability.

A recurring prompt usually has no stable identity, accountable owner, version, dependency record, qualification evidence or revocation path. People edit local copies, omit inconvenient steps and combine the instructions with different models, data and tools. The text may look consistent while the effective capability changes on every run.

This is the same category error described in Frameworks Are Not Architecture: an implementation detail is allowed to stand in for the governed system. A longer prompt does not repair that boundary. It merely hides more operating logic inside an informal interface.

A skill is a capability contract

The emerging Agent Skills open format packages specialised instructions and resources in a folder centred on a SKILL.md file. OpenAI's skills guidance similarly describes a reusable workflow with a name, activation description, instructions and supporting resources. Those conventions are valuable because they make procedural knowledge portable and versionable.

For governance, the file format is only the container. The important object is the capability contract around it. A production skill should answer:

• Purpose: which decision or job does this capability support?
• Activation: when should it run, and which situations are explicitly out of scope?
• Inputs: what data, provenance, freshness and classification are required?
• Method: which steps, decision points and quality checks are mandatory?
• Resources: which templates, schemas, reference sources, scripts and tools may be used?
• Authority: what may be recommended, prepared, approved or executed—and by whom?
• Output contract: which structure, citations, confidence boundaries and validation results are required?
• Evidence: what must be retained so another party can reconstruct the run?
• Lifecycle: who owns, reviews, versions, qualifies, suspends and retires the skill?

Progressive disclosure solves context loading, not governance

The Agent Skills model uses three levels of progressive disclosure: a small catalog entry for discovery, the full instructions when activated, and supporting resources only when required. The client implementation guide explains how this keeps the base context small while allowing specialised material to load on demand.

That mechanism improves context efficiency and discoverability. It does not prove that the selected skill is appropriate, current, safe or authorised. Activation is a routing decision. Qualification is a governance decision. Execution authority is a separate runtime decision.

Skills do not inherit unlimited authority

NIST's tool-use taxonomy distinguishes read-only, constrained-write and write access across trusted and untrusted environments. That distinction belongs in skill qualification. The same procedural skill can have radically different risk when paired with a read-only evidence API, a production change interface or unrestricted computer use.

The 2026 NIST NCCoE agent identity and authorization concept paper frames open questions around least privilege, dynamic authorization, delegated authority, human binding and tamper-resistant audit. A governed skill should preserve those questions as explicit deployment decisions instead of assuming that good instructions compensate for broad credentials.

The effective permission for a run should be the intersection of the requesting principal, task, agent identity, skill eligibility, tool, resource, data class, environment, time and approval state. A skill may narrow that grant. It must never widen it.

Build a lifecycle, not a prompt library

A folder full of reusable instructions is useful, but it is not yet a governed capability system. Production skills need a lifecycle:

1. Propose. Define the reader or operator problem, intended outcome, owner and boundary.
2. Design. Separate stable procedure from runtime context and enforceable platform controls.
3. Review. Inspect instructions, scripts, dependencies, external calls, licenses and data handling.
4. Qualify. Test representative, adversarial and failure cases in the intended model-tool-environment combination.
5. Approve. Record the eligible operating envelope, permission ceiling, evidence requirements and residual risk.
6. Publish. Give the approved version a stable identity, integrity record and controlled distribution path.
7. Observe. Capture activation, inputs, version, tool actions, checks, exceptions and observed effect.
8. Reassess or revoke. Trigger review when instructions, models, tools, policies, dependencies, threats or outcomes change.

OpenAI's current workspace guidance for skills makes the supply-chain issue concrete: uploaded skills may contain instructions, files and code; automated scanning is useful, but it does not replace source review, organisational policy or judgement. Workspace roles can govern who creates, uploads, shares, publishes and installs skills. Those administrative controls should connect to the organisation's capability registry and change process.

A worked example: evidence review

Consider a recurring request: “Review this control evidence and draft an assurance conclusion.” As a prompt, the request hides most of the operating model. Reviewers may use different criteria, accept screenshots without provenance, overlook the evidence period or phrase a draft as if it were an approved conclusion.

As a governed skill, the workflow can require a control identifier, owner, test procedure, evidence period, system boundary and source provenance. It can separate collection, sufficiency assessment, exception analysis and conclusion drafting. It can require citations back to each evidence object and mark missing inputs as unresolved rather than filling gaps.

The skill may prepare an assessment. It should not accept residual risk or issue the final assurance opinion unless that authority is separately assigned. This is the same boundary developed in AI Can Draft the Assessment. It Cannot Own the Assurance Decision.

Qualification needs an operating envelope

“The skill passed” is not a useful assurance statement. Record what passed: instruction version, model or model class, tool versions, permission profile, data classifications, environment, test set, expected failure behaviour and evaluator independence.

Minimum qualification should include happy paths, missing or conflicting inputs, malicious or irrelevant embedded instructions, unavailable dependencies, excessive-action requests, stale references and attempts to cross the permission boundary. For consequential workflows, confirm the external effect independently rather than relying on the agent's own completion statement.

A change to prose may be editorial. A change to activation rules, scripts, tools, output decisions or permission assumptions may change the capability and should trigger risk-based requalification.

The skill record worth keeping

• Stable identifier, semantic version, owner and status.
• Purpose, activation criteria, exclusions and target users or agents.
• Required inputs, data classifications and provenance rules.
• Permitted tools and maximum authority—not embedded credentials.
• Dependencies with versions, origins, integrity checks and licenses.
• Required outputs, validation rules and retained evidence.
• Qualified model-tool-environment combinations and known limitations.
• Approval, review date, change history, monitoring signals and revocation route.

Where skills are the wrong abstraction

Do not turn every instruction into a skill. One-off questions, exploratory work and highly contextual judgement may remain prompts. Deterministic transformations may belong in ordinary software. Authentication, authorization, rate limits, segregation of duties and irreversible-action gates belong in platform controls. A skill should orchestrate or explain those boundaries, not impersonate them.

Skills also create maintenance cost. Excessive fragmentation makes discovery unreliable; oversized skills recreate monolithic prompts; overlapping skills create inconsistent routes; invisible auto-activation can surprise users. Prefer small, coherent capability units, explicit ownership and observable activation.

Open questions

• Which changes require full requalification rather than targeted regression testing?
• How should equivalent skills from different providers declare comparable capability and risk?
• Who can approve a skill for a higher-impact permission profile?
• How should organisations preserve evidence when a proprietary client controls activation?
• When should a frequently invoked skill become deterministic software or a formal service?

Next concept: structure the decisions inside the skill

A governed skill makes a workflow reusable, but repeatability alone does not make its decisions defensible. The next layer is decision structuring: explicit alternatives, constraints, assumptions, contradictions, evidence and reconsideration triggers. The practical bridge is already visible in From Policy Hierarchies to Controls, where intent becomes a testable chain of owners, triggers, tests and evidence.

Primary references

1. Agent Skills — overview and open format.
2. Agent Skills — client implementation and progressive disclosure.
3. OpenAI Academy — Using skills.
4. OpenAI Help Center — Skills in ChatGPT.
5. NIST — Lessons Learned: Tool Use in Agent Systems.
6. NIST NCCoE — Software and AI Agent Identity and Authorization concept paper.