yield/Documentation

Primitive 05 / Terminal

Outcomes

End every run honestly: complete with a useful result, block on a real frontier, or refuse deliberately.

01 / Choose

The reason determines the terminal.

Complete

The requirements passed and the workflow can return its useful result.

Blocked

New evidence or an external change is required before work can continue.

Refused

The workflow deliberately declines because approval, safety, or policy says no.

Requirement failed

A declared claim failed, so later operations are unreachable.

Useful for

  • Return verified evidenceComplete with the useful result.
  • Wait for credentialsBlock until access is available.
  • Stop after denied approvalRefuse the requested action.
  • Stop unsafe workEnd before the action starts.
  • Explain a failed testRecord why the requirement failed.
  • Wait for external stateBlock until the outside state changes.
02 / Code

Make every ending explicit.

Outcomes · TypeScript
import { defineSkill } from "@operatorstack/yield"

defineSkill((ctx) => {
  const approval = ctx.askUser("approve", "Publish?", [
    { value: "yes", label: "Publish" },
    { value: "no", label: "Stop" },
  ])
  if (approval !== "yes") ctx.refused("release not approved")
  const publish = ctx.runCommand("publish", "npm publish", 600)
  if (publish.timed_out) ctx.blocked("registry status is unknown")
  ctx.require(publish.exit_code === 0, "publish succeeds", publish)
  return { published: true }
})
03 / Run

The terminal state tells the next session what happened.

CursorSkill workflow · finished

› /publish-release

● Publish command finished and the requirement passed.

CompleteUseful result saved
BlockedExternal change needed
RefusedWorkflow declined
Terminal result{ "status": "completed", "result": { "published": true } }

Cursor shows the ending. Yield records one terminal state and its result or reason, so another session does not need the old chat.

04 / Saved

The result explains how the run ended.

A completed run stores its structured result. Blocked and refused runs store the reason. Another session can inspect the run without reconstructing the decision from chat history.

Common mistake

Do not use Blocked as a generic error. Use it only when the workflow has reached a true frontier. Use Refused when the workflow has enough information and chooses not to continue.

Set your examples once

Which language are you using?

We’ll open every language-aware example in your choice. You can still switch any individual code block.