Claude Code Mods From a Month of Session Logs: Five Bands, Status Line Items, and Commands

Once Claude Code shipped mods, the hard part was deciding what to build. I had Claude read a month of my session logs to find the requests I kept repeating, and ended up with five mods.

The most useful one is leftovers. My cwd is often my home directory rather than a git repo, so git diff can't tell me what Claude actually left behind.

The most important design decision: the button doesn't run anything itself; it hands the suggested command to Claude, which still goes through the usual permission checks.

Mods are function hooks plugins. They can draw a band (a row of UI above the prompt), add a cell to the status line, intercept tool calls, or add a /command.

The official guide, Getting started with Claude Code mods, suggests having Claude read your own session logs first, so that's what I did.

Mining session logs for repeated requests

I asked Claude to look for three kinds of things:

• Things I kept asking about, or kept asking Claude to do.
• Commands that made me nervous, like ones I stopped halfway or asked it to undo afterward.
• How I check Claude's changes.

The range was 19 sessions from September 3 to October 3: roughly 240 messages I typed and 2,725 tool calls.

What it found, ranked by how much it would help, with leftovers at the top:

The fifth, plan-bar, didn't come from the logs. I saw the progress bar in the desktop app and wanted one in the CLI too.

leftovers: what Claude left behind

A single session of mine often touches 3 to 5 places, and in the same month I ssh'd into servers 91 times.

No single git diff shows the whole picture in that situation.

leftovers works out what was left behind from Bash command patterns, like launchctl bootstrap, systemctl enable, docker compose up -d, crontab, git worktree add, and cp x x.bak. When the matching cleanup command shows up later, that item gets crossed off.

Commands written in unusual ways get missed, which is a built-in limit of pattern matching.

The most important decision is in the Clean up button. Pressing it sends Claude a prompt with the suggested cleanup command, and Claude checks that the thing still exists before removing it.

Running systemctl disable on a server straight from a button is too risky.

In practice, when it's something you can't undo, like deleting a repo, Claude asks me first.

There's also an Uncommitted section. It maps the directories Claude touched back to their git repos and lists uncommitted files at the end of each turn, which covers the third category: how I check changes.

The other four mods

your-turn lists the manual steps Claude handed to me above the prompt.

The longest one in the evidence went about 7 hours between Claude listing it and me reporting back, with a context compaction (older conversation summarized to free up space) in between.

The key design point is controlling when to call the model. Only when a reply at the end of a turn looks like it contains something for me to do does it make one haiku call to extract it, capped at 8 seconds.

When only one item is pending, it doesn't ask the model at all. If I reply with something like "done", it's crossed off directly.

notes-due only adds a reminder for whether it's time to write notes. After a merge, a deploy, or creating a new repo, the status line shows a count of N notes not yet written, and running /session-notes resets it to zero.

secret-mask only masks Bash output.

Results from Read, Edit, and Write are left alone, because that's the original text used to edit files later. Masking it would make Edit fail to match, or write the masked value back into a config file.

plan-bar registers two tools, plan_set and plan_update, and asks Claude to use them for any work with three or more steps. Claude drives the progress bar itself.

A terminal can only draw it with block characters, so it can't do the rounded labels the desktop version has.

Installing, and pitfalls when writing mods

plan-bar, leftovers, and secret-mask were later cleaned up into the public homieyangg/claude-code-mods repo. To install (the commands are covered in the Claude Code plugin docs):

/plugin marketplace add homieyangg/claude-code-mods
/plugin install leftovers@claude-code-mods
/reload-plugins

One pitfall worth writing down: $ (the mods API object) can only be passed to functions declared at the top level of the file.

A closure inside register that takes $ makes the whole module fail to load. The shared function that draws the band has to be declared at the top level, with $ passed in.

Also, don't keep a mod with the same name in both a dev directory and the installed folder, or it gets loaded twice on resume.

Mods need tests too. After every change I run claude plugin validate and claude plugin test.

The day the first version went live I started reworking how you interact with the bands, and leftovers got a few blind spots patched along the way. That's covered in clickable bands and what leftovers still can't see.