Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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/skillsInstall everything without prompts:
npx skills@latest add CheckPickerUpper/skills --allUse one skill without installing:
npx skills@latest use CheckPickerUpper/skills@pizza1Reference
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-existingClient 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.