Field Guide

Prompt vs skill vs workflow: choose what your task needs

Research-based guidance; original hypothetical examples; decision worksheet not yet validated through repeated use

Use a prompt for the present request, a project instruction for context and rules that belong to one initiative, a skill for a reusable procedure, and a workflow for dependent steps. Choose by the work you need to repeat. These pieces can work together; you do not have to move every task through all four.

This guide gives you a decision table and one weekly-update task expressed in each form. The examples are hypothetical, and the selection method is Today’s Worker’s editorial recommendation. We have not established that it reduces effort or improves results through repeated reader use.

Choose what needs to remain available

These are functional distinctions. Product names and implementations vary. Anthropic’s explanation distinguishes initiative context from reusable procedural knowledge. OpenAI’s Projects documentation describes keeping chats, files and project instructions together. Neither description guarantees that a saved rule will be followed.

A prompt need not be disposable. You can save and reuse it. The question is whether a saved request is enough, or whether you also need managed context, a procedure or ordered execution. Nor does putting a rule in a project mean every relevant detail will reach every response. Inspect the current product’s documentation and the actual result.

Use the same weekly-update task in all four forms

Imagine you prepare a weekly project update from these invented notes:

Note A: The outline was approved on Monday.
Note B: The design needs review. No owner is recorded.
Note C: The proposed launch date is Friday; approval is pending.

The required update has four fields: confirmed decisions, actions, owners and unresolved items. A proposed date must not become an approved date. A missing owner must remain unassigned. These are example requirements, not facts about an actual team.

1. Start with a task prompt

Use only Notes A–C to prepare a weekly update with confirmed decisions, actions, owners and unresolved items. Do not invent names or approvals. Label missing owners “unassigned.” Preserve the distinction between a proposed date and an approved commitment. Return the update, then list anything you could not establish.

This may be enough for a one-off update. The prompt contains the current evidence and the checkable output standard. Use acceptance criteria to define your real task before choosing a more elaborate setup.

2. Keep project-specific rules with the project

If this initiative produces updates every week, you might keep its approved terminology, date convention and owner roster in project context. Keep each week’s notes separate from those standing references.

For this project’s status updates, use the supplied owner roster. A person appearing in the roster is not evidence that they own an action. Use “unassigned” unless the current notes explicitly assign the work. A proposed launch date remains proposed until a source records approval.

That last distinction matters. Context can tell the assistant who exists; it cannot supply an assignment the notes never made. If the roster changes, update the authoritative reference. Copying it into several separate instructions creates several places to maintain.

3. Package the recurring procedure as a skill

If you prepare comparable updates across initiatives, separate the method from the local facts. A skill could specify the following procedure, while each project supplies its own notes and roster:

Procedure: prepare a source-bounded project update
Inputs: current notes; project terminology; owner roster if available.
Steps:
1. Extract explicit decisions and proposed decisions separately.
2. Extract actions and only the owners explicitly assigned to them.
3. Return decisions, actions, owners and unresolved items.
4. Check each entry against a supplied note.
Missing input: flag what is absent; do not infer approval or ownership.
Checks: no invented owner; no proposal promoted to approval;
        every material statement traceable to an input.

This is a procedure sketch, not an installed skill or a tested claim of reliability. A real package needs the format and resources required by its host. The Agent Skills overview describes a folder with a required SKILL.md and optional supporting files. Having that folder does not establish that the procedure works.

Do not put one client’s names or private notes in a general skill. Reuse the method; supply authorized local context for the specific task. If a correction recurs, use the correction guide to decide what the procedure or its checks should change.

4. Add a workflow when dependent stages need coordination

The task becomes a workflow when it needs stages such as obtaining authorized notes, checking required inputs, drafting an update, reviewing disputed entries and saving an approved artifact. Someone or something must coordinate that sequence.

1. Obtain the current authorized inputs.
2. Run the update procedure.
3. Check the draft against those inputs.
4. Route unresolved approval or ownership questions to the responsible person.
5. Save the reviewed version and read it back.

Decide in advance whether an unresolved item can remain labeled in a draft or must stop the process. Sending the update is a separate action that requires the appropriate authority. A generated draft and a saved file are different results.

In Anthropic’s architectural distinction, workflows follow predefined paths, while agents can choose their next steps dynamically. An agent might execute part of this workflow, but that does not remove its source, review or permission boundaries. The article’s implementation examples are older; use the distinction, not its tool list, as the reference here.

Inspect one expected result and one failure

These entries are written teaching examples, not observed model outputs. You can use the same inputs as a small test: did the assistant preserve uncertainty and avoid inventing ownership? A more elaborate container has not earned its place if it still fails those checks.

Then change one input: record an explicit design owner in a later test. The instruction should allow that assignment. A rule that always returns “unassigned” would satisfy the missing-owner example while failing the actual job.

Ask five questions before expanding the setup

1. Has the same instruction or procedure recurred, or are you still discovering what the task requires?
2. Is the context specific to one initiative, or can the method transfer if each project supplies its own facts?
3. Does the procedure require reusable resources, examples, scripts or checks beyond a saved request?
4. Are there dependent stages, handoffs or external actions that need explicit gates and state?
5. Can you compare the larger setup with a smaller baseline using similar inputs, the same acceptance checks and recorded review effort?

Write the reason for expanding and the next observation that would support or contradict it. This is a selection check, not evidence that the larger setup will perform better.

Copy the decision worksheet

Task I need to repeat:
What changed on the last attempt:
Current-task inputs:
Facts or rules local to one project:
Procedure that could transfer to another project:
Dependent stages or external actions:
Output and acceptance checks:
Smallest container to try:
Evidence that would justify a larger one:
Next comparable test and unresolved limits:

Keep the smaller form when the reason to expand is unclear. A local context problem may need a better project reference. A repeated procedure may need a skill. A failed handoff may need a workflow checkpoint. Those are different changes, and adding all three makes it harder to tell which helped.

Our recommendation is to expand only when a specific reuse, context, resource or dependency need justifies the extra work. Anthropic recommends beginning with a simple solution, but this worksheet is our interpretation, not its tested standard. Record setup, review and correction effort when comparing alternatives. A single passing example does not establish transfer across tasks, products or people.

If the same correction has already recurred, Fix It Once can format it into a scoped instruction, checks and a test prompt. It does not install a skill, run the procedure or verify a future output. Keep the rule only if later use gives you a reason to keep it.