Paseo Loop
Run a worker/verifier agent loop via Paseo CLI until tests pass, checks green, or iteration limits—without hand-holding every retry.
Overview
Paseo Loop is an agent skill most often used in Build agent-tooling (also Ship testing, Operate iterate) that runs worker/verifier cycles via the Paseo CLI until verification passes or limits stop the loop.
Install
npx skills add https://github.com/getpaseo/paseo --skill paseo-loopWhat is this skill?
- Worker/verifier cycle: launch worker → verify → repeat until done or limits
- CLI primitive: paseo loop run with ls, inspect, logs, stop
- Objective --verify-check (shell) and/or judgment --verify prompts
- Reads ~/.paseo/orchestration-preferences.json before picking providers unless user overrides
- Trigger phrases: loop, babysit, keep trying until, check every X, watch
- Documents 5+ loop management subcommands (run, ls, inspect, logs, stop)
Adoption & trust: 1.2k installs on skills.sh; 8k GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
You asked the agent to fix something once but need it to keep trying with explicit pass/fail checks until the job is actually done.
Who is it for?
Builders already using Paseo who want babysitting loops on tests, PR checks, or iterative agent work.
Skip if: One-off questions with no repeatable verification criterion—use normal chat instead of loop run.
When should I use this skill?
User says loop, babysit, keep trying until, check every X, watch, or wants iterative autonomous execution.
What do I get? / Deliverables
A managed Paseo loop runs with documented worker and verification steps, stoppable via CLI, until objective checks or verifier judgment confirms completion.
- Running loop id with inspect/logs trail
- Terminal verification outcome tied to worker iterations
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Autonomous iterative execution is primarily agent-tooling during Build, when you are driving codegen and verification toward a done state. Agent-tooling covers orchestration primitives (loop run, inspect, stop) that sit beside your main coding workflow.
Where it fits
Babysit a fix loop until unit tests pass and changed files stay coherent per verifier prompt.
Loop with --verify-check running gh pr checks or npm test until CI criteria succeed.
Watch a recurring job every N minutes until a production symptom clears or limits hit.
How it compares
Orchestrated CLI loop with verifiers—not the same as a single subagent task or an MCP tool call.
Common Questions / FAQ
Who is paseo-loop for?
Solo builders orchestrating Claude/Cursor-style agents through Paseo who need sustained worker/verifier cycles with shell or LLM verification.
When should I use paseo-loop?
Say loop or babysit during Build for fix-and-test cycles, at Ship when waiting on npm test or gh pr checks, or in Operate when watching a condition on an interval.
Is paseo-loop safe to install?
Loops can run shell and agent providers—review Security Audits on this Prism page and your verify-check commands before unattended runs.
Workflow Chain
Requires first: paseo
SKILL.md
READMESKILL.md - Paseo Loop
# Paseo Loop Skill 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 ## Prerequisites Read the **paseo** skill. Before choosing worker or verifier providers, read `~/.paseo/orchestration-preferences.json` unless the user explicitly named providers in this request. Do not start the loop until you have read it. 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>`. ## Your job 1. Understand the user's intent from `$ARGUMENTS` and the conversation. 2. **Worker prompt** — self-contained, concrete about what to do this iteration, explicit about what counts as progress. 3. **Verification** — pick the right shape: - Shell check (`--verify-check`) for objective criteria a command can answer (`gh pr checks --fail-fast`, `npm test`). - Verifier prompt (`--verify`) for judgment ("Return done=true only if all tests pass and the changed files are coherent. Cite the command and the outcome."). - Both, when shell rules out the obvious failures and the verifier judges the rest. 4. **Providers** — `--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. 5. **Sleep** — `--sleep` only when polling something external. Otherwise let it run as fast as the loop completes. 6. **Stops** — set a sensible `--max-iterations` and/or `--max-time`. Open-ended loops are how runaways happen. 7. **Archive** — `--archive` keeps agents after each iteration for inspection. 8. Launch with `paseo loop run`. ## Common shapes **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. ## Prompt rules **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.