Sometimes I find myself doing the same thing over and over again. One of those things looked like this:

1. Find that my test suite is failing
2. Open up Claude Code
3. "Please run pnpm test and fix the failures"
4. Wait

Maybe there's only one failing test out of the ~1000 tests in the suite, so we can kinda optimize it a little:

1. Look to see which test file was causing the problem
2. pnpm test /path/to/that/file.test.ts
3. Open up Claude Code
4. Copy/paste the pnpm test ... command and its output and hit enter
5. Wait

That's faster as it lets Claude Code focus on a single test file. But it still involved me doing the work of copying and pasting the command and its output. It's a First World Problem of truly quotidian proportions.

What if I could do this instead, and have it be equivalent to all the hard work described above?:

$ pnpm test /path/to/that/file.test.ts
$ claudify

$ pnpm test /path/to/that/file.test.ts
$ claudify

Turns out that's possible with a fairly simple little shell script. I call it claudify, though I usually alias it to just 'fix'.

How does it work?

It's pretty basic. The entire script is only 70 lines long and most of that is documentation and logging. Here's the core of it:

1. Pulls the most recent command off your shell history (using fc -ln -1)
2. Runs that command again, captures the output
3. Throws the command and its output into a tiny prompt
4. Sends that prompt to Claude Code
5. Prints a subset of the Claude Code output as it works

That's it. It's a pretty dumb and simple script that wraps Claude Code and takes advantage of the -p and --output-format flags supported by Claude Code.

How do you install it?

claudify needs to be a function in your shell, so you can add it to your .bashrc or .zshrc file. My shell-fu is not good enough to make it work via a bash script (because executing a bash script seems to generate a new history stack).

So the answer is to just copy/paste the function into your .zshrc, .bashrc or similar. Make sure you run source ~/.zshrc or source ~/.bashrc to make it take effect.

Grab the file here, or try this one if you're on Windows (no promises on the Windows one as the only thing I use my PC for is playing Doom).

Customizing with reusable instructions

I find myself using this in two main contexts:

1. Fixing a broken Next JS build
2. Fixing failed tests

Claude Code really does not want to write tests the way I want them. If I had a dollar for every time I told it "don't mock the database, insert real data and clean it up afterwards", I'd be a good deal happier in life.

claudify accepts a single parameter that allows you to customize the prompt that gets passed in to Claude Code along with the most recent command and its output (the default prompt is just "Please fix this:"). I tend to just create some simple shell aliases with different instructions based on what I want.

These 2 aliases are the most useful to me:

alias fix="claudify"
alias fixtest="claudify \"Please fix this test. Do not mock the database, \
  instead insert whatever data are required in a beforeEach and delete it again \
  surgically in an afterEach. Do not generate your own UUIDs, \
  let the database do that and read the IDs if you need them.\""

alias fix="claudify"
alias fixtest="claudify \"Please fix this test. Do not mock the database, \
  instead insert whatever data are required in a beforeEach and delete it again \
  surgically in an afterEach. Do not generate your own UUIDs, \
  let the database do that and read the IDs if you need them.\""

So now in my day-to-day, if pnpm build fails, I tend to just run fix and go do something else for a while until it's fixed all the TS issues the most recent vibe coding session introduced. Similarly, if a test fails I'll run fixtest and let it do its thing.

It probably saves me 30 seconds each time I do it. It won't change your life, but it might be mildly convenient once in a while.