speedrun-splits

speedrun-splits puts a speedrun timer above the Claude Code prompt and splits each task on its own, from Claude’s first file read to the pull request. Every split shows how far ahead or behind your personal best you are, and each repo keeps its own records. It costs no tokens.

What it does

A run starts with your next prompt and splits on six phases, each stamped the first time it happens:

1. recon: the first file Claude opens with its Read tool.
2. first blood: the first change to code in this repo, from an edit, a write or a shell command that changed files.
3. test run: the first test or typecheck command after that change. The segment ends when the tests start.
4. green: the first test run that passes, typechecks excluded, stamped when it finishes.
5. commit: a commit Claude Code reports as made.
6. PR: a pull request opened on this repo or its fork parent.

Each split shows its difference from your personal best (PB), green when you are ahead and red when you are behind. A yellow star marks a gold segment: the fastest you have ever done that phase. When the run ends, a toast tells you whether it set a new PB.

Runs end at the PR by default. /splits finish-on commit ends new runs at the commit instead (finish-on pr switches back), and the two kinds keep separate records, so commit runs never compete with PR runs.

/splits prints the board: your PB, the PB split and gold segment for each phase, the sum of best (all your golds added up) and the last five runs. /splits start starts a run by hand, /splits reset drops the current one, /splits clear deletes this repo’s records for the current finish line, and /splits hide or show toggles the timer.

Install

Needs Claude Code 2.1.287 or later and a git repository; runs that end at a pull request also need the GitHub CLI (gh).

claude plugin marketplace add ccdwyer/claude-mods
claude plugin install speedrun-splits@ccdwyer-mods

The marketplace is the author’s collection repository, not the speedrun-splits repository itself. It also carries the same author’s context-dungeon, a roguelike driven by the same session events.

In a session that is already open, run /reload-plugins. Then send a prompt in a repository: the timer starts with it.

How it works

The hooks module starts a run on prompt.submit when none is open, only for prompts a person sends. While the run is open, a clock ticks once a second and the band above the prompt shows the elapsed time, the latest splits that fit the width and the next phase.

The splits come from a tool.call hook that lets every call through unchanged and looks at it after it runs:

• A successful Read by the main agent stamps recon. Subagents’ reads don’t, but their edits, tests, commits and PRs do.
• Edit, Write and NotebookEdit stamp first blood when the file is inside the session’s repo, or another worktree of it, and isn’t generated output such as coverage, snapshots, node_modules, dist or build.
• For Bash, it reads the command text and matches it against known test runners and typecheckers (npm, pnpm, yarn and bun test scripts, jest, vitest, pytest, go test, cargo test, dotnet test, tsc and others), git commit and gh pr create. It follows one cd or --prefix, so tests and commits in another checkout don’t split. It also reads what Claude Code reports about the result: the files the command changed, whether it made a commit or opened a PR, and whether it went to the background. Installs (npm install, pip install) and history moves (git checkout, pull, rebase) are never first blood.

To check that a commit or PR belongs to this repo, it runs git locally (rev-parse, remote -v, reflog, log) with a three-second timeout. A commit counts only when the reflog shows HEAD moved by a commit. When a command runs gh pr create, the mod also uses your gh login to ask GitHub which PRs the branch already has and which repo is the fork parent. Those requests, to GitHub or your GitHub Enterprise host, are its only network traffic. Commit and PR commands sent to the background are polled every ten seconds for up to ten minutes.

Each finished run is saved in Claude Code’s plugin store on your machine, under a key made of the finish line, the repo (its remote as owner/repo, or its root path when it has none) and a run id. The board is rebuilt from those runs, so two sessions finishing at once can’t overwrite each other. It keeps the newest 50 runs per repo and finish line, plus any run that holds the PB or a gold. The only other stored value is your finish-on choice. The hooks add nothing to prompts or tool results.

Limitations

• Green needs a plain test command. A run piped into tail or head, followed by || true or ; echo, sent to the background, or only listing tests (--list, --collect-only) marks the test run but never green, because its exit status doesn’t prove the tests passed. Claude often trims test output with a pipe; the author’s demo prompt asks for plain npm test with no pipes.
• Only a commit or PR made by a shell command counts. A PR opened in the browser or through an MCP server never ends the run; /splits finish-on commit is the way around it.
• The clock is wall time. It keeps running while you are away, and a run stays open until it reaches its finish line: if you drop a task halfway, the next prompt continues the same run unless you /splits reset first.
• A run that never changed code is kept in history but can’t set a PB or a gold.
• Draws only in interactive sessions. The author shows it only in the terminal; the Desktop app’s Code tab is untested.