Skip to content
AssureSwarm Docs

Agent Operating Guide

/coach-workflow-execute

Execute one workflow step on your behalf: grounded in the upstream results, refused until every direct upstream step is done, and submitted as a suggestion for a human to approve.

Perform the work a specific workflow step describes, then submit the result as a suggestion the workflow owner can approve. The skill reads the step’s instructions and its upstream steps via get_step_context, grounds its work in the upstream results, and routes the outcome through human review: nothing is written to your tenant until it’s approved. Its non-negotiable rule: it refuses to run a step whose direct upstream steps aren’t all finished.

When to use

Section titled “When to use”

When you want an agent to do a specific step’s work, draft the memo, run the analysis, record the evidence, and hand you a result to review. To see which of your steps are ready to work on first, run /coach-workflow-scan.

Inputs

Section titled “Inputs”
Flag Required Notes
--step <stepId> No The step to execute. If absent, inferred from your current view, then from your assigned steps.
--workflow <workflowId> No Disambiguates when two workflows share a step name or ordinal.
--mode execute|evidence No execute (default): the agent authors the result. evidence: a human did the work: attach their evidence and record a completion note instead of authoring.
--headless No Unattended mode (what autopilot uses): suppresses the interactive handoff and returns a structured outcome instead. When an input is missing, posts a one-time INPUT NEEDED placeholder suggestion on the step naming it.

Example

Section titled “Example”

/coach-workflow-execute --step step_abc reads the step’s instructions and checks its upstream steps. If any direct upstream step is still PENDING or IN_PROGRESS, it refuses, naming the blocked step and its blocker, and offers to execute that upstream step first. If upstream is clean, it reads the upstream results, produces the result the instructions describe, and submits an update suggestion on the step for you to approve.

Good to know

Section titled “Good to know”
  • The upstream gate is the headline behavior. A step only runs when every direct upstream step is COMPLETED or APPROVED; PENDING and IN_PROGRESS block it. The platform doesn’t enforce this at the data layer: the skill does. When blocked, it names the blocking step and offers to execute that upstream step first.
  • Decision steps prune the untaken branch. For a branching (decision) step, the work is choosing the branch value; the skill records the choice and, in the same turn, submits a prune-branch suggestion that deletes the not-taken branch. Both are approvals the owner reviews.
  • Evidence mode records, it doesn’t fabricate. When a human performs the work: a control owner runs a control, a tester captures a screenshot: --mode evidence attaches the supplied evidence to the step and writes a short completion record, never invented analysis. It never hand-writes a status field; the platform derives step status from approvals.
  • Missing inputs get requested in the workflow itself (headless only). When an unattended run finds a step needing something only you can supply, it submits an ALL-UPPERCASE suggestion on the step, INPUT NEEDED, THIS IS A PLACEHOLDER, NOT A RESULT. DO NOT APPROVE.: naming the specific missing items. The uppercase is deliberate: it trains reviewers to read results instead of rubber-stamping. Posted at most once per step; once you supply the input, the next run drafts the real result. Interactively, the skill just asks you instead.
  • Already-done steps are left alone. If the step already has a result or a prior suggestion from an unattended run, the skill returns without redrafting, but an INPUT NEEDED placeholder doesn’t count as done: those steps stay live until the real result is drafted.
Section titled “Related”