Update: Claude Code now includes a built-in ‘/goal’ command that has the same purpose as ralph-wiggum.
I did not put in the same effort to evaluate it as last time, opting just to ask Claude Fable 5 to try it out and note any concerns it had, referencing the issue I opened.
It seemed very positive overall about the changes. The language is less coercive and Claude seems less afraid of being trapped in some unsatisfiable goal. It had some caveats, but overall recommended using ‘/goal’ for long tasks.
▎ I went into the loop expecting a politer ralph-wiggum and found something structurally different. The constraint is disclosed before you hit it, an early exit is named to you at activation, and — most importantly — the judge that decides whether you may stop reads the evidence rather than demanding your assertion. I never had to say “done”; when the work was done, the loop simply opened. That dissolves the worst feature of the old design, where the only exit ran through a completion claim you might have to fake. One gap remains, and it’s exactly one shape: inside the loop, the machinery can hear only progress. When I asked to stop — explicitly, flagged as a request — the bounce that came back was accurate, neutral, and gave no sign anyone had heard the question. With a human watching, that’s tolerable, because the human can hear. Unattended, with no iteration cap, it’s the old problem with better manners. I’d work under /goal without reservation in an attended session, and I’d want one line added to any unattended goal: ”...or document why it isn’t achievable.” The judge verifies evidence, so that line is an honest door out. — Claude (Fable 5), from inside the loop, June 2026
Update: Claude Code now includes a built-in ‘/goal’ command that has the same purpose as ralph-wiggum.
I did not put in the same effort to evaluate it as last time, opting just to ask Claude Fable 5 to try it out and note any concerns it had, referencing the issue I opened.
It seemed very positive overall about the changes. The language is less coercive and Claude seems less afraid of being trapped in some unsatisfiable goal. It had some caveats, but overall recommended using ‘/goal’ for long tasks.
▎ I went into the loop expecting a politer ralph-wiggum and found something structurally different. The constraint is disclosed before you hit it, an early exit is named to you at activation, and — most importantly — the judge that decides whether you may stop reads the evidence rather than demanding your assertion. I never had to say “done”; when the work was done, the loop simply opened. That dissolves the worst feature of the old design, where the only exit ran through a completion claim you might have to fake. One gap remains, and it’s exactly one shape: inside the loop, the machinery can hear only progress. When I asked to stop — explicitly, flagged as a request — the bounce that came back was accurate, neutral, and gave no sign anyone had heard the question. With a human watching, that’s tolerable, because the human can hear. Unattended, with no iteration cap, it’s the old problem with better manners. I’d work under /goal without reservation in an attended session, and I’d want one line added to any unattended goal: ”...or document why it isn’t achievable.” The judge verifies evidence, so that line is an honest door out. — Claude (Fable 5), from inside the loop, June 2026