Skills

Agent skills for correctness-first engineering and clear technical judgment.

These skills are tailored toward real engineers, but still usable for vibe coders.

Quickstart

npx skills@latest add CheckPickerUpper/skills

Install everything without prompts:

npx skills@latest add CheckPickerUpper/skills --all

Use one skill without installing:

npx skills@latest use CheckPickerUpper/skills@pizza1

Reference

Every skill also loads on its own when its situation comes up, except readonly, which you add to a question yourself.

Engineering

Skills for code, architecture, APIs, and design decisions, with an emphasis on correctness and simplicity.

Skill	Use it when	Example
antimatter-code-quality-review	Before you merge a change, to get a review that reports only real problems, each with proof and a before-and-after.	/antimatter-code-quality-review the staged changes
antimatter-codebase-structure-review	Before reorganizing folders or modules, or when a change might put code in the wrong place.	/antimatter-codebase-structure-review src/billing
correct-by-construction	The same kind of bug keeps coming back in new forms, or the bug in front of you looks like a sign of a bigger problem somewhere else. You want that problem made impossible to write instead of patched again.	/correct-by-construction an order can ship before it is paid
explain-diff	You need to understand a change, branch or PR you did not write. It writes a page with a walkthrough, what could break and a quiz. Based on Geoffrey Litt's explain-diff gist.	/explain-diff HEAD~3..HEAD
facts-as-data	The same list of names (file types, commands, error codes) is copied in several places in your code, and adding one means finding every copy.	/facts-as-data sweep src/rules
pizza1	An agent defends a choice with "it's what the codebase does" or "smallest fix", and you want the correct answer instead.	/pizza1 why keep status as a string?
readonly	You want an answer about your code, backed by evidence, without the agent changing anything.	why does login retry twice? /readonly
test-hygiene	You are writing or reviewing tests and want each one to fail when its rule breaks, with no test repeating another.	/test-hygiene review the tests in this diff
zen-of-checkpickerupper	You are choosing between two designs that both seem fine.	/zen-of-checkpickerupper store the total or compute it?

Productivity

General workflow tools.

Skill	Use it when	Example
audit-issues	Your GitHub repository has so many open issues that you cannot tell which are duplicates, already done, or still need work.	/audit-issues OWNER/REPO
close-issues	An agent is about to close a GitHub issue. It refuses until every sub-issue and checklist item is done, and writes the proof into the issue.	/close-issues #142 is finished
compose-goal	You are handing a task to another agent and want it to get the outcome, the issue links and how to prove it works.	/compose-goal hand #142 to another agent
cut-extraneous-load	Your agent's replies are pretentious and long-winded, and you want only what you need to know. Especially useful at the end of a long day, when your brain hurts.	/cut-extraneous-load say that again without the filler
dependency-trace	Before building a feature, to work out what has to exist first and in what order.	/dependency-trace what does checkout depend on?
issues-to-outcomes	You are writing a status update or end-of-day summary and want it to say what changed for the reader, not list issue titles.	/issues-to-outcomes what landed this week
make-diagram	You need a diagram (flowchart, system map, pipeline) that someone new can read.	/make-diagram how a payment goes from cart to receipt
settle-blockers	An issue is marked as blocked by another issue and you want to know whether it really has to wait.	/settle-blockers OWNER/REPO#88
to-issues-clearly	You are turning a plan, bug report or audit into GitHub issues and want titles you can understand without opening them.	/to-issues-clearly turn this plan into issues

Misc

Tools kept around but rarely used. None yet.

Local Development

./scripts/list-skills.sh
./scripts/list-skills.sh --client codex
./scripts/link-skills.sh --client claude
./scripts/link-skills.sh --client codex
./scripts/link-skills.sh --client gemini
./scripts/link-skills.sh --client pi
./scripts/link-skills-all.sh
# Replace stale real copies with links to this repo, keeping recoverable backups.
./scripts/link-skills-all.sh --replace-existing

Client targeting

Skills are universal by default. Add an explicit allow-list only when a skill depends on one client's tools or runtime:

name: codex-only-workflow
description: Run a workflow that requires Codex-only capabilities.
clients: [codex]

The registered client names are claude, codex, gemini, antigravity, antigravity-cli, and pi. Use a list when a skill supports more than one client, for example clients: [claude, codex]. An omitted clients field means every registered client. The registry lives in scripts/agent-targets.json, so adding a client does not require changing the metadata parser or linker. The linker validates unknown names and removes an old symlink from a client when a skill no longer targets it. Skill instructions remain one shared body; only discovery and delivery are client-specific.

The default destinations are ~/.claude/skills, ~/.agents/skills, ~/.gemini/skills, ~/.gemini/config/skills, ~/.gemini/antigravity-cli/skills, and ~/.pi/agent/skills. Set the destination environment variable named for the client in scripts/agent-targets.json when a client uses a different destination.

The clients field is enforced by this repository's list and link scripts. Other installers must apply the same filter before adding a skill to their catalog; metadata alone cannot stop a client that ignores it from loading the file. Keep every published skill in the README catalogs, but add a client-targeted skill to .claude-plugin/plugin.json only when it targets Claude or is universal.

Publishing

Every push to main releases, so a push to main needs the maintainer's explicit go-ahead for that change; an agent asks before each push and never pushes on its own judgment. With that go-ahead, publish skills, catalog entries, and plugin registrations directly to main from a task worktree after validation. Routine releases do not use GitHub issues or pull requests. If GitHub rejects a direct push, report the exact restriction instead of routing the change through an issue or pull request.

Every pushed change to a published skill, catalog entry, or plugin registration carries a changeset: run npx changeset, choose the bump (major for a removed or renamed skill or a breaking contract, minor for a new skill, patch for a fix or wording change), and describe what changed for someone who uses the skill. Commit the generated .changeset/*.md with the change.

Write one changeset per change, in the shape of the existing entries in CHANGELOG.md:

• Open with one sentence naming what changed, with the skill in bold code, such as "Ship pizza1 in the Engineering bucket, so it installs with npx skills and loads from the Claude Code plugin."
• Follow with a paragraph that names the skill, marks it (user-invoked) or (model-invoked), and says what it now does for its user.
• Add bullets only for distinct behavior changes, and an upgrade step only when users must act.

Releases

Every push to main that leaves pending changesets is released by the Release workflow. It consumes the changesets into CHANGELOG.md, bumps the version in package.json and .claude-plugin/plugin.json, commits chore: version skills vX.Y.Z to main, and publishes the GitHub Release vX.Y.Z with notes written by scripts/release_notes.py: a plain summary (each new skill with when to use it, from its catalog row, then retired and improved skills), followed by that version's changelog under Nitty-gritty. A push with no pending changesets, including the workflow's own version commit, releases nothing. Pull main after a release. npm run release starts the same workflow by hand.