When should a workflow become an agent skill?

Repetition is useful evidence, but not the decision

A team may repeat a task hundreds of times and still need an ordinary program. Another task may occur monthly yet require enough specialized judgment to justify a skill. Ask what stays stable across executions: the exact transformation, the decision procedure, or only the desired outcome. Those answers point to different implementation objects.

The Agent Skills specification supplies a small package format. It does not require a fleet controller before an author can create a useful folder. The additional contract below becomes valuable when another person depends on the behavior and cannot reconstruct the author’s assumptions.

Locate the judgment that callers keep rediscovering

A prompt expresses the current request. A tool exposes a callable operation. A deterministic program carries a transformation whose rules can be implemented directly. A skill teaches the agent how to approach a recurring class of work, including choices that depend on the evidence found during execution.

The boundary matters because each object has a different failure owner. If a file parser drops rows, fix the parser. If the agent selects the wrong analysis for a valid file, inspect the skill. If a request can alter an unauthorized account, the enforcing tool or runtime needs attention. Rewriting prose cannot repair every layer.

A release-note assistant with three separate jobs

Consider a hypothetical product team preparing notes for six repositories every fortnight. Its assistant reads merged pull requests, groups changes by user impact, and drafts release notes. The recurring judgment is deciding whether a change is user-visible and explaining its consequence without copying internal implementation chatter.

Fetching pull requests belongs behind an authenticated tool. Sorting changes by merge time belongs in ordinary code. Editorial categorization and handling ambiguous changes belong in the skill. Publishing the approved notes remains a separate operation with its own owner and authorization. Packaging all four as an undifferentiated “release helper” makes it difficult to know which promise failed.

Fill the capability selection card

Use one row per proposed capability, not per directory. The example is constructed for this guide and is not a report of customer results.

Field	Release-note drafting decision
Recurring judgment	Classify merged changes by user consequence
Required input	Repository scope, release interval, approved change records
Accepted output	Draft notes with links and explicit uncertain classifications
Exact helper work	Normalize identifiers and sort records
External operations	Read pull requests; publishing is excluded
Activation boundary	A request to draft notes for a specified release
Safe stop	Missing release interval or unavailable change evidence
Maintenance owner	Developer communications lead
Evidence before sharing	Representative accepted drafts and negative activation cases

The card exposes a useful disagreement: perhaps the team does not agree on what counts as user-visible. Resolve that editorial contract before teaching a model to apply it. A package cannot manufacture a stable organizational decision.

Prefer code where exactness defines success

When success means producing the same checksum, validating the same schema, or applying a known conversion, implement that operation directly. The skill can decide when to invoke the helper and interpret its result. Anthropic’s engineering explanation illustrates this division between procedural guidance and executable work.

Give the helper a narrow interface and a clear failure result. A script that silently downloads dependencies, changes global configuration, and then generates a report has expanded the package’s operating surface. Its convenience does not remove those dependencies from review.

Share only the promise you can maintain

Before distributing the first version, run a normal request, a neighboring request that should not activate it, and a request with missing prerequisites. Check the resulting artifacts and the path taken. These probes are a starting point, not a statistical reliability claim.

If no owner can update references when the product changes or explain a disputed output, keep the capability experimental and limit who depends on it. Ownership can be lightweight; it must still be identifiable.

Bound the decision and continue with authoring

This guide does not design tool authorization or durable workflow recovery. It decides which reusable behavior deserves a skill boundary. For the next implementation choice, use trigger descriptions that preserve neighboring intent and the division between instructions, references, and scripts.

The complete lifecycle appears in Skills in Production. This web guide is independently written and does not reproduce a manuscript excerpt.