Set the Bar and Walk Away: /goal Fixes and Merges a PR

I've been running Moebius for eight or nine years now, and it's open source, which means people send in code of, let's say, questionable quality. There's a CONTRIBUTING.md right there in the repo. Does the code coming in follow it? Maybe. Usually not. Checking every PR by hand takes a lot of time and a lot of effort, so I wanted to see if Claude Code's /goal could do it for me.

/goal sets a goal that Claude checks before it stops. It loops, and loops, and loops, until a condition is met: a do-until, or a while loop if you prefer. Here's the goal I dictated with Wispr Flow, aimed at the PR Claude opened for issue 120 in the last lesson:

/goal 1. Check for open PRs with the label Claude. This is code that was written by you. I want to make sure that the code complies with our CONTRIBUTING.md policies and that there are at least 5 tests: 1 happy path and 4 sad paths. There can be 2 happy paths, of course, but I want to make sure that there's at least 1 happy path and then some sad paths to comply with my testing.
2. Do a cursory code review to make sure that it's not introducing anything lame.
3. If everything passes, remove the Claude label and in progress from the associated issue, and close the issue with a comment that it is signed off by you.If the code review fails, I want you to label the issue with "question", remove "in progress", and leave a comment as to what failed, and then move on.

The review failed: not enough sad paths, and the PR wasn't small and focused the way CONTRIBUTING.md asks. Which is fair! But I'd given it an exit, so it labelled the issue and moved on. What I should have said was "fix it until it's done", so I went back and changed the end of the goal:

/goal 1. Check for open PRs with the label Claude. This is code that was written by you. I want to make sure that the code complies with our CONTRIBUTING.md policies and that there are at least 5 tests: 1 happy path and 4 sad paths. There can be 2 happy paths, of course, but I want to make sure that there's at least 1 happy path and then some sad paths to comply with my testing.
2. Do a cursory code review to make sure that it's not introducing anything lame.
3. If everything passes, remove the Claude label and in progress from the associated issues. If the check doesn't pass, I want you to fix the problem, make sure it passes review, and make sure the testing and other things comply. Once you're finished, you can remove the labels, as noted, close the issue, and then also close the PR and merge it in.

Merging without a human might not be your thing, and that's fine. On this library I'm OK with it. Claude rebased the branch, fixed the tests, merged PR 121 and closed issue 120 with a sign-off comment. Is that a good thing? I don't know, I'll leave that to you. I'll also be straight with you: I don't use /goal much. I like working against issues with a broader sense of orchestration, which we'll get to later. But if you've inherited a code base that doesn't build (in .NET, Go, Elixir, whatever), "everything compiles" makes a pretty great goal.