Mohamed Boudra
90feb8050c
Skills installed via Paseo desktop never updated after first run, so users were stuck on already-fixed skill content. On every launch, if the paseo base skill is present in `~/.agents/skills/`, sync each bundled skill (incl. `references/`) into agents, claude (via symlink/ junction), and codex — overwriting only files whose content differs. Files on disk that are not in the bundle are left alone; deprecation goes through tombstones (e.g. `paseo-orchestrate` redirects to `paseo-epic`). Also refreshes the bundled skill set: drops `paseo-chat`, adds `paseo-advisor` and `paseo-epic`, and turns `paseo-orchestrate` into a tombstone redirecting to `paseo-epic`. Adds a desktop test job to CI on Ubuntu and Windows so the junction/symlink path is exercised on both platforms.
2.8 KiB
name, description, user-invocable
| name | description | user-invocable |
|---|---|---|
| paseo-loop | 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. | true |
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 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>.
Your job
- Understand the user's intent from
$ARGUMENTSand the conversation. - Worker prompt — self-contained, concrete about what to do this iteration, explicit about what counts as progress.
- 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.
- Shell check (
- Providers —
--providerfor the worker,--verify-providerfor 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 —
--sleeponly when polling something external. Otherwise let it run as fast as the loop completes. - Stops — set a sensible
--max-iterationsand/or--max-time. Open-ended loops are how runaways happen. - Archive —
--archivekeeps agents after each iteration for inspection. - 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.