Loop Engineer is used through coding-agent skills and slash commands, not through a terminal CLI.
Users interact with:
/plan-loop,/develop-product, and/loop-engine- the other slash-command skills listed in
AGENTS.md - equivalent natural-language requests in coding agents that support skill routing
Installers wire thin router skills into each supported coding harness. Those routers read the canonical command and skill files from the installed app.
The installed bin/loop executable is retained as a private bridge between coding-agent
skills and deterministic Python modules. It owns operations that should not be recreated by
free-form model edits:
- session lifecycle and workspace resolution
- doubt and parent-finding parsing/resolution
- product hierarchy synchronization
- feature creation and convergence
- graph, freshness, evidence, and output validation
- eval result persistence
- installation, migration, update, and diagnostic administration
- the verification ledger (
loop test,loop verify), impacted tests, and mutation scores - executable constraints (
loop check) and plan checks against the spec (loop plan-check) - skill tiers and search (
loop skills find), hook wiring (loop hooks), provider config - the trace and the context probe (
loop trace,loop probe)
The shell bridge is an implementation detail. Command and skill files may invoke it; normal user documentation must not require users to chain runtime commands.
Some capabilities exist under both names - loop doctor and /doctor, loop scope check
and /scope, loop doubts ask and /resolve-doubts. They are not synonyms, and the
choice is not stylistic:
| Write | When |
|---|---|
loop <cmd> |
The agent executes this step itself, now, inside a larger procedure. It returns data the procedure consumes. |
/<skill> |
Routing to a whole capability with its own reads, terminus and output - the thing a user could also type. |
A skill that names /resolve-doubts where it means "surface this round's blockers"
promotes a mid-run query into a full plan-wide readiness review with a GO / NO-GO
terminus. The reverse - naming loop doubts ask where the run genuinely needs readiness
settled - stops at a printed list nobody acted on.
The tell: if the next line of the procedure consumes a return value, it is the runtime call. If the next line is "and then continue from whatever that decided", it is the skill.
Where a loop command has no skill at all (glossary, fog, record, cloud, eval,
feature, budget), the runtime name is the only name - and AGENTS.md #14 still holds:
the agent runs it and reports what it said, rather than printing it for the user.
- Primitive runtime operations remain supported for skills, tests, installers, and maintainers.
- The free-form
loop plan-loop "<idea>"orchestration alias is compatibility-only and emits a deprecation notice./plan-loop <idea>is the public interface. - Existing scripts are not broken in this change. No workspace file format or state transition changes.
- Maintainer-only shell operations may remain documented in explicitly labelled sections.
Do not delete bin/loop or scripts/loop_cli.py until every supported coding harness has a
portable replacement for invoking deterministic operations (for example a stable tool API
or universally supported MCP transport), installed routers no longer reference the shell
bridge, and a versioned migration exists for external automation. Until then, deleting the
runner would move rules-first state transitions back into nondeterministic model behavior.