edit-statusline
Skill1 starsChanged 3 months agoMITView on GitHub
Check what the Claude Code statusLine payload carries now against a past example, decide with the user whether the status line should show something new (or stop showing something gone), and edit statusline-command.sh. Use when the user asks to update / review / change the status line, says a field appeared or disappeared (e.g. "5h limit is gone"), or after a Claude Code update.
In this repository15 other files it gives its agents.
- autonomy-statSkill
- check-usageSkill
- compact-unfreezeSkill
- formalization-statement-fidelity-auditSkill
- get-contextSkill
- github-math-checkSkill
- heart-beatSkill
- manim-ttsSkill
- mermaidSkill
- my-github-md-ruleSkill
- nostrSkill
- sessiondbSkill
- use-bmsSkill
- use-fandomSkill
- webapp-defaultsSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 1 is distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 42
No edit → stop here: Leave example.json as it is, even if it differs from the current payload.
- Distinctive: line 60
Test the script on the current payload without touching the real log:
- Very specific: line 82
All payload fields are read in the single jq call (one process per redraw).
- Very specific: line 83
Add new fields there; keep .workspace.current_dir last (free text).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
edit-statusline
Files (all in scripts/, i.e. ~/my-skills/skills/edit-statusline/scripts/):
| File | What |
statusline-command.sh | The status line itself. ~/.claude/statusline-command.sh links here (and ~/my-skills/statusline-command.sh too, for older links). |
example.json | A past payload, redacted. The baseline to compare against. |
compare.py | Compares the key structure of example.json with the latest payload. |
redact.py | Redacts a payload so it can become the new example.json. |
statusline-command.sh writes the raw payload of every redraw (of any
session) to ~/.claude/statusline-last-input.json. That file is "the current
payload". It is raw: never commit it, never paste it whole into a public place.
Workflow
Compare.
python3 ~/.claude/skills/edit-statusline/scripts/compare.pyIt prints added / removed / type-changed key paths, value-dependent differences (a null on one side — not a schema change), and the paths the script reads that are absent now. Keys marked
(situational)appear only in some situations (git repo, worktree, agent, vim, PR); their absence proves nothing. Ifstatusline-last-input.jsonis missing or old, any redraw of any session rewrites it — just run the compare again.- Decide with the user. Report the differences (a short table: key, example, now). For each new key, say what it holds and whether it would be useful on the status line; for each key the script reads that is gone, say what goes blank. Propose concrete changes, and let the user decide whether to edit at all.
- No edit → stop here. Leave
example.jsonas it is, even if it differs from the current payload. Do not commit anything. - Edit → change both files.
- Edit
scripts/statusline-command.sh. Keep its header comment in sync (the "Line 2:" layout line and the notes). Regenerate the baseline:
cd ~/my-skills/skills/edit-statusline/scripts python3 redact.py > example.jsonredact.pyreplaces every id, path, session name and repo field with"..."and prints the strings it kept on stderr. Read that list: if a new field holds something personal (a name, a path, an id, a URL, a token), redact it by hand inexample.jsonand add its key toKEYSinredact.py.Test the script on the current payload without touching the real log:
cd ~/my-skills/skills/edit-statusline/scripts STATUSLINE_USAGE_LOG=/tmp/sl-test.log STATUSLINE_LAST_INPUT=/tmp/sl-test.json \ bash statusline-command.sh < ~/.claude/statusline-last-input.json | cat -v(Use the session scratchpad instead of
/tmpwhen one is given.)
- Edit
- User checks the diff. Show
git -C ~/my-skills diff(both files) and wait for the user's OK. - Commit
~/my-skillswith the/commitworkflow (no version bump).
Rules
~/.claude/statusline-usage.logkeeps 5 columns (<epoch> <five%> <week%> <five_resets_at> <week_resets_at>,-if absent). The check-usage skill parses it by position. Changing the format means changingskills/check-usage/scripts/check-usage.pyin the same commit.- All payload fields are read in the single
jqcall (one process per redraw). Add new fields there; keep.workspace.current_dirlast (free text).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

