Track workflow execution

Makes workflow progress traceable through runs, steps and attempts without showing unverified success.

execution-tracking-verification

See how it helps

When is it useful?

Use when a workflow graph must explain retries, cancellation and partial execution.

What does it help you do?

Assigns distinct identities to the run, step execution and attempt.
Maps visual statuses to actual persisted execution evidence.
Defines cancellation boundaries and verifies end-to-end outcomes.

Try asking this

Show a workflow with one retried step and cancellation during an external call, distinguishing uncertain outcomes. Cancel while the provider response is missing. Show the uncertain step separately from confirmed cancellation and preserve the identifiers needed to reconcile it.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Execution Tracking & Verification

Use this skill when building workflow run inspection UIs, step execution timelines, cancellation flows, and end-to-end verification tests for workflow systems.

Traceable Run, Step & Attempt Hierarchy

Three-Level Execution Identity (runId -> stepExecutionId -> attemptId):
- Record every workflow run (runId, workflowVersionId, tenantId, triggerEventId, status, timestamps), every node activation (stepExecutionId, nodeId, status, resolved inputs/outputs), and every individual retry attempt (attemptId, attemptNumber, error details, duration, idempotencyKey).
- Redact secrets, tokens, and sensitive fields from step logs and UI inspection payloads before persisting or rendering.
Honest Visual Run Overlay on the Graph:
- When inspecting a historical or live run on the canvas, render the exact WorkflowVersion graph that the run executed, never the current modified draft.
- Visually and textually distinguish every step state (using icons/badges + labels, never color alone):
  - succeeded, running, waiting (showing what it is waiting for: timer deadline, webhook correlation key, or approver), failed (showing attempt count and error), skipped (unchosen conditional path), cancelling / cancelled, and uncertain_side_effect (when an external call timed out after dispatch and requires reconciliation before blind retry).

Explicit Cancellation Semantics

Distinguish Cancellation Requested (cancelling) from Cancelled (cancelled):
- Cancel pending timers and prevent unstarted downstream steps from launching.
- Clearly show steps whose external side effects already completed before cancellation arrived so operators never assume cancellation automatically undid an external payment or email.

End-to-End Workflow Verification Discipline

Verify workflow definitions and engines across the full matrix of operational failure modes:

Branching & Join Matrix: Test true vs. false vs. default branches, skipped-branch propagation, and parallel join synchronization.
Durable Wait & Process Restart: Trigger a run that enters a timer or approval wait, restart the worker/runtime, deliver the wakeup event, and assert the run resumes from its persisted checkpoint without re-running completed prior steps.
Duplicate Event & Retry Idempotency: Deliver the same trigger webhook, approval decision, or step completion twice and assert zero duplicate step executions or duplicate external side effects.

Checklist

Does the run inspector render the pinned WorkflowVersion graph and show runId, stepExecutionId, and per-attempt history?
Are waiting, skipped, failed, cancelled, and uncertain_side_effect states clearly differentiated with non-color indicators?
Are secrets masked in all recorded step inputs, outputs, and error traces?
Have process restarts during waits, duplicate events, and step retries been verified end to end?

Included files 1

SKILL.md