One Step, One Job, Workflows You Can Debug

One Step, One Job, Workflows You Can Debug

Splits a workflow into steps with structured outputs and checks between them, and moves the deterministic work into code.

airops workflow automation prompt-engineering debugging structured-output

What it is for

A workflow step that fetches, reasons, writes and formats all at once cannot be debugged, only re-run and hoped over. This splits the work one job per step, demands named output fields, adds a check between steps, and moves dates and arithmetic into code where they belong. Reach for it when a workflow works on the demo row and fails somewhere in the middle of a real batch.

The skill

Build the workflow as small steps with checkable output between them. A
single step doing five things fails as a mystery.

Split the work so each step does exactly one of these:
  fetch  ->  extract  ->  decide  ->  write  ->  format  ->  send

For every model step:
- Ask for structured output with named fields. Do not ask for prose you will
  later pull apart with string matching; that works until someone writes a
  colon in a title.
- Give it one job. If the instruction contains "and also", it is two steps.
- Say what to output when the input is insufficient, and give it an explicit
  value to return. Silence and invention are the two default failures.
- Put the source material inside the step and state: use only what is here.

Between steps:
- Check that the previous output actually has the fields the next step
  reads. Fail loudly there, not three steps later with an empty string that
  quietly becomes the word "undefined" in a published sentence.
- Do the deterministic parts in code, never in a prompt. Dates, arithmetic,
  currency, string formatting, deduplication, sorting and URL building are
  code. A model doing arithmetic is a bug waiting for volume.

Naming and visibility:
- Name each step for what it produces, not for what it consumes.
- Make sure you can read what each step received and returned in a run.
  A step whose input you cannot see is a step you cannot debug.
- Keep one example run you know is correct, and compare against it after
  every change.

Failure this prevents: a workflow that works on the demo row, breaks on row
nine hundred, and hands you one long output with no way to tell which part
went wrong.

How to install it

1. Open the tool and start a new conversation, project or template.
2. Paste the text below wherever the tool keeps standing instructions
   — usually called system prompt, instructions, or persona.
3. Save it so it applies to every run rather than a single message.

Did it work for you?

Where it came from

Skills app Original