Once a developer understands a command-line tool, the next question is whether they should have to keep thinking about the same command. In this case the answer was no. The paths, itch.io target, and channel were stable enough to turn a manual push into a reusable project action.
Why I made this
Butler already made game updates faster by sending only the changed parts of a build, but the developer still had to open a terminal and reconstruct the correct directory, project target, and channel for every release.
That is a small amount of friction, but it sits directly in the publishing path. Small release barriers accumulate, encourage inconsistent commands, and make it easier to postpone shipping a build that is otherwise ready.
What I did
I take the known-good Butler push configuration and place it behind a local launcher. The demonstration is intentionally short: update the build, double-click the release action, and let Butler push it to the established itch.io channel.
This complements the from-scratch Butler tutorial already in the archive. One piece teaches the complete mental model; this one shows the next layer of developer-experience work—removing repetition after the workflow is understood.
The video originally linked to a small code gist. That gist is no longer available, so I am not presenting the exact launcher as a reusable current download. The artifact that remains is the design decision and the visible release behavior.
A note on the archive
The recording and its launcher are from 2019. The linked gist is no longer available, and authentication, paths, build output, and platform conventions should be reviewed before recreating a local release script.
The current itch.io Butler manual still centers the workflow on `butler push directory user/game:channel`. Use that manual if you want to build this now. The old clip is here because it shows the natural next question after learning a command: how do I stop retyping it forever?