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".
中文简介正在准备中。当前显示原文说明。
安装前可以查看交给 AI 代理的指令内容。
Turn working-tree changes into clean conventional commits and (optionally) a PR. Commit subjects
become the release changelog — the meter computes versions and release notes from them (see
.github/CONTRIBUTING.md -> How releases work).
Honor the repo's laws: branch + PR, never commit to main; conventional commits; never
force-push or rewrite pushed history; never hand-edit generated files (the guard-generated-files
hook denies edits to app/src/shared/data/ and app/src/renderer/public/{sprites,heroes}/).
| Argument | Meaning |
|---|---|
--pr | Open a PR after pushing (default: just commit + push). |
--draft | Open the PR as a draft (implies --pr). |
--issue <n> | Add Closes #n to the PR description. |
-n [name] / --new-branch [name] | Branch before committing; auto-name if none given. |
git status
git diff
git diff --staged
git branch --show-current
git rev-parse --abbrev-ref origin/HEAD 2>/dev/null | sed 's|origin/||' || echo main
No changes → stop ("Nothing to commit."). Conflict markers → stop (ask to resolve first).
main)main/master or -n given → create type/short-description (slug, ≤ 5 words;
type/issue-N-... when --issue): git checkout -b "<branch>".-n → reuse it.Consider staged, unstaged, AND untracked. Group by logical change. Each subject:
type(scope): imperative description # < 60 chars, lowercase, no period, no em dash
type ∈ feat|fix|perf|refactor|docs|style|test|chore|ci|build · scope = the area touched
(app, reader, data, scripts, release, …). These subjects are the release notes — make
each read as a standalone changelog line. Show the grouping before committing.
If the diff touches the renderer (app/src/renderer/**, app/src/**/*.tsx), verify on real pixels —
the renderer rule requires eyeballing, not just unit tests (app/CLAUDE.md):
~/tbh-meter/ artifacts via CDP (full recipe: dev skill —
cd app && pnpm dev -- --remote-debugging-port=9222, write raw/<id>.json + live.json with an
advancing mtime).gh pr comment).If the app genuinely can't run (e.g. a Windows-only path, no fixtures), say so and ask the human for captures — never skip the visual check silently.
git add <files for this group> # explicit paths — never `git add -A`
git commit -m "type(scope): description"
Stage explicit paths, never git add -A (avoids sweeping generated files; the hook denies hand-edits
to app/src/shared/data/ and the generated public/{sprites,heroes}/).
git push -u origin "$(git branch --show-current)"
Rejected and only a force would fix it → STOP, explain, ask the human to run it. Never
--force/--force-with-lease, never rewrite pushed history. To sync with base, merge base in and
plain-push.
--pr / --draft).github/PULL_REQUEST_TEMPLATE.md (use its exact structure).--issue; for an
overlay PR, embed the approved screenshot(s); check the boxes that apply.gh pr create [--draft] --base "$BASE" --title "type(scope): summary" --body "$(cat <<'EOF'
<filled template>
EOF
)"
gh pr merge --auto --squash "$(gh pr view --json number --jq .number)" \
|| echo "Auto-merge unavailable — continuing."
Branch, commits (subjects), PR URL. For an overlay PR, confirm the screenshot(s) render in the PR body.
| Situation | Action |
|---|---|
| No changes | Stop. "Nothing to commit." |
| Conflict markers | Stop. Ask to resolve first. |
| UI change, app can't run | Say so; ask the human for captures. Never skip the gate silently. |
| Push rejected (needs force) | STOP. Explain. Ask the human to force it himself. |
| Generated-file hook denies a stage | Don't fight it — unstage it; edit the generator (app/scripts/sync-data.mjs) instead. |
gh missing/unauthed | brew install gh / gh auth login. |
| Auto-merge unavailable | Non-fatal. Report once; return the PR URL. |
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
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.
中文简介正在准备中。当前显示原文说明。
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 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.
中文简介正在准备中。当前显示原文说明。
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>".
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。