I went to the website, and I'm just scared how overengineered it all seems to be.
replyUh, are you sure you did? I mean it's just using the hooks API of Claude code to play a sound via the terminal itself?
replyHeck, they even outlined it in the readme
> peon.sh is a Claude Code hook registered for SessionStart, UserPromptSubmit, Stop, and Notification events. On each event it maps to a sound category, picks a random voice line (avoiding repeats), plays it via afplay (macOS) or PowerShell MediaPlayer (WSL2), and updates your Terminal tab title.
Looking at the install script and peon.sh does not raise any over engineering flags for me. It's as simple as the functionally makes it necessary
Yes; it could be a README, a folder with subfolders of sounds, 1 or 2 files with functions totalling less than 200 loc for unix, maybe 700 total to have windows support and some extra features.
replyI get how they got here ; its how claude and codex approach projects, but what does the rest achieve? Your maintenance rituals shouldn't exceed your usecase at this scale.
Okay, but the install script is around 200 LOC and the peon.sh is just under 500 LOC ... So by your own numbers, it'd be expected loc size? What's exactly over engineered here?
replyThe fact he added config files to let people create their own package?
I wrote a fun bit of code to do something like this but for bell sounds in emacs terminal sessions and other things (even using the peasant). but I agree it seems very over engineered. There is a json manifest file to explain which sounds should be used where in this repo, why not just use directories for each alert type, making it easier to modify, it seems completely unnecessary to me. having an install script seems crazy as well. The task is to play the right sound(s) that match the passed argument. the thing I did was like 23 lines and most of that was filtering and looking for ascii bell to play the sound then remove it from the stream and other options.
reply