agentleFS
koteitankoteitan/my-skills/skills/edit-statusline/SKILL.md

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.

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
  1. Very specific:

    No edit → stop here: Leave example.json as it is, even if it differs from the current payload.

    line 42
  2. Distinctive:

    Test the script on the current payload without touching the real log:

    line 60
  3. Very specific:

    All payload fields are read in the single jq call (one process per redraw).

    line 82
  4. Very specific:

    Add new fields there; keep .workspace.current_dir last (free text).

    line 83

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

edit-statusline

Files (all in scripts/, i.e. ~/my-skills/skills/edit-statusline/scripts/):

FileWhat
statusline-command.shThe status line itself. ~/.claude/statusline-command.sh links here (and ~/my-skills/statusline-command.sh too, for older links).
example.jsonA past payload, redacted. The baseline to compare against.
compare.pyCompares the key structure of example.json with the latest payload.
redact.pyRedacts 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

  1. Compare.

    python3 ~/.claude/skills/edit-statusline/scripts/compare.py

    It 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. If statusline-last-input.json is missing or old, any redraw of any session rewrites it — just run the compare again.

  2. 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.
  3. No edit → stop here. Leave example.json as it is, even if it differs from the current payload. Do not commit anything.
  4. 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.json

      redact.py replaces 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 in example.json and add its key to KEYS in redact.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 /tmp when one is given.)

  5. User checks the diff. Show git -C ~/my-skills diff (both files) and wait for the user's OK.
  6. Commit ~/my-skills with the /commit workflow (no version bump).

Rules

  • ~/.claude/statusline-usage.log keeps 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 changing skills/check-usage/scripts/check-usage.py in the same commit.
  • All payload fields are read in the single jq call (one process per redraw). Add new fields there; keep .workspace.current_dir last (free text).

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.