damson
UserHard-won habits for Claude Code — themed plugins of battle-earned skills, each extracted from a real session where not having it cost something.
Categories
Indexed Skills (43)
agent-config-audit
Audit AI agent configuration files (CLAUDE.md, AGENTS.md, preference files) for contradictions, duplication, bloat, and personal/team boundary violations. Use when unsure which instruction files are active for a project, after restructuring how your config is organised, or when the same rule turns up in two files with different wording. Do NOT fire to write or restructure one file (that is `claude-md-pointer-check`), to judge whether a single addition earns its place (`redundancy-check-before-ship`), or on source, tests and config values: this reads the instruction files as a set and reports what they do to each other.
claude-md-pointer-check
Use before creating a CLAUDE.md, or before an edit that adds or rewrites a whole section of one — not for typo- or line-level fixes. Detects when a sibling AGENTS.md or README.md already covers the planned content, rewrites the CLAUDE.md as a pointer + Claude-only delta instead of a duplicate, and flags unactionable phrasing found in the sibling on the way through.
prompt-coach
Use when the user asks "rate my prompt" / "evaluate my prompt(s)" / "how am I prompting?" / "give me prompt feedback" / "score my last prompt" / "4Ds analysis" / "prompt retrospective". Also use when the user asks for an end-of-session review of their work-with-Claude habits, OR after a session involving 20+ turns where the user explicitly wants improvement signal. NEVER fire unsolicited — prompt critique without consent is unwelcome.
redundancy-check-before-ship
Use before committing an addition to any prose-rule file — CLAUDE.md, AGENTS.md, a docs/ page, a README, or a PR template. Fires when a diff ADDS conventions, rules or procedures in prose. Auto-trigger after writing such an addition and before `git commit`, and when the user says a file is "too big", "has duplicates", or asks whether a change "is really necessary". Skip for code, tests, config values, pure deletions, rewording that adds no rule, and new files with no sibling docs. For the CLAUDE.md-vs-sibling file-structure rewrite specifically, defer to `claude-md-pointer-check`; this skill covers rule-level dedup across any prose-rule file.
save-before-compact
Use ONLY when the user explicitly wants to compact a long session without losing its learnings — triggers like "save before compact" / "wrap up and compact" / "session's too long, compact but keep the takeaways" / "capture learnings then compact". NEVER fire unsolicited. This skill APPLIES changes (CLAUDE.md / preference-file additions, memory, new skills) and writes a resume brief, then stops for the user to run /compact — it never runs /compact itself. Thin sessions get only the resume brief; in-flight high-stakes ops defer (Step 1 has the thresholds).
session-retro
Use ONLY when the user explicitly asks for an end-of-session retrospective — triggers like "session retro" / "end of session retro" / "session retrospective" / "wrap up the session" / "what did we learn this session" / "what should I take away from this session" / "let's reflect on this session". NEVER fire unsolicited — this skill produces evaluative feedback on the user's prompting, and reflection without consent is unwelcome. Skip when the session has fewer than ~15 substantive turns (signal too thin), or when the user is mid-incident / mid-deploy. If a sub-skill already ran this session, the retro asks whether to re-run or reuse its output rather than silently duplicating it.
skill-opportunity-finder
Use when you notice the user repeating the same instruction / asking the same kind of question / correcting you on the same kind of mistake / doing the same manual operation three or more times in a session. Also trigger when the user explicitly asks "what should be a skill?" / "what am I doing manually?" / "where am I repeating myself?". Skip during the first ~5 turns of a session — patterns need history to be observable.
sweep-the-siblings
Use when a defect turns up in one member of a family of sibling documents — a skill page, a runbook, an ADR, a workflow file, a per-package README — and the family shares an invariant the repo states somewhere. Fires on "is that wrong anywhere else?", on filing an issue for a single instance, and after a reviewer finds a fault that is about form rather than content. Do NOT fire when the repo states no invariant to sweep against, when the family has fewer than three members, or for a defect genuinely local to one file.
validate-skill-against-real-project
Use when a portable or generic skill has never been executed against a real project, before trusting it or calling it done. Fire on "validate the skill", "does this skill actually work", "test it against a real repo", when a skill claims to work on "any <stack> project" and no run is on record, or when a skill was reviewed by reading it rather than running it. Skip for project-specific skills, which are allowed to assume one build's wiring.
pre-publication-sweep
Use before a repository or its content crosses the line it cannot come back from — flipping private to public, publishing an extract, pushing to a host others can read. Fires on "make it public", "open source this", "check nothing confidential leaks". Do NOT fire on a repo that is already public — its history is already out, and the task is exposure response, not a sweep — or for content that never leaves the machine.
probe-migration-in-transaction
Use when a change adds or alters a SQL migration whose effect is a behaviour — an RLS policy, a view, a trigger, a grant, an enum, a constraint — and you want to know what it really does before opening the PR. Especially when there is no local Postgres: a transaction against the dev database that is rolled back costs nothing and leaves nothing. Do NOT fire for a bulk data write you intend to keep (that is reversible-bulk-write), for a migration that only adds a column nothing reads yet, or when the only database reachable is production.
read-only-db-probe
Use when a claim needs numbers from a live database and no committed report already produces them — sizing a cohort before a design decision, verifying a reviewer's assertion against the data instead of arguing, checking what a load actually left behind. Produces a throwaway read-only script in the session scratchpad and quotes what it printed. Do NOT fire for anything that writes (that is reversible-bulk-write), or when the repo ships a report command that already answers the question — run that instead.
reversible-bulk-write
Use when about to write in bulk to a live datastore — importing a dataset, backfilling a column, a mass UPDATE, any statement whose blast radius is "lots of rows". Fire before the first write, not after it goes wrong. Also fire when a bulk write has already gone in and needs undoing. Do NOT fire for ordinary single-row writes, for schema migrations (those have their own review and apply path), or for writes to a throwaway or local database.
supabase-ci-migration-guards
Use before writing or reviewing any migration that references Supabase-managed schemas — `auth.users`, `auth.uid()`, `storage.objects`, `storage.buckets`, `realtime.subscription`, `supabase_functions.*`, or any policy / function that depends on `auth.jwt()`. Auto-fire when a diff in `supabase/migrations/*.sql` matches the regex `(auth|storage|realtime)\.|to_regnamespace|create or replace function .* returns`. Also fire when the user says "fix the CI migration job" / "migration failed in CI" / "vanilla postgres errored on this migration" / "schema auth does not exist". Skip if the migration only touches the `public` schema with no Supabase-namespace references.
verify-db-posture-at-the-target
Use after a change to row-level security, grants, policies or function privileges reaches a live Postgres or Supabase project, and before reporting it closed. Fires on "verify it", "did the push work", "is the advisor clear now", "check production", and after a hand-run fix on a database no migration ledger records. Do NOT fire for schema shape alone (a column, an index, a type), for a change that has not been applied anywhere yet, or when the only question is whether a test passed.
separate-persuasion-from-deception
Use when a change touches something the user can lose: a price, a fee, a recurring charge, a consent or permission grant, a pre-selected default, a cancel, unsubscribe or delete path, or a prompt whose job is retention. Fires on "is this a dark pattern", on designing a paywall, trial, upsell, consent dialog or notification opt-in, and before shipping a flow whose conversion depends on what the user does not notice. Do NOT fire for ordinary visual or usability work, for an internal tool with no external user, or for a flow where nothing the user cannot recover is at stake.
await-pr-checks
Use when waiting on a pull request's CI before acting — "merge when green", "wait for the checks", "watch the run", "is CI green?" — and before REPORTING a PR's check state after any push, including one this session made. Also fire when a wait loop is about to be written with `gh pr view`/`gh run list` in it. Goal — a terminal verdict per named check, never a report that mistook silence, an empty field, or the previous run for an answer. Do NOT fire to merge on the result (green authorises reporting, not merging: that is `merge-on-go-ahead`), to diagnose a check that has already reported red (read its log), or for a run with no pull request behind it.
branch-hygiene
Use when a PR has just merged on `origin/develop` or `origin/main`, when multiple open PRs share an ancestor that has now landed, when the user says "rebase the open PRs" / "manage open PRs" / "PR X merged, clean up" / "fix conflicts" / "deal with conflicting PRs", **before merging a PR that another open PR is based on**, or after running `gh pr merge`. Goal — drop duplicate commits introduced by the merge, force-push the open PRs onto the new base, prune dead worktrees and branches, and close the issues the merged PR's keywords could not. Do NOT fire for deliberate history surgery on one PR (dropping, reordering or splitting commits is `rewrite-pr-history`) or for promoting an integration branch to the branch people install from (`close-the-release-cycle`).
bump-vendored-pin
Use when moving a pinned vendored dependency to a new upstream commit — a git submodule gitlink, a GitHub Action's pinned ref, a SHA recorded in a config file. Fires on "bump the pin", "update the submodule", after an upstream merge lands, and after an upstream history rewrite orphans the old SHA. Do NOT fire for floating refs (a branch name or `@main` is not a pin), or when the vendored copy is being edited in place — that is a different mistake, and the fix is upstreaming the edit, not bumping.
capture-pr-screenshots
Use when opening or updating a PR that changes a UI route file (`page.tsx`, `+page.svelte`, a `routes/` entry) without adding a matching screenshot. Also fire when the user says "missing screenshot" / "no screenshot for the UI" / "capture the screenshot" / "screenshot for this PR" / "you forgot the screenshot". Skip on a backend-only PR, or one that already includes screenshots for the surfaces it changes. Where the repo documents its own capture command, run that instead — this skill is the fallback for repos that document nothing.
close-the-release-cycle
Use when promoting an integration branch to the branch people install from, and when finishing one: "release it", "promote develop to main", "cut a release", "ship it", "tag it", or after a release PR merges. Fires on the whole cycle, not just the merge, because the failures live in the steps after it: an untagged release, a floating major tag left behind, and a skipped back-merge that makes the *next* promotion conflict. Do NOT fire for merging an ordinary feature PR into the integration branch.
coverage-pr-comment
Use when reporting code coverage on a pull request, or fixing a report that is not landing. Fire when the user says "post coverage on the PR", "show the coverage delta against the base branch", "the coverage bot adds a new comment every push", "add a threshold / red-amber-green band to coverage", "coverage dropped and nobody noticed", or when a PR carries a bare coverage percentage that no reviewer acts on. Stack-agnostic — JaCoCo, lcov, Istanbul, coverage.py, go cover, SimpleCov, coverlet. Skip for GitLab MRs, whose discussion API needs its own upsert; when Codecov or Coveralls already comments, stop and ask before adding a second (see When to STOP).
github-pr-screenshot-embed
Use when embedding a screenshot or image in a GitHub PR description or comment, especially for a PRIVATE repo. Fire when the user says "the screenshot is a broken image in the PR", "embed this in the PR", "the image doesn't render for reviewers", "add a before/after image to the PR", or when a raw.githubusercontent.com link shows as a broken image. Skip for GitLab MRs — GitLab rewrites uploaded paths differently and needs its own upload step.
merge-on-go-ahead
Use when the user authorises merging pull requests they name: "merge #4", "12 and 13 are ready", "land 21 and 22", or a bare "go ahead" in a thread about one identified PR. Owns only the merge itself: it confirms the authorisation covers this PR at its current head, checks the gates the repo actually enforces, merges in the repo's own convention, and waits out the recomputation before touching a dependent PR. Do NOT fire without an authorisation naming the PRs, on a promotion to the branch people install from (that is a release), or to decide WHETHER something should merge.
parallel-pr-fanout
Use when a batch of 3+ independent changes should land as SEPARATE pull requests built by parallel agents — "address all of these", "fix everything on the list", "make as much parallel work as possible", a review or audit producing many unrelated fixes. Goal — reviewable, file-disjoint PRs that merge in any order. NOT for coupled changes (one PR), sequential work (a stack), or generic non-PR parallelism (that is plain agent dispatch).
pr-comment-loop
Use when an active branch has open PRs that may have received new comments since the last check. Auto-trigger after any `git push` to a feature branch, after merging a PR (its siblings' review threads may have moved), and any time the user asks "is PR N ready?" / "what's the status of PRs?" / "manage the open PRs" / "anything to address in PR N?" / "review the PR comments". Also fires **before handing over a PR on a repo no bot reviews**, where the job is to obtain a review rather than process one. Skip if no PRs are open or if the user explicitly says "ignore the comments".
rescue-a-shared-checkout
Use when a working tree you do not exclusively own carries uncommitted changes somebody else wrote — a second agent session, a colleague's machine, a long-lived VM, a tool that wrote into the tree behind you. Fires on "whose changes are these", "the tree is dirty and it isn't mine", "sort out the pending changes", and before cutting a branch from a tree whose dirt you did not create. Do NOT fire for your own uncommitted work, or for a tree you are certain nothing else writes to.
rewrite-pr-history
Use when deliberately editing the history of an open PR's branch — dropping, reordering, splitting or rewording commits, or squashing before review. Fire on "remove the X commit from PR N", "reorder the commits", "drop the last commit", "clean up the history before review". For the routine post-merge rebase of open PRs (duplicate commits after a parent landed), use branch-hygiene instead — that is mechanical cleanup, this is surgery.
stand-in-for-a-blocked-review
Use when a pull request's automated review did not happen while its merge gate still reads green: the reviewer posted a quota or limit notice, skipped the pull request over who opened it, or never ran at all, and its status says success anyway. Confirms the review is genuinely missing, takes the cheap recoveries first, checks whether this exact content was already reviewed somewhere else, and only then commissions an independent agent review and posts it as the record. Do NOT fire when the reviewer posted findings (answer those instead), when the quota resets inside the time you can wait, or to decide whether the pull request should merge.
watch-what-the-merge-triggered
Use immediately after merging into a branch that workflows watch — an integration branch, a release branch, anything with `on: push`. Fires on "merged", "it landed", "that's in now" when the base has deploy, migrate, publish or notify workflows, and whenever a merged PR touched a workflow file or a path some workflow filters on. Owns the run the MERGE starts: which workflows it triggers, watching them to a terminal state pinned to the merge commit, and treating that run as the first and only exercise of merge-time credentials. Do NOT fire for a merge into a branch nothing watches, for the PR's own checks (await-pr-checks owns those), or to confirm that the merged diff contains what was claimed, which is a question about content rather than about runs.
wire-scheduled-workflow
Use when adding, renaming or debugging a GitHub Actions workflow that carries a `schedule:` or `workflow_dispatch:` trigger — especially in a gitflow repo where workflows land on `develop` first. Fire on "the cron never fired", "the workflow doesn't show up", "dispatch says workflow not found on the default branch", HTTP 404 from `gh workflow run`, or a review of a diff that adds either trigger. Skip for workflows with only `push` / `pull_request` triggers — those run from the pushed ref and have no registration step.
worktree-bootstrap
Use immediately after `git worktree add` or `git gtr new` creates a fresh worktree for any repo (a web/Next app, a Node/TypeScript backend, a Python data/ETL project, an Android/Gradle app, or anything else) and it won't run or build because .gitignored env files and installed dependencies weren't carried over. Fire when the user says "set up the worktree", "the new worktree won't build/run", "missing .env in the worktree", "node_modules is missing", "gradle can't find the SDK / local.properties", or a dev server errors on missing env vars right after a worktree is created. Skip when the repo ships its own bootstrap skill — that one knows its extra credential files and hooks. Skip if the worktree has already run once.
android-screenshot-baseline-record
Use when recording or re-recording screenshot-test baselines (golden images) in any Android/Compose project — Roborazzi, Paparazzi, or AGP's Compose Preview Screenshot Testing. Fire when the user says "record the baselines", "regenerate the screenshots", "update the snapshots", "the goldens are stale", or stages a new screenshot test with no images beside it. Skip when the project ships its own recording skill — that one knows its build's wiring. For checking existing baselines still pass, use android-screenshot-baseline-verify.
android-screenshot-baseline-verify
Use when checking that existing screenshot baselines still pass in any Android/Compose project — before pushing, after a refactor, a theme or design-token change, or a dependency bump. Fire when the user says "run the screenshots", "do the baselines still pass", "check the goldens", or asks whether a refactor changed the rendered output. Skip when the project ships its own verification skill. To create or update baselines rather than check them, use android-screenshot-baseline-record.
android-verify-on-device
Use when a UI or behaviour change has to be confirmed on a running Android app rather than by a test — a setting that must take effect, a screen that has never been opened, a class the project cannot construct under Robolectric. Fire when the user says "check it on the device", "does it actually work", "run it and look", or when a change lands in a class that reaches Play Services and so has no unit-test seam. Fire also when a layout question has been answered twice from captures and the answer keeps moving, or when what is on screen depends on something a test cannot supply: a filled ad, a real inset, an orientation the manifest may lock away. Skip when a screenshot golden or a Robolectric test can hold the same claim — they are cheaper and they run in CI, which this never does.
figma-to-compose-component
Use when building or recreating a Jetpack Compose component from a Figma design in any Android project. Fire when a figma.com/design or figma.com/file link is paired with "build this", "implement this component", "recreate this in Compose", or a ticket references a Figma node id. Covers retrieving the node without flooding context, checking the design system before writing anything new, and binding to theme tokens rather than raw values. Skip when the project ships its own design-system skill — that one knows its component catalogue.
ship-a-fix-round
Use when a user reports on-device findings against an Android build and expects fixes and a new APK back: "X is broken, fix it", a list of UI complaints from a test session, a bug with repro steps on hardware. Owns the whole round: root cause, fail-proofed fix, goldens, the repo's full gate, focused commits, the PR brought up to date, a fresh build handed over, CI watched on the pushed commit. Do NOT fire for a change nobody reported, for a non-Android build (the diagnostics here are adb's), or to skip the parts a round already verified.
diagnose-a-lying-signal
Use when a status surface and reality disagree: a green check for work that cannot have happened, a badge reading "unknown" or an implausible number, a run that failed with nothing in it, a command that "found nothing" it should have found. Fires on "the check is green but...", "the badge still says unknown", "why did that fail with nothing in the log", "it says it passed but nothing ran", "that number cannot be right". Do NOT fire for an honest failure with a real error in a real log: that is debugging, and the log is already telling the truth.
mutation-proof-harness
Use when about to prove that newly added guards can fail: a checker, a lint, a CI script, a validation function, and more than one needs proving. Fires on "prove the check can fail", "mutation proof", "watch it go red", and whenever a PR test plan is about to claim a guard was proved. Owns the SCRIPT: the baseline that stops a typo'd filter reading as a pass, the diff that stops a no-op mutation reading as a working guard, and the restore. Do NOT fire for a single ad-hoc mutation, or to decide WHETHER a guard is worth proving: prove-the-check-can-fail owns that.
prove-a-procedure-on-a-fixture
Use before claiming that a documented procedure's commands work: a skill, a runbook, a README whose steps a reader pastes into a terminal. Fires on "this handles renames and deletions", "the block is paste-and-run", "the step is fixed", and on answering any review finding about embedded shell. Do NOT fire for prose that ships no commands, for a check or a test (that is `prove-the-check-can-fail`), or where CI already runs the procedure against the same awkward cases on every push.
prove-the-check-can-fail
Use when adding or relying on a test, assertion, screenshot golden, lint rule or CI step meant to catch something, before trusting it or reporting it as coverage. Also fire when wiring a check into CI, when a check passes on its first run having never been seen red, or when the user asks "does that actually test anything" / "is that really covered". Do NOT fire for test-driven work, where the test was already seen failing before the fix.
render-the-candidates
Use when a requirement about layout, geometry or visual arrangement has round-tripped twice without converging: you changed the code, the user restated the requirement, and it is still not what they meant. Fires on "still don't end up", "that's still wrong", "I'm still confused by", "it had been correctly designed", and on your own impulse to write a third paragraph explaining what you think they mean. Do NOT fire on the first miss, where only one reading is actually plausible, or where the disagreement is about behaviour rather than about something that can be seen.
verify-dependency-behaviour
Use when about to state or rely on how a third-party JVM/Android library behaves (a default value, whether a field is omitted or null, which branch a task takes) and the docs are absent, ambiguous, or the naming suggests something the code may not do. Fire when a plan says "set X to its strict value" without evidence X is not already strict, when a field's name and its type disagree, or when a check passes and you cannot say which comparison it made. Do NOT fire when the behaviour can be run and observed, run it.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.