Problem

The in-progress loop-me skill gives workflow specs a useful vocabulary:

• Trigger;
• Checkpoint;
• Push right;
• Brief.

It also defines when the workflow spec is complete: an implementer should be able to build it without asking another question.

What appears to be missing is the completion boundary for one run of the resulting workflow:

What observable evidence means this run is complete, and what must happen when that evidence cannot be produced?

A workflow can be clear about its trigger and steps but still leave an implementer to invent:

• whether partial output counts as success;
• how many retries are allowed;
• when to pause, skip, or escalate;
• whether seeing the same input again should repeat the work.

That ambiguity can turn a recurring workflow into an unbounded retry loop or allow it to report success without a checkable result.

Concrete reference

I have been exploring this boundary in a broader loop-design-check skill.

I do not think that full framework belongs in loop-me. The portable part is much smaller: every implemented workflow needs enough information to know when one run has ended and when it must stop trying.

Proposal

Add two optional terms to the existing loop-me vocabulary:

• Success signal — the observable evidence that one run achieved its intended outcome. Prefer a runnable check, exit status, recorded state transition, or external reconciliation over an agent's qualitative judgment.
• Failure policy — what happens when the success signal cannot be produced: a bounded retry, skip, pause, or escalation to a human.

Then slightly tighten the definition of done:

A workflow spec is done when an implementer can build it without another question, including knowing how one run proves completion and when it must not continue.

These terms should remain demand-driven, consistent with the current instruction to mandate nothing structural. A workflow with an obvious one-step result may need only a short success signal. A workflow that cannot safely retry may need an immediate escalation rather than a retry count.

Relationship to existing work

• /implement can enter repeated /code-review and fix cycles with no stopping condition #498 concerns repeated /code-review and fix cycles inside /implement.
• This proposal concerns the run boundary of workflows produced by loop-me.
• The workflow-level definition of done remains separate from the run-level success signal: one says the spec is buildable; the other says a running instance has completed.

Non-goals

• Do not add a universal loop engine or scheduler.
• Do not require a plan/build/judge architecture.
• Do not mandate a human checkpoint for every workflow.
• Do not prescribe a fixed retry count.
• Do not make loop-me own monitoring, persistence, or orchestration.
• Do not turn the vocabulary into a required template.

Acceptance criteria

• A workflow can state observable evidence that one run completed.
• A workflow can state what happens when that evidence is unavailable or failing.
• Retry behavior, when present, is bounded.
• The guidance does not require every workflow to use the same structure.
• The distinction between completing the spec and completing one workflow run is explicit.