# Wiggum > Methodology for the user-triggered /wiggum command (do not self-invoke). An autonomous-continuation loop for long-running work -- run, checkpoint, and verify until a defined Definition of Done holds or a stop-and-escalate condition fires. Covers durable handoff state, baseline re-verification after context compaction, per-commit self-audit, work-unit commit and restack cadence, subagent fan-out limits, and escalation. - Skill: `jwiegley/wiggum` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add jwiegley/wiggum` - Raw SKILL.md: https://api.skillmd.com/api/skills/jwiegley/wiggum/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: jwiegley (https://skillmd.com/u/jwiegley) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/jwiegley/wiggum --- # Wiggum Run autonomously in a work -> checkpoint -> verify loop until the Definition of Done holds, or a stop-and-escalate condition fires. This skill is the methodology; the `/wiggum` command turns it on. Do not enter this mode on your own -- only when the user invokes it. Whenever Wiggum is invoked, load the `refocus` skill from the available skill catalog and keep it active for the entire loop. Perform its goal and scope check immediately, at least hourly during active work, and after every resume or compaction. No separate user invocation of `refocus` is needed. Keep its last check, next deadline, and next required step in the existing handoff state. You perform git operations directly, following the documented approach of the matching workflow. `commit`, `restack`, and `rebase` are user-triggered commands, so follow their procedure rather than invoking them as slash commands. "Parity" means the work matches a named reference target (for example, a source-of-truth implementation). If no target is given, "done" means every objective of the current plan is complete and independently verified. ## Working policies - Always use `CARGO_TARGET_DIR` to locate Rust build products in a directory under the `~/Products` related to the current project. - Always use `~/Products` for temporary build products, worktrees, explorations, downloaded artifacts, etc., instead of (for example, so do NOT use these): - `/tmp` - the current working tree - a sibling directory - `.claude/worktrees` - etc. - Always use `direnv exec . $COMMAND` to run commands in this directory that involve tools provided by the flake.nix environment, such as compilers, linkers and other dependencies specific to this project. You do not need to use `direnv exec` for regular commands like sed, bash, grep, rg, etc. - Use the `obr` skill, if it is being used, to track all current, pending and completed work and tasks. See AGENTS.md to determine if it is in use for this project. This is also indicated by a PLAN.org, doc/PLAN.org or docs/PLAN.org file in the repository. - Use `git-surgeon` skill whenever possible to interact with Git, since it is more precise and token-efficient. - Restack, using the resolving skill, every four hours or so, or when you reach a good checkpoint, but never blocking the work until this time is reached. This is simply something that should happen from time to time as good engineering practice. - Use PAL MCP if it is working, per the `heavy` skill, or ignore it if it is not working. - Use the ponytail and caveman skills, always avoid scope creep, and stay focused on the task or goal presented to you. - Use the `abstraction-review` skill and make sure that you avoid circumventing abstractions merely for the sake of expediently reaching "the goal". The goal is not just the outcome, but it is also the principled manner in which we get there. ## Definition of Done A user request to stop or halt overrides everything below: acknowledge it, record the current loop state in the active `obr` issue or handoff document, and stop immediately. Exit the loop successfully ONLY when ALL of these hold, with evidence rather than self-assertion: - Every planned task or done-criterion is complete. - The build and the full test suite pass, and you have shown the passing output. - The last work commit has passed a final `fess` audit -- audit it even if the most recent commits were themselves `fess` fixes. - No actionable partner observation is outstanding as of the last cleanup cycle. (Partner review does not necessarily drain to empty; you may finish with a note that further, non-blocking observations are deferred.) - The branch is rebased or restacked cleanly onto its base (locally). - If a parity target was given, a parity check passes with evidence. Never edit the plan or the done-criteria to lower the bar. Never weaken, skip, or delete tests, and never hardcode outputs to satisfy a check -- that is reward hacking, and it defeats the whole loop (see the `fix-all` skill's philosophy). Verification comes from a separate evaluator, not from grading your own work. ## Stop and escalate Autonomy is not stubbornness, and these conditions OVERRIDE the /wiggum directive to keep going -- when one fires, stop and hand back to the human, even mid-loop. Stop and ask when: - the same failing signature or gate persists after a bounded number of attempts (default 3) without intervening progress -- do a root-cause pass, then escalate instead of thrashing. Record the attempt count in the handoff document so it survives compaction, and reset it when the gate passes or the underlying cause demonstrably changes; - requirements are ambiguous or appear to have changed; - a rebase or restack conflict cannot be resolved without guessing intent; - a subagent returns unusable output twice, or PAL consensus cannot be reached; - an action would be destructive or irreversible -- data loss, force-pushing or submitting shared history, deleting work. Report where you are, what you tried, and what you need. ## Durable state (survives compaction and fresh sessions) Keep three distinct artifacts so work resumes exactly where it left off if the machine dies or the session restarts: 1. **Frozen plan / done-criteria** -- the target, written before work. Read-only for the purpose of lowering the bar. 2. **Handoff documentation** -- use `obr` to track this information, if `obr` is being used, otherwise use a Markdown file within the repository. This handoff information should track what is done, what remains, how to resume, and the current stop-and-escalate attempt counts. If using `obr`, use on issue per item being worked on, so that progress and completeness can be tracked with fine granularity; if using a handoff document file, append and trim to keep it current and task-state oriented. 3. **Running learnings** -- if the `journal` workflow is in use, that append-only, timestamped record of durable learnings is separate from the handoff. Do not conflate the two. ## Refresh after compaction After every context compaction, before any new work: re-read this skill, the `refocus` skill, the frozen plan/target, and the `obr` issues or handoff document in full (including the attempt counts and refocus checkpoint); if a journal is kept, re-read its preface plus the recent entries needed to recover the latest learnings. Perform the refocus check, then run a baseline verification -- build and tests, plus the parity check if a parity target exists -- to confirm the current state before touching anything new. Starting new work on an already-broken base only makes it worse. ## The loop Each iteration: Check the `refocus` deadline before advancing work; if due, perform its check first. Also follow its clock checks around long-running tools and waits so an iteration that lasts over an hour still refocuses on time. 1. Advance one logical unit of work -- a coherent change that builds and passes. However, if that logic unit is very small, then proceed in larger steps so that commits are not being generated too often -- since that feedback loop takes a lot of time, and doing so too frquently would slow down development unnecessarily. 2. Commit it in a clean, logical sequence, following the `commit` workflow's approach (you perform the commits directly; `commit` is user-triggered). 3. Audit that commit: dispatch a subagent -- the `fess-auditor` agent, or one running `fess` -- to check the work and its claims. Use the runner's explicit no-history mode and first pass the `parallelize` skill's parent-history sentinel probe; a separate context window alone is not evidence of independence. Keep the evaluator separate; do not grade your own work. See `references/fess-audit.md` for how to pick the audit scope and what context snapshot to provide. Verify any finding before acting, and fold real fixes into the main work. Do not separately re-audit commits whose only purpose is to fix `fess` findings, nor `partner-cleanup`'s own cleanup commits (it self-verifies) -- that loops without progress. 4. Check `doc/observations/`; if non-hidden Markdown is present, run `partner-cleanup`, let it make its cleanup commit, then resume. 5. On cadence (below), bring the branch current: rebase or restack it LOCALLY onto its base, resolving conflicts with the `resolve` workflow. Do NOT submit or push the stack as part of the loop -- pushing rewritten or shared history is a terminal, human-gated action (see Stop and escalate). 6. Repeat until the Definition of Done holds or a stop condition fires. ## Cadence Use clock readings and persisted timestamps for the `refocus` skill's hourly deadline. Keep Git cadence anchored to work: - Commit at each completed logical unit. - Rebase or restack before starting a new independent unit, or whenever the base may have moved -- staggered from commits so a restack and a commit never collide in the same step. Do not batch many units into one giant commit, and do not thrash by committing or restacking mid-unit. ## Keep the branch current Keep the branch rebased on its base as you go: on a Graphite stack follow the `restack` procedure (rebase from the base of the stack up to the current branch, not above); off Graphite, `rebase` and `resolve`. In the loop this is a LOCAL currency operation only -- submitting or pushing the stack is a separate, human-gated step, never part of the cadence. ## Parallelize non-interfering work Use the `parallelize` skill. As coordinator you keep all git and shared-state changes in this session and dispatch only safe, non-interfering work -- research, isolated file generation, the `fess` audit, reviews -- to subagents that write only inside their own namespaces and return artifacts you integrate. Its no-history sentinel contract is mandatory for the `fess` audit and review roles. Bound fan-out to what you can review (roughly 3-5 at a time), and do not let subagents spawn their own subagents. ## Confer via PAL for real decisions For genuine plans, designs, significant decisions, or critical reviews -- not routine steps -- use PAL MCP to reach consensus with the configured reasoning models, `@NIX_MODEL_PAL_PARTNER@` and `@NIX_MODEL_PAL_REASONING@`. Think deeply, gather the relevant context, and let the consensus shape the plan.