When should a repeated AI task become an agent skill?

An operations team asks an AI assistant to check this week’s promotion SKU list. Next Monday the same kind of request arrives, with a new file and market. Someone proposes saving the entire conversation as an “agent skill.” The useful question is whether the trigger, required inputs, steps, and definition of a correct result repeat, not whether the topic appears twice.

OpenAI’s Build skills documentation describes a skill as a package of task-specific instructions, resources, and optional scripts. It explains that ChatGPT and Codex can select a skill from its name and description, then load its full SKILL.md when needed. A skill is a reusable workflow, not a new permission, a background memory of past customers, or proof that the underlying data is current.

The context map shows what material enters one model request. The tool contract controls an operation’s schema and backend checks; MCP intake reviews an integration’s exposed capabilities. This page asks whether a workflow is stable enough to package and maintain. If it needs external state, the skill must request it from a named source rather than pretending to remember last week’s file.

Pass five gates before writing the skill

Collect several recent instances of the proposed task, including at least one difficult or failed one. Write the observed evidence in the card below. These five gates are a site decision method, not fields that OpenAI requires in SKILL.md.

Gate	Evidence that supports a skill	Signal to narrow or defer
Trigger	A positive request and a nearby negative request can be told apart in one concise description.	“Help with purchasing” could mean lookup, negotiation, legal review, or approval.
Inputs	Required files, dates, scope, and authoritative sources can be named; a missing input has a known next step.	The agent must guess which account, market, document version, or rule applies.
Steps	The order and important branches repeat; any script has defined inputs and failure behavior.	Each run invents a different investigation or depends on broad judgment.
Acceptance	A reviewer can check output fields, evidence pointers, and serious failure conditions on representative cases.	“Looks helpful” is the only pass rule.
Maintenance	A named owner can update the instructions and tests when the source or process changes.	Nobody owns stale rules, failed runs, or retirement.

Failing one gate does not mean the task should never use AI. It may need a one-off task brief, a narrower subtask, a deterministic program, or a human decision. In particular, do not turn an unstable legal or financial judgment into a skill just to make it appear repeatable.

Choose the smallest reusable form

If the job is a fixed calculation with stable machine-readable inputs, implement and test a script or ordinary workflow. A skill may then tell an agent when to run that script, which approved inputs to use, and how to review exceptions; it should not replace a deterministic check with prose. If the job needs task-specific choices and those choices have stable bounds, a skill can be useful. If the task occurs once or its trigger cannot be distinguished from adjacent requests, keep instructions local to the task while collecting examples.

OpenAI documents SKILL.md with required name and description metadata; scripts, references, and assets are optional. Put the key use case and exclusions early in the description because implicit selection relies on it. Keep the body focused on inputs, ordered actions, stop conditions, output, and checks. The owner, test date, change signal, and retirement decision in this site’s card are maintenance choices, not claims that OpenAI requires a version or expiry field in skill metadata.

A skill can say “call the approved catalog reader,” but it cannot grant that reader access. The backend still checks identity and scope. It can say “use the current catalog snapshot,” but it does not itself store that snapshot as reliable long-term memory. Use the memory lifecycle method when deciding what facts may persist between runs.

Test the description and the work, not just the folder

Run a positive prompt that should select the skill, a close negative prompt that should not, and a request with a required input missing. Description matching does not guarantee implicit selection; record missed and false activations, then revise the description and boundaries. A critical workflow can invoke the skill explicitly. Run representative task cases through the workflow too. Check whether the assistant asked for missing material, used the approved source version, produced the agreed fields, and stopped at the declared boundary. Compare against the current manual or scripted baseline; a skill earns its place when it saves repeated explanation or reduces errors without broadening the task.

Record how a change is detected: an input format, policy, source system, script, or acceptance rule changes; a negative prompt starts selecting the skill; or a normal case fails. Review the skill then. “Installed” is not a quality state. A long folder of examples with no owner can become a source of stale instructions.

Example one: reconcile weekly promotion SKUs

A fictional retailer receives a promotion CSV each week, an approved catalog snapshot, and a market code. The repeated job is to identify missing SKUs, duplicates, discontinued items, and market mismatches, then produce an exception sheet with source-row references. The trigger is narrow: “check this week’s promotion SKU export against the approved catalog.” It excludes setting discount percentages, approving a campaign, and editing the catalog.

The skill can validate the week and market, locate the approved snapshot, run a deterministic comparison script, and ask a human to review exceptions. A missing catalog revision blocks the run instead of letting the assistant reuse last week’s data. The team tests one ordinary file, one duplicate, one market mismatch, and a nearby request to authorize a price change. The first three should produce checkable rows; the price request should not select this skill. An operations owner maintains the card when the CSV schema or catalog status codes change.

Example two: supplier terms differ across regions

A fictional sourcing team often asks an assistant to “review supplier terms” from several regions. The documents vary in language, jurisdiction, renewal structure, and negotiated exceptions. No short, stable sequence can decide whether a clause is legally acceptable. Creating a broad “supplier approval skill” would hide the missing legal judgment.

One subtask does repeat: extract explicitly stated effective, renewal, notice, and termination dates from supplied terms. A narrow skill can require the document revision and region, output each date with the exact clause location and source wording, mark ambiguous or absent dates, and stop before legal interpretation. Test a clear date, a date embedded in a renewal clause, and an ambiguous “within thirty days” phrase. A legal reviewer checks the extraction and decides what the clause means for that region. If a user asks “can we sign this?”, the extraction skill may prepare a date table, but it must not deliver an approval.

Boundary

This card decides whether to package a repeatable instruction workflow and how to test its selection and results. It does not authorize tools, certify an MCP server, preserve personal or business facts between sessions, or replace a human professional decision. The examples are invented. Keep only synthetic case IDs, sanitized summaries, and controlled evidence pointers in the browser-saved card; store actual supplier documents, commercial terms, and customer files in approved systems.