The documented distinction

A skill records how to do work. A routine determines when an owning Bot runs a workflow, on a schedule or through supported events. The documentation also says routine test runs perform real work. Treat testing as execution, with appropriate inputs and permissions.

The workflow design and prompts below are editorial examples, not tested packaged skills.

Documentation: Official skills and routines guide ↗

Decide which part you actually need

Use a skill when you repeatedly explain the same method: how to classify a customer question, structure a research brief, or reconcile a weekly export. Use a routine when a known trigger should start an already-understood job. If the method changes every run, saving a schedule will not make it predictable.

For example, a competitor-update skill could define which product pages to inspect, what counts as a meaningful change, and how to cite it. Its routine could request that comparison each Monday in your time zone. These are separate decisions: the same method might also be useful on demand before a meeting.

  1. Complete one task manually with the Bot and inspect the result.
  2. Extract the reusable rules, including what a correct empty result looks like.
  3. Run the method on a different input. Include a missing source or ambiguous case.
  4. Save the revised method, then decide whether the task is frequent enough to schedule.
  5. Review the proposed schedule, owner, inputs, and next occurrence before relying on unattended output.

Save a method with an acceptance test

Use this after a task has worked. Attach or reference the accepted example so the Bot can distinguish a formatting preference from a substantive rule.

Try this brief

Draft a reusable skill from the [accepted task/result]. Include its purpose, required inputs, method, output structure, and acceptance checks. Identify which decisions were specific to this example and turn them into explicit inputs. Define behavior for empty, missing, stale, and contradictory sources. The output must remain a draft for human review; external changes need separate authorization. Show me the proposed skill and a second example to test it against before we schedule anything.

Original editorial template. Replace placeholders and review access before running.

Make a schedule earn its place

Our suggested release gate is three varied examples that produce useful output without extra explanation. This is a practical editorial threshold, not a statistical reliability guarantee. Keep the accepted outputs so a future change can be compared against them.

Specify the reporting window separately from the run time. A Monday morning run might cover the previous calendar week, the last seven complete days, or changes since the last successful run. Choosing explicitly prevents gaps and double counting.

  • The method is useful without a schedule.
  • The owner and time zone are explicit.
  • A failed input produces a visible failure, not a recycled report.
  • A repeated run has a defined outcome and cannot accidentally duplicate a write.

Sources & next steps

Capabilities are grounded in the documentation below. The workflow design and acceptance checks are editorial suggestions.

Build your own workflow brief ↗