autoloop

name	autoloop
description	Use when the user explicitly invokes /autoloop to automate an already-approved plan through /execute, /verify, and /ship with bounded retries and handoff on repeated failure.
when_to_use	Use only after a reviewed plan exists and the user explicitly asks for /autoloop. Do not use for idea shaping, plan creation, destructive operations, vague "keep going" requests, or simple one-off changes.
argument-hint	[plan]
user-invocable	true
allowed-tools	["Bash","Read"]

/autoloop

Step 0: Escape Hatch

If builder says 别走流程, 直接做, 简单点, or 不走地图, do not run /autoloop. Acknowledge once and do the smallest direct action.

Exception: the escape hatch does not bypass safety gates for destructive changes, secret access, public upload, deploy, database migration, force push, or irreversible writes.

Contract

/autoloop is an explicit automation wrapper for mature, already-approved plans.

It may run:

/execute -> /verify -> /ship

It must not create a plan, expand scope, choose new dependencies, perform destructive actions, push, open a PR, or publish unless the active plan and /ship both say that action is in scope and builder explicitly approves it.

Preconditions

Before doing anything else:

1. Resolve the active plan:

   bash ${BDC_HOME:-$HOME/.bdc}/scripts/active-plan-resolver.sh --single
   

2. Confirm the plan is reviewed or explicitly approved by builder.
3. Confirm at least one unchecked step remains.
4. Confirm the plan has executable verify commands.
5. Confirm no step asks for destructive work without explicit owner approval.

If any precondition fails, stop and report the exact missing condition. Do not downgrade into ad-hoc /execute.

Process

1. Run /execute on the next unchecked step.
2. If /execute passes, run /verify on the finished work.
3. If /verify returns APPROVE, continue until the next boundary or until no unchecked steps remain.
4. If /verify returns REQUEST_CHANGES, treat it as failure 1 and run one correction loop through /execute.
5. If the correction loop still fails, or any stage accumulates two failures, stop and run /handoff.
6. When the plan has no unchecked steps, run /ship for local-first go/no-go. Do not push, publish, or open a PR unless /ship asks for it and builder confirms.

Failure Budget

Event	Count
/execute verify failure	1
/verify REQUEST_CHANGES	1
/ship NO-GO with actionable fix	1
Same stage fails again after one correction loop	stop

Two accumulated failures in one /autoloop invocation require:

1. stop execution
2. summarize what passed, what failed, and what was changed
3. run /handoff or write the equivalent handoff if the handoff skill is unavailable

Safety Boundaries

• Do not run destructive commands from /autoloop. Because: automation must not hide irreversible decisions.
• Do not push, publish, deploy, or open a PR by default. Because: /autoloop is a local execution wrapper, not a release authority.
• Do not continue after scope drift. Because: /execute scope checks define the atomic boundary.
• Do not change the approved plan's dependencies or architecture decisions. Because: /autoloop starts after planning is frozen.

Output

Keep a compact running ledger:

Autoloop:
- Plan: <path>
- Current stage: execute | verify | ship | stopped
- Passed: <count>
- Failures: <count>/2
- Last evidence: <command or verdict>
- Next action: <continue | stop | handoff | ship>

Verification

• The active plan was resolved with active-plan-resolver.sh --single.
• /execute produced fresh verify evidence before /verify.
• /verify returned APPROVE before /ship.
• /ship produced GO/NO-GO and rollback/restore notes before any release action.

Red Flags

• /autoloop starts from a fuzzy idea or unreviewed plan.
• It performs destructive work or publishing without explicit approval.
• It retries indefinitely instead of stopping after two failures.
• It treats REQUEST_CHANGES as a warning instead of a failure.

Common Rationalizations

Rationalization	Response
"The plan is probably approved because it exists."	Do not assume. Incident: standards/debugging.md 2026-04-04 records written rules being ignored until hard gates enforced them; approval must be explicit.
"One more retry might fix it."	Stop after the budget. Incident: large health baseline runs require durable handoff state instead of unbounded continuation.

References

• ${BDC_HOME:-$HOME/.bdc}/standards/roadmap.md
• ${BDC_HOME:-$HOME/.bdc}/skills/execute/SKILL.md
• ${BDC_HOME:-$HOME/.bdc}/skills/verify/SKILL.md
• ${BDC_HOME:-$HOME/.bdc}/skills/ship/SKILL.md
• ${BDC_HOME:-$HOME/.bdc}/skills/handoff/SKILL.md