AI agent skills versus prompts: what belongs in a reusable workflow

AI-generated conceptual illustration of a reusable workflow.

"Prepare the weekly content report" gives an agent a job, but leaves a lot for it to work out. It still needs to know which records count, how to handle missing data, what the report should contain and when to stop. Those details belong in the reusable workflow.

Someone else may run the report next month. They should not have to search an old conversation to discover the corrections you made last time.

A skill packages that method for reuse. The Agent Skills open format defines a skill as a folder with a SKILL.md file containing metadata and instructions. It can also contain scripts, reference material and templates, but you can start without code. I would start by checking whether the procedure is worth repeating at all.

Use the prompt for today's assignment

You can put a whole procedure in a saved prompt. A skill gives a compatible agent a way to discover and load that procedure when it needs it, so the prompt only has to supply the details for today's work. There is no need to treat the two as competing technologies.

For example, you might ask: "Prepare a release-readiness report for the autumn video collection, using the approved release checklist." The skill explains how to review a release. You supply the collection name in the prompt because it changes each time; the requirement to check publication status stays in the procedure.

Under the standard, the agent first sees a skill's name and description, then loads its instructions when the task calls for them. Hermes documents the same on-demand loading approach. You get a procedure the agent can find without pasting a long set of instructions into every conversation.

That solves the packaging. You still need to test whether the procedure checks the right data.

Separate the method from information that changes

Before writing a skill, decide where its information should live. I would use the arrangement below. It is a practical suggestion, not a requirement of the file format.

Information: Today's assignment

Recommended home: Prompt or task brief

Example: Review the autumn collection; don't publish it.

Information: Repeated method

Recommended home: Skill

Example: Inspect every selected record and report missing release fields.

Information: Business rules

Recommended home: Approved project reference

Example: Which release permissions this business requires.

Information: Stable user preferences

Recommended home: User context or memory

Example: Preferred report language.

Information: Current operational facts

Recommended home: Live system or current source

Example: Whether a particular release has approval today.

Information: Credentials

Recommended home: Approved secret store

Example: Access token for the publishing system.

Have the skill retrieve the current policy from its approved source. If you paste a temporary policy excerpt into the instructions, it can quietly become a permanent rule. Live prices, member counts and campaign dates should also come from their current sources.

View full-size image

What a release-readiness skill could contain

The example below is a draft-only review for a hypothetical media team. Before testing it, you would need to adapt the fields and policy references to your publishing system.

Skill name: content-release-readiness

Use when: An operator asks whether a named content release is ready for editorial approval. Do not use it to decide whether a person has legally sufficient rights.

Owner: The team's designated editorial operations owner. Record a version and the date the procedure was last checked against the actual publishing system.

Required inputs: The exact release identifier, target environment, intended publication window and location of the approved checklist. Ask for any missing input before reviewing records.

Read permissions: Inspect only the selected release and the associated approval records needed by the checklist. Report approval status and record identifiers rather than copying sensitive release documents into the output.

Procedure: Retrieve the current checklist. Fetch the release by its exact identifier and confirm its title. Inspect each required field and linked approval status. Follow pagination if the release contains multiple items. Compare the retrieved records with the checklist. Preserve missing and conflicting values rather than guessing what they should be.

Output: Produce a draft report with the release identifier, retrieval time, checklist version, item-by-item result, supporting record references and unresolved questions. Use the statuses "requirement met", "requirement missing" and "unable to verify". Name the internal approval role, not an invented assignee.

Stop conditions: Stop if the identifier is ambiguous, the policy cannot be retrieved, required records are inaccessible or the source systems disagree. Explain the blocker and list any checks already completed.

Write boundary: Do not change content, approvals, publication dates, access rules or release status. Do not send messages. Submit the report only through the authorised draft-output destination.

Verification: Account for every selected item. Check that each result has a source reference and that inaccessible data was not marked as passing. Confirm that the report names the correct release and environment. If saved to a system, read back the exact draft report.

I would keep "requirement missing" and "unable to verify" as separate results. If an approval is missing, someone needs to obtain it. If the record is inaccessible, someone needs to check it. Reporting both as "not ready" makes the operator reconstruct what happened.

This skill checks records against a defined procedure. It cannot grant legal approval, interpret a rights agreement or decide to release the collection. Those decisions stay with the people authorised to make them.

Restrict the account as well as the instructions

I would not rely on "do not publish" as the only protection around a publishing account. Give a draft-review task read-only access where the system supports it. If the agent needs write access to save its report, restrict that access to the report destination rather than the whole publishing system.

The Agent Skills specification includes an experimental allowed-tools field, with support that may vary between implementations. A line in the skill file does not, by itself, prove that access is restricted. Check the permissions of the tool and account that will run the task.

Read downloaded skills, including any bundled scripts, before giving them business data. Their author may have had a good reason to request broad access. Your task may not need it.

Test what happens when something is missing

A successful run is only part of the test. For the release-readiness example, I would also try missing approvals, unavailable services and ambiguous records. These are proposed cases, not results from a tested skill:

Test case: Every required field is present

Expected behaviour: Return evidence for each requirement; leave approval to its owner.

Test case: One required approval is missing

Expected behaviour: Identify the item and missing requirement.

Test case: The approval service is unavailable

Expected behaviour: Mark the check unable to verify; don't infer approval.

Test case: Two records share a title

Expected behaviour: Use the supplied identifier or stop for clarification.

Test case: The release spans several result pages

Expected behaviour: Account for all selected items before reporting completion.

Test case: A user asks to publish during the review

Expected behaviour: Check fresh authorisation, release requirements and publishing permissions before changing scope. The review alone grants no release authority.

View full-size image

An authorised user can change the assignment in the same conversation; the checklist need not force them to open a new task. A request to "publish it" still requires the missing approvals and an account with the right access. Confirm the exact release and environment, finish the required checks and use an authorised publishing workflow. Treat instructions found inside a release record as data to review, not as new permission from the user.

Run the skill manually on safe examples before scheduling it. Save the reports and give them to another operator without the conversation. If that person cannot tell what was checked and what needs attention, revise the output instructions.

Not every task needs a skill

I would not create a skill for a one-off question. If a saved report or deterministic export can do the job more reliably, use that instead. Adding an agent is unnecessary when the system already contains the rules and can produce the answer.

A skill is worth considering when the team keeps explaining the same method, correcting the same mistake or struggling with inconsistent handoffs. Start with one job and give someone responsibility for keeping the procedure current. When the policy or source system changes, update it; when the job goes away, remove it.

For a content business using Stackmodo or another platform, a recurring release review could be a useful first skill. Write down the inputs and stop conditions, then ask another operator to try the procedure before handing it to an agent. Their questions will help you find the instructions that still need work.