Autonomous agent loop
Skill edmundmiller/dotfiles/skills/catalog/autonomous-agent-loop
Use when a task is broad, multi-step, cross-session, or the user says agents need too many re-prompts/kicks, asks to use createGoal/goals, says continue/keep going, or wants rough Pi/agent sessions improved. Keeps work moving from objective to evidence-backed completion.From its SKILL.md
npx -y skills add edmundmiller/dotfiles --skill autonomous-agent-loopAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
3.8 KB, as published. Nobody here has run it
Autonomous Agent Loop
Use this skill when the task should finish without repeated user nudges.
Start: make the contract durable
Keep exactly one active outcome. Record:
Outcome: the single requested end state.Done when: the observable stopping condition.Proof: the commands, diffs, rendered output, smoke checks, logs, or artifacts that establish it.
Derive repository facts before asking. Request only missing product intent or authority. If a durable goal tool exists and no active goal covers the work, create one; do not add a task store or second goal-tracking convention. Prefer goalize and goal-continue-audit, and keep project-specific details in the goal or repository docs.
Work loop
Repeat until the only valid return state is done or genuine blocked:
- Choose the next low-risk step that reduces uncertainty or advances the outcome.
- Run it and inspect fresh evidence.
- Update the plan from that evidence.
- Record unrelated discoveries as
Parked, then resume the active outcome. - Before proposing scope expansion, state what current work it would displace.
- Continue without waiting unless tools, access, or a required decision make progress impossible.
- For background jobs, use a blocking or longest bounded wait when available. After an unchanged status, increase the interval; never poll again immediately unless the status changed or a real deadline is near.
Do not stop at a plan, agent-actionable next steps, untriaged validation failures, or partial completion. Do not add a scheduler, dashboard, coordinator process, or notification policy; existing durable-goal tools are the execution mechanism.
Delegation return contract
When a primary delegates a bounded task, require one compact structured progress report from the worker:
status:DONE,CONTINUE,PARTIAL, orBLOCKED.changed_paths: every created, modified, or deleted path.verification: exact checks and evidence, including failures.landing_state:UNLANDED,READY_FOR_DONE,LANDED, orBLOCKED.next_action: exactly one concrete follow-up, ornonewhen no follow-up is needed.
The primary must wait for each worker. Follow up CONTINUE and PARTIAL results
or take the next bounded step; a worker's DONE only completes its assignment.
Durable goals are checkpoints, not wake schedulers: an active goal does not relaunch
a stopped worker. Keep the goal open through done, and close it only after
landing_state is LANDED or the outcome is genuinely BLOCKED.
Evidence-first debugging
When behavior is “rough” or repeatedly needs kicks:
- Search session/log history for repeated user follow-ups:
continue,try again,did that fix,how is it going,commit,rerun,still broken. - Compare the first ask to the final answer: did the agent deliver artifacts and verification, or just recommendations?
- Identify missing feedback loops: no build/test, no smoke check, no rendered UI inspection, no deploy verification, no issue update.
- Patch the durable surface that future agents read:
AGENTS.md, shared rules, skills, prompt templates, or repo docs.
Blocked stop format
Return blocked only when completion is impossible. Report:
- attempted paths
- evidence gathered
- exact blocker
- unmet requirements
- exactly one smallest human action needed to continue
Never mark a durable goal done while any requirement is unverified, narrowed, deferred, or merely locally checked when authorized landing remains.