// Run an agent loop until an exit condition is met. Use when the user says "loop", "babysit", "keep trying until", "check every X", "watch", or wants iterative autonomous execution.
Cut a beta release of Paseo. Use when the user says "release beta", "cut a beta", "ship a beta", "beta release", or "/release-beta". Betas are silent release candidates — no changelog, no website move.
Cut a stable release of Paseo (fresh patch or promote from beta). Use when the user says "release stable", "ship stable", "promote", "release:patch", "release:promote", or "/release-stable".
Paseo reference for managing agents and worktrees. Load whenever you need to create agents, send them prompts, or manage worktrees.
Spin up a single agent as an advisor — second opinion on the current task. Use when the user says "advisor", "second opinion", "what does X think", or wants an outside take without delegating the work itself.
Heavy-ceremony orchestration for big work — research, planning, adversarial review, phased implementation, audit, delivery. Use when the user says "epic", "long task", "build this end to end", or wants a feature that runs all night.
Form a committee of two high-reasoning agents to step back, do root cause analysis, and produce a plan. Use when stuck, looping, tunnel-visioning, or facing a hard planning problem.
| name | paseo-loop |
| description | Run an agent loop until an exit condition is met. Use when the user says "loop", "babysit", "keep trying until", "check every X", "watch", or wants iterative autonomous execution. |
| user-invocable | true |
A loop is a worker/verifier cycle: launch a worker → check verification → repeat until done or limits hit. Use for "keep trying", "babysit", or "watch this until X."
User's arguments: $ARGUMENTS
Read the paseo skill for orchestration preferences — worker and verifier providers come from preferences unless the user names them.
Loops are a CLI primitive: paseo loop run. Manage with paseo loop ls, paseo loop inspect <id>, paseo loop logs <id>, paseo loop stop <id>.
$ARGUMENTS and the conversation.--verify-check) for objective criteria a command can answer (gh pr checks --fail-fast, npm test).--verify) for judgment ("Return done=true only if all tests pass and the changed files are coherent. Cite the command and the outcome.").--provider for the worker, --verify-provider for the verifier. From preferences unless the user named them. For implementation loops, pair worker and verifier on different providers — each catches the other's blind spots.--sleep only when polling something external. Otherwise let it run as fast as the loop completes.--max-iterations and/or --max-time. Open-ended loops are how runaways happen.--archive keeps agents after each iteration for inspection.paseo loop run.Babysit a PR — worker checks PR state and fixes issues; shell check is gh pr checks <n> --fail-fast; sleep 2m; max-time 1h.
Drive tests to green — worker investigates failures and fixes code; shell check is the test command; verifier confirms all tests pass; max-iterations 10.
Cross-provider implementation — worker on impl provider, verifier on a different provider; verifier checks changed files, runs typecheck and tests; max-iterations and max-time both bounded; archive on so iterations can be inspected.
Worker — self-contained, concrete (commands, files, branches, tests, PRs, systems), explicit about what counts as progress this iteration.
Verifier — checks facts, doesn't suggest fixes, cites commands/outputs/file evidence, specific about what "done" means.