Choose one business task with available inputs, checkable results, and a practical recovery path, then practice with a fictional operations note.
Prioritize a recurring task whose inputs are easy to gather, whose output can be checked against source material or clear rules, and whose errors a person can correct or undo. Frequency and staff time help you rank candidates; this table is a discussion aid, not a validated scoring formula. For a first exercise, let the Agent organize information only; do not authorize sending, business-system edits, or transactions.
Have the business owner answer each question, then discuss which task is worth trying first. No scoring is needed: frequency and staff time help prioritize, while input, review, and recovery conditions determine whether a task fits a first exercise.
| What to assess | Question for the owner | A useful starting signal |
|---|---|---|
| Frequency | How many times a week or month does this happen? | It recurs often enough to reuse a successful approach. |
| Staff time | About how many minutes does each run take, and which steps take longest? | Start with a recurring, time-consuming step that can be described clearly. |
| Input availability | Which files or fields are needed, and are you allowed to provide them to the Agent service? | Choose a small task that can use public or approved material. |
| Checkable output | Who can check the result against source text, business rules, or defined fields? | An owner can verify the key facts item by item. |
| Error recovery | If an error appears, can someone stop, correct it, or restore the prior state? | During the exercise, review a draft before it triggers any external action. |
Compare three candidates: summing weekly sales rows with fixed rules calls for a spreadsheet formula; turning campaign notes into a brief requires interpreting changing text, so a model can draft for a person to check; automatically approving refunds moves money, so leave it out of a first trial. Choose by task shape before choosing an Agent.
This fictional campaign task uses available notes, figures that can be checked against the source, and a draft for people to review. Give the note below to an Agent interface you already use.
Practice note (fictional): This week’s new-customer campaign had 38,000 impressions, an 8.2% add-to-cart rate, and a 2.1% order conversion rate. The team is checking campaign-page load speed.
Using only this fictional campaign note, return: (1) a brief that preserves impressions, add-to-cart rate, and order conversion rate exactly; (2) stated action items; and (3) information still needed. Impressions are a count. The denominator definitions for the two rates are not provided, so their comparability cannot be confirmed; report them separately and do not compare them or infer causes, performance, or recommendations. Do not add facts absent from the note.Brief: This week’s new-customer campaign had 38,000 impressions, an 8.2% add-to-cart rate, and a 2.1% order conversion rate.
Action item: Check campaign-page load speed.
Still needed: The note does not provide the denominator definitions for the two rates, a comparison period, or the load-speed review result.List two or three candidate tasks. Use the questions below to discuss how often each occurs, the staff time it takes, whether inputs can be accessed appropriately, whether results can be checked against their source, and whether a mistake can be stopped or reversed. Start with recurring, bounded, reversible organizing work; a rare but lengthy task can also be a candidate if you first try a small sample.
Replace personal data, credentials, wallet addresses, or unpublished material with fictional or public text, and follow the data-handling rules of the service you use.
Specify the input, required fields, source evidence, and how to represent missing information. Submit the prompt in an Agent interface you already use, save its output, and check each item against a fixed list. If one item fails, add one specific rule and try again.
The first exercise needs no web search or tool connection. Consider a tool only when the task needs application data or an action; sending, writing, and trading require separate permissions and human approval.
For the next check, change the figures or date and remove one field; then try a second input format such as an email excerpt or a spreadsheet row. Confirm that figures remain unchanged, missing information is flagged, and the task stays within its approved scope before moving to real, authorized material.
Compare model options only when recurring work truly requires interpreting ambiguous or changing text. The resource cards support specific next steps; a simple text task can begin with a prompt and human review.
Compare the example input with the result and acceptance checks.
Fictional example notice: Community cleanup, 12 May 2027, Riverside Park. Meet at the north gate.
Return JSON with exactly title, date, and location. Use a string when supported by the input; use JSON null when a value is missing or cannot be confirmed. Do not guess. Format date as YYYY-MM-DD and preserve Community cleanup and Riverside Park as written.
{
"title": "Community cleanup",
"date": "2027-05-12",
"location": "Riverside Park"
}Why it is included: Use it to turn a vague idea into a task with clear deliverables and review criteria.
When it does not fit: A clear task description is enough for a first exercise; track goals and progress as a project grows.
Why it is included: When the task depends on OpenAI product behavior or parameters, follow its route to check official documentation instead of guessing from memory.
When it does not fit: An offline generic text task needs no OpenAI product documentation; this Skill also does not replace other vendors' official docs.
Why it is included: When application rules constrain input or an Agent's final answer, it offers a testable way to define rejection conditions and output checks.
When it does not fit: For the small hand-checked offline JSON example below, a schema or assertion is enough; an Agent guardrail is unnecessary.
Why it is included: When an Agent must call an application function, define its parameter contract, validation boundary, and narrow scope.
When it does not fit: A plain text-to-JSON exercise needs no callable tool; adding one creates unnecessary permissions.
Why it is included: If you later build Agent orchestration, scripted mock responses can check your own dispatch and output handling without a live model call.
When it does not fit: It tests application orchestration, not model quality; a single manual JSON check does not need a simulator.
Why it is included: When reviewing real code or a system that accepts external input, identify its stack and check the matching security references.
When it does not fit: Use it when reviewing real code or a system; for a short text exercise, start with the task prompt and result review.