Agent Skills vs Prompts: When to Use Each

Every Friday, you ask an AI assistant to turn work notes into a weekly update. You keep repeating the same rules: separate completed work from plans, keep blockers visible, and never invent a deadline. This week's facts change; the reporting rules do not.

A saved prompt may be enough. An Agent Skill becomes worth considering when you want those recurring rules maintained as a reusable package for an agent that supports it. A Skill does not eliminate prompting, supply missing facts, or guarantee that the report is correct.

The Agent Skills overview describes a folder-based format for reusable knowledge and workflows. That is the technical meaning of “Skill” here, not a general claim that the model has learned a new ability through training. Format details were checked on September 7, 2026.

Compare what stays fixed and what changes

A prompt can be long and reusable. A Skill can be short and contain only instructions. Length is not the distinction. The practical difference is how recurring guidance is stored, made available and maintained.

Try the recurring request before building a package

Here are fictional weekly notes:

Help-page draft completed on Monday.
Review requested from Mina; no reply yet.
Publish after review. No publication date agreed.
Search bug reproduced; fix not started.

For a one-time update, this request states enough of the job:

Turn these notes into a weekly update with three sections:
Completed, Waiting on others, and Next work.
Preserve the difference between finished work and planned work.
Do not invent owners, dates, approvals or progress.
If an essential fact is missing, mark it as not confirmed.

[Paste this week's notes.]

A report that says “Mina approved the draft; publish Friday” fails twice. Asking for a polished report did not authorize either invention. Your reference checks are that the draft is complete, the review is outstanding, publication has no agreed date, and the bug is reproduced but not fixed.

If you only write this update occasionally, save the request in a document and paste it when needed. That gives you reusable instructions without introducing a new installation or maintenance task.

A Skill stores the recurring part separately

For a supporting agent, the same reporting rules could be stored in a file named SKILL.md inside a folder named weekly-update. The format specification requires a name and description in YAML metadata, followed by Markdown instructions.

This is a minimal authored design example, not an installed Skill or a benchmark result:

---
name: weekly-update
description: Turn work notes into a factual weekly update. Use when drafting a recurring weekly status report from supplied notes.
---

# Weekly update

Read the supplied notes. If none are provided, ask for them.

Write three sections:
- Completed
- Waiting on others
- Next work

Keep planned work separate from completed work.
Do not invent owners, dates, approvals or progress.
Mark essential missing information as not confirmed.
Before returning the report, check each status against the source notes.
Return a draft; do not send it to anyone.

This week's notes do not belong permanently in those instructions. If you bake “Mina has not replied” into the Skill, it can become stale next week. Supply the new facts with each request; maintain the recurring process in the package.

Now the current request can focus on the variable input: “Use the weekly-update Skill to draft this week's report from these notes.” The agent still needs to find and follow the Skill. Follow your chosen client's installation and invocation instructions; creating a folder somewhere on your computer is not enough to establish that it is available.

Packaging does not replace testing

The format supports discovering a short description before loading the fuller instructions when needed. This can keep extensive reusable guidance out of unrelated tasks. It does not prove that every client will activate the right Skill for every wording of a request.

Use the same fictional notes to compare the saved prompt and the Skill. Look for the exact facts above, not just matching headings. Then remove the notes entirely: does the workflow ask for input, or produce a fictional status report? Finally, provide a confirmed review and see whether the report changes only the affected status.

These are suggested acceptance cases. We have not measured this sample across clients, so there is no claimed accuracy or speed improvement. Anthropic's engineering account of Skills likewise recommends starting from representative tasks and observed shortcomings rather than assuming a large package is better.

A Skill may also contain scripts. Read what they do before using a package from someone else, especially if it requests file access or external connections. Instructions about writing a report are different from code that sends it. The package's presence is not permission to perform every action it mentions.

When is a Skill worth maintaining?

Consider a Skill when several pieces recur together: reporting rules, a template, examples of acceptable results, or a procedure that uses tools. A single maintained package gives you a place to update those pieces and repeat the checks after a change.

Stay with a saved prompt when the task is occasional, the rules are short, or your app does not support the format. If the instructions are unclear, moving them into a file will not resolve that ambiguity. First get one report you can check; then separate the recurring guidance from the facts that change each week.

References

• Agent Skills overview: the reusable format and progressive loading model.
• Agent Skills specification: required metadata, instruction files and optional resources.
• Anthropic: Equipping agents for the real world with Agent Skills: development, evaluation and security considerations.