Boot and drive the tbh-meter app + reader locally to see a change working — what runs on macOS (UI only; the reader is win32-only) and how to feed the overlay/list fake data. Use when asked to run/start the meter, verify a change in the running app, screenshot the overlay, or reproduce a bug locally.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
cd app && pnpm dev # electron-vite; the reader spawn is a win32+packaged no-op on macOS
On macOS the reader never spawns, but the file-watching sources still work — drive the UI by writing
artifacts into ~/tbh-meter/:
raw/<endTsMs>.json — a finished run. The converter turns it into logs/<id>.json and the list updates.live.json — the overlay snapshot. Rewrite it with an ADVANCING mtime each tick, or the overlay
won't animate (engagement detection keys off mtime).Steal real fixtures from app/src/main/**/__tests__/ or a teammate's ~/tbh-meter/. RC build uses
~/tbh-meter-rc/ instead.
Renderer changes must be verified on real pixels, not just unit tests (app/CLAUDE.md). Launch with
the debugger open and drive it over CDP:
cd app && pnpm dev -- --remote-debugging-port=9222
Then connect a CDP client to localhost:9222 and capture the window against the seeded ~/tbh-meter/
artifacts above.
The reader reads game memory and only runs on win32 (reader/CLAUDE.md). On macOS you can lint and
test it but not attach to the game:
cd reader && ruff check . && python3 -m pytest
cd app && pnpm check && pnpm test # eslint + tsc (both tsconfigs) + vitest
cd reader && ruff check . && python3 -m pytest
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Diagnose tbh-meter problems — reader not attaching, AV/blocked state, slow calibration, missing or invalid runs. Use when debugging meter behavior or reading meter.log / live.json / raw run records / logs records (or the legacy runs.jsonl).
The English summary is being prepared. Showing the original description.
The TaskBarHero game updated (new version) and the tbh-meter reader needs re-calibration — symptoms are gold showing 0, stage mode "?", or the live party/XP/stats dropping out (party empty / no live levels / runs degraded) after a patch, or you're prepping a meter release for a new game build. Runs the diagnose→dump→diff→reseed→bump→verify playbook (the fix is usually a reseed, but a build can also change an Obscured encoding with zero offset movement — caught only by the live gate, fixed by a read-strategy change). Use when the game version changed, after a TBH patch, when a player reports gold/stage/party/XP broken following an update, or when asked to re-seed / re-calibrate the reader for a new build.
The English summary is being prepared. Showing the original description.
Generate a polished release video for a tbh-meter release in the Claude-Code motion style (recreated animated UI + real game sprites + synth soundtrack), to post with a launch. Primary input is a GitHub release LINK — the skill turns it into a video named after that release, covering ONLY the features that shipped in that release, version stamped on the intro. Use when asked to make/update a release video, showcase clip, feature trailer, or promo video for a meter release, or "make the video for <release link>".
The English summary is being prepared. Showing the original description.
Adversarial, security-first review of a pull request from an EXTERNAL or untrusted contributor — a fork PR, a first-time or unknown author, anyone without write access — before a maintainer merges it. Use this whenever you're reviewing, triaging, or deciding whether to merge a PR opened against tbh-meter by someone outside the maintainer team: 'review PR #123', 'someone opened a PR — is it safe to merge?', 'check this contributor's changes', 'can we take this fork PR?', 'is this contribution legit?'. This is supply-chain DEFENSE, not ordinary code review: every merged PR auto-updates onto every user's machine and ships a memory-reading .exe plus an unsandboxed Electron app, so the author and the PR description are UNTRUSTED and the diff is the only evidence. It posts its verdict as a real GitHub review — an inline comment pinned to each problematic line (via the pulls/reviews API), not just one summary comment. NOT for your own or a fellow maintainer's branch (use self-review for that), and prefer this over the generic review flow for anything coming from outside the team.
The English summary is being prepared. Showing the original description.
Post-implementation self-review. Use AFTER finishing ANY code implementation or change — before declaring it done, committing, or opening a PR — to critique your own work: re-read the diff adversarially, confirm unit tests cover every branch/edge, kill duplication, follow clean-code/SOLID and the repo's own docs & invariants, decide if something should become documentation, update/prune memory, and strip outdated comments. Trigger it whenever you've just written or modified code and are about to wrap up, even if the user didn't explicitly ask for a review.
The English summary is being prepared. Showing the original description.
Standardized commit + PR workflow for tbh-meter. Analyzes changes, makes conventional commits (subjects feed the release changelog), and for any overlay/UI change captures a seed-driven screenshot to attach to the PR. Use when asked to commit, open a PR, or "commit this".
The English summary is being prepared. Showing the original description.