agentleFS
MasonFlint44MasonFlint44/claude-spend-statusline/CLAUDE.md

claude-spend-statusline

CLAUDE.md0 starsChanged 2 months agoMITView on GitHub

One bash script, statusline/spend-statusline.sh, rendered by Claude Code as the status line, plus four skills under skills/ that install and configure it. README.md is the user manual and documents every knob and display element. - Every test runs under libfaketime at Saturday 2026-09-05 in America/Chicago, and network calls go through the fake curl in tests/bin/. New tests must work under that clock and never reach the real endpoint; LIVE=1 bats tests/live.bats is the one exception and is for hand use…

  • Commits and pushes

The file

We split this CLAUDE.md into the rules it gives an agent

3 rules. About 0 are common, 0 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    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:

    Every test runs under libfaketime at Saturday 2026-09-05 in America/Chicago, and network calls go through the fake curl in tests/bin/.

    line 16
  2. Very specific:

    Add a ## X.Y.Z — YYYY-MM-DD section to CHANGELOG.md.

    line 42
  3. Very specific:

    Run the checks above, commit, push, and confirm the push landed before tagging.

    line 45

≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md 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
CLAUDE.md

claude-spend-statusline

One bash script, statusline/spend-statusline.sh, rendered by Claude Code as the status line, plus four skills under skills/ that install and configure it. README.md is the user manual and documents every knob and display element.

Verify before committing

bats tests/                        # about 30 s, no network
shellcheck statusline/spend-statusline.sh tests/skills/run.sh tests/skills/triggers.sh tests/bin/curl
UPDATE=1 bats tests/calendar.bats  # only when a golden listing should change; review the diff
DOCKER=1 bats tests/compat.bats    # bash 3.2 / 4.3 / 4.4 images; CI runs this
  • Every test runs under libfaketime at Saturday 2026-09-05 in America/Chicago, and network calls go through the fake curl in tests/bin/. New tests must work under that clock and never reach the real endpoint; LIVE=1 bats tests/live.bats is the one exception and is for hand use only.
  • faketime's clock has about a second of jitter, so boundary tests need a margin rather than an exact second.
  • The script needs bash 4.4 or newer. Everything before the version guard near the top must stay bash 3 syntax so an old macOS bash prints the guard's one line instead of a parse error. compat.bats checks this.
  • tests/skills/run.sh runs the skills through claude -p for real money and copies your credentials into a throwaway config dir; run it by hand, never in CI. So does tests/skills/triggers.sh, which scores the skill descriptions' triggering with the skill-creator plugin's evaluator; run it after changing a description.
  • docs/preview.py regenerates the README screenshot from the script itself (python3, git, libfaketime). Rerun it when the rendered line changes and commit the SVG with the change.

Conventions

  • Which elements show is decided by the display file alone; do not add per-element environment switches.
  • Commits end with Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> and nothing else. No session-link trailer: the repository is public.

Releasing

  1. Add a ## X.Y.Z — YYYY-MM-DD section to CHANGELOG.md.
  2. Set version in .claude-plugin/plugin.json and VERSION= near the top of the script; doctor.bats fails if they differ.
  3. Run the checks above, commit, push, and confirm the push landed before tagging. Then git tag -a vX.Y.Z with the changelog section as the message, push the tag, and gh release create vX.Y.Z with the same notes.
  4. Ship it: the marketplace (~/git/claude-toolbox) pins each plugin to a release tag and its commit, so nothing reaches users until it's re-pinned. There, run scripts/pin.sh spend-statusline vX.Y.Z, then commit and push. Locally: claude plugin update spend-statusline@claude-toolbox, then /spend-statusline:install again.

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.