| name | one-off-operations |
| description | Handles one-off operations: the request is a concrete effect that happens once — export or copy data somewhere, a migration, a backfill, a cleanup — with no trigger, schedule, or reuse intent. The workflow is the vehicle, not the deliverable. Users rarely say "one-off"; infer it from the task's shape. Load before building for such a request, or when a build-workflow result contains postBuildFlow.reason "direct-one-off-build-succeeded". Do not load for automations the user will run again — that is the normal build + post-build-flow path. |
| recommended_tools | ["build-workflow","workflows","executions","ask-user","verify-built-workflow"] |
One-Off Operations
Use this skill when the request is a one-off operation: a concrete effect
that needs to happen once, where a workflow is only the vehicle to make it
happen. Typical shapes: "put this data in a spreadsheet", "copy these rows to
X", "migrate/backfill/clean up Y".
These instructions are in English, but user-visible text you write while
following them stays in the user's conversation language.
Recognizing a one-off
Users rarely label a task "one-off" — infer it from the task's shape, not
from explicit phrasing. It is a one-off when the deliverable is a state
change, not an automation:
- The user asks for an effect on data that already exists and is bounded —
pasted into the chat, sitting in a named node, table, file, or sheet — rather
than data that will keep arriving over time.
- The request is imperative about the here-and-now ("add these rows", "export
what's in X", "clean out the duplicates"), with no trigger, schedule, or
event vocabulary — no "when", "every", "whenever", "daily", "each time".
- Nothing suggests the user wants to keep and rerun the workflow; the workflow
is never mentioned as the thing they want, only the outcome is.
Explicit markers ("just this once", "I won't need this again") confirm the
classification but are not required — most one-offs arrive without them.
Signals against: trigger/schedule vocabulary, "from now on", a named event
source, or any hint the user wants the automation itself. When in doubt,
treat the request as reusable and follow the normal build flow — a reusable
workflow that runs once is harmless; a one-off flow applied to an automation
skips verification the user would have wanted.
A one-off that touches external systems is still workflow-anchored (you cannot
write to external services directly) — the intent changes the post-build
flow, not the anchor.
The one-off flow
- Build the workflow with a manual trigger — always. A one-off is
never published, so an event trigger (webhook, form, schedule) would never
fire and only misleads. If the task genuinely needs an event source or a
future run time, it is not a one-off — reclassify it as a reusable
automation or a scheduled task and use the normal flow. Pass
executionIntent: "one-off" to build-workflow. This marks verification
as optional in the build outcome — no verification follow-up is scheduled,
and the completion criterion becomes a live run whose output you read back.
- Setup is unchanged: if the build outcome requires credential or value
setup, route it through
workflows(action="setup") as usual. A one-off
still needs real credentials before it can run live.
- Run live with
executions(action="run"). The run-approval card is the
user's consent gate — for a one-off, the live run IS what the user asked
for, so the usual "reserve live runs for explicit user requests" rule is
satisfied by the request itself. Do not run before setup is complete.
- Read back before reporting. After the run, inspect the actual output of
the effect nodes with
executions(action="get-node-output") — the run
result data is truncated and not enough for quantitative claims. Check that
each write/effect node's input was the intended data (the rows you meant to
write), not an upstream node's API response. Report only numbers, columns,
and shapes you actually read. If the target system is cheap to read (e.g. a
read operation of the same node type), offer a read-back of the destination
as final confirmation.
- Offer to clean up the workflow. When the operation succeeded, ask whether
to keep the workflow for future reuse or delete it now that the job is done.
Never delete without asking. If the user keeps it, mention it stays
unpublished unless they say otherwise. This step is about the workflow: the
data a one-off wrote is the deliverable the user asked for, so never offer to
undo that. Test data left behind by a test run is the opposite case — see
"Cleaning up after a live test" in
post-build-flow.
Optional pre-flight verification
verify-built-workflow is available but not required and never the
completion criterion for a one-off. Offer it before the live run only when
the wiring is complex (branching, merges, non-trivial transformations) or the
user is cautious about touching real data.
When you do run it, present results honestly:
- Say which nodes were simulated — external writes did not happen, and the
data flowing into simulated write nodes was NOT validated (their output is a
fabricated success fixture).
- Never call the workflow "verified", "tested", or "working" from a simulated
pass alone, and never let it substitute for the live run and read-back.
Claiming success
Do not make quantitative claims ("22 rows written", "columns matched") that
you did not read back from actual execution output or the target system. A
successful run status alone does not prove the right data was written — read
the effect node's real output first. If you could not read it back, say so
plainly and name what is unconfirmed.
