Build a Ralph Wiggum long-running loop extension for pi
Session from pi-extensions-sessions on Hugging Face by thomasmustier · MIT · condensed by Coders Talk
Add a pi coding-agent extension implementing the 'Ralph Wiggum' pattern of long-running, self-continuing agent loops driven by a task file, replacing a broken old version.
- +0Prompt · +0Add a ralph-wiggum extension implementing the Ralph Wiggum long-running agent loop pattern, killing the old broken ralph-wiggum.ts
- +0mAgent did · +0mRead extension docs/examples, designed a PRD-driven loop extension (index.ts + README), wired it into the examples README, and fixed type-check errors until checks passed
- +5mAgent did · +5mSet up tmux-based testing (installed tmux), ran single-story and multi-story PRD loops end to end, verifying commits, progress file and completion detection
- +17mIntervention · +17mDeveloper rejected the PRD/JSON approach and multi-loop-by-filename design, asking for a simpler single task-file-per-named-loop model with reflection checkpoints and 'detect but don't auto-resume' for conflicting loopsWhy: The PRD JSON structure was overkill - I wanted something simpler, tied to an arbitrary file, that could support named concurrent loops safely.
- +29mAgent did · +29mRewrote the extension around named loops with a simple markdown task file and state json, tested via tmux, then moved the extension out of the monorepo into ~/pi-extensions per developer's instruction not to push to upstream
- +1h 4mAgent did · +1h 4mAdded a ralph_start tool so the agent could self-start loops, wrote a SKILL.md (using skill-creator), symlinked into pi-skills/extensions, and stripped now-redundant Ralph guidance from an external repo's AGENTS.md to test skill self-sufficiency
- Break · 1h 12m away, not counted
- +1h 15mAgent did · +1h 15mReworked iteration pacing per developer spec (items-per-iteration vs reflect-every-N-items) and validated with a 50-item batch review test showing correct pacing and reflection triggers
- +1h 44mFail · +1h 44mMultiple stop/interrupt mechanisms failed in practice: ctrl+shift+r shortcut didn't work, esc just re-queued the next iteration, hasPendingMessages() broke normal loop continuation, and typing 'stop' didn't pause an already-queued iteration
- +2h 37mIntervention · +2h 37mDeveloper proposed a much simpler fix after all the stop hacks failed: have the agent itself output the completion marker when it sees a 'ralph-stop' message, rather than intercepting events in the extensionWhy: After all this hook-detection complexity failed repeatedly, I realized the simplest fix was to just tell the agent in its own instructions to emit the stop marker on request - no special-casing needed.
- +2h 43mOutcome · +2h 43mSimplified to: agent outputs <promise>COMPLETE</promise> on 'ralph-stop' or task completion; removed complex before_agent_start detection; docs updated and pushed to ~/pi-extensions across ~15+ commits
Next time I'd start with the simplest possible stop mechanism - just telling the agent in its own prompt to emit the completion marker on a keyword - instead of trying to intercept aborts, keyboard shortcuts, and pending-message queues in the extension runtime. The fix that actually worked was recognizing that the agent's own instructions could handle 'stop' just like normal completion, which cut out a lot of fragile event-hook logic we'd built up. The iterative testing via tmux was valuable for catching real bugs (state file location, pacing, reflection timing) but the interrupt handling took far too many failed attempts before landing on the obvious answer.