Agent Skills

abicheck publishes three Agent Skills — portable, triggerable packages of native-compatibility expertise that a coding agent (Claude Code, GitHub Copilot, OpenAI Codex, Cursor, Gemini CLI) loads when a user asks a compatibility question in their own words.

The skills are named after the user's job, not after abicheck commands. Someone who has never heard of abicheck can ask "will this change break existing consumers?" and get a workflow that reaches for abicheck as its deterministic verification engine.

Requires abicheck 0.6.0 or later, below 0.8.0, to run. The skills check the installed abicheck version against their own declared range — >=0.6.0,<0.8.0 — and refuse to run rather than fail partway through, since several commands/options they drive postdate 0.5.0 (see "Prerequisites" below). The check runs abicheck --version — the executable actually on PATH when the skill runs, not a source checkout's pyproject.toml (the two can differ, e.g. a 0.7.x checkout with a separately installed 0.5.0 package). If that version isn't inside the range, the installed skill will decline to execute.

Status (2026-09-29): preview, installable with npx skills add abicheck/abicheck. A second evaluation pilot compared agents with and without the skill. It ran 14 compatibility scenarios with one model, headless Claude Code. With the skill:

• the agent reached the right verdict in 30 of 30 runs, against 22 of 28 without it;
• it ran a real comparison in 93% of runs, against 54%;
• it made an unsupported compatibility claim in 7% of runs, against 68%.

The skill was revised against that same scenario set, so this is not yet a held-out result, and it has not been validated on other agents. The methodology and caveats are in the pilot report.

Second skill (2026-09-30): explain-abi-change, for a developer who wants to understand what changed between a program and the shared libraries it uses, whether something fails or not. It was evaluated on 10 scenarios in the same way. With the skill, the agent backed every answer with a real comparison (20 of 20 runs, against 14 of 20 without it), and had one zero-tolerance failure against eight. Without it, the agent named the right mechanism just as often, so the skill's measured value so far is evidence, not a better guess at the cause. That evidence costs about a third more per run in money and a sixth to a quarter more in time, and three scenarios built so that source and symbols cannot reveal the change did not separate the two on accuracy either. On a smaller model the picture is different: Haiku 4.5 answered correctly 85-88% of the time with the skill against 58% without it, and each correct answer cost less. See its pilot report.

Portfolio status (2026-08-20): the portfolio was reset from four published skills down to one internal candidate. No skill has measured evidence yet that it improves agent behavior over a well-documented CLI alone, so publishing three additional, unvalidated skills alongside the one flagship was scaling packaging ahead of any validated product value. native-api-evolution, native-consumer-compatibility, and native-release-compatibility — previously published at prototype status — are no longer published; their source is recoverable from git history for whenever a second skill is built. check-abi-compatibility (renamed from review-native-library-change, itself renamed from native-binary-compatibility-review) is the sole surviving skill and is an internal candidate: working, reviewed content, but not yet validated and not for external publication or citation as validated in any user-facing claim, pending G37's still-unrun behavioral evaluation. The same status is also kept in skills-src/CLAUDE.md, the skill's own source tree.

The catalogue

Skill	Status	The question it answers
check-abi-compatibility	Preview (npx skills add abicheck/abicheck)	"Will this change break existing consumers?" — review a diff, branch, commit, or PR, ending in a verdict plus a root-cause explanation. Also handles "why did this suddenly report dozens of breaks?"
explain-abi-change	Preview (same install)	"What changed in this library, and why does my program behave like this?" — starts from what the developer observed (undefined symbol, version ... not found, a crash or wrong results after an update, a plugin that stops loading, or just a library bump with different symbols), finds which library copy is really used, compares it with the one the program was built against, and names the mechanism and what to do. Also says when the change is harmless or not ABI-related.
set-up-abi-compatibility-ci	Preview (npx skills add abicheck/abicheck)	"Set up ABI compatibility checks for our library in GitHub Actions." — inspects the repository (build system, shared libraries, public headers, language, release process), picks a baseline strategy (release snapshot, merge-base build, or committed snapshot), and writes a pinned, least-privilege workflow with a staged rollout and a setup report. Also repairs an existing check that never fails. Evaluation: skills-src/evaluation/agents/ci-setup/.

Installing it

npx skills add abicheck/abicheck                     # all three skills, into the current project
npx skills add abicheck/abicheck -s explain-abi-change  # just one of them
npx skills add abicheck/abicheck -g -a claude-code   # for every project, one agent
npx skills add abicheck/abicheck -l                  # list what the repository offers

This uses the skills CLI, which installs skills straight from a GitHub repository into the directory each agent reads (Claude Code, Codex, Copilot, Cursor, Gemini CLI and others) and handles list, update and remove itself. abicheck publishes the skills for it as the committed, self-contained skills/<skill-name>/ trees: generated from skills-src/, with every reference each one cites copied in, and checked against a fresh render in CI so they cannot drift.

The skill drives the abicheck CLI, so install that too: pipx install abicheck (or pip install abicheck).

From a checkout (contributors): skills-src/ is the one hand-authored source. The committed skills/ tree above is what npx skills add installs; the three agent-specific trees (.agents/skills/, .claude/skills/, .gemini/skills/) are generated build output, not committed — python scripts/install_dev_skill.py --target <codex|claude|gemini|all> writes them in place.

Each installed skill directory is fully self-contained: every reference it needs comes with it, with no symlinks and no cross-skill paths.

Skills are executable content. Anthropic's own guidance applies to these as to any others: install only from sources you trust, and read what you install. The rules these skills hold themselves to — never manufacture a green result, never widen a suppression, never mutate a project silently — ship inside every skill as references/shared/safety-invariants.md.

Enabling them for a whole repository

To make the skills available to every contributor's agent in your own library's repository — install them into the project and commit them, make the abicheck CLI available to local and cloud agents, and describe your public headers, build, and baseline in AGENTS.md — see Enabling abicheck skills in your repository.

Prerequisites

The skills drive the abicheck CLI, so they need whatever the workflow they run needs — see CLI usage for installation and evidence and build-context flags for what deeper --depth levels require. Local CLI invocation is the only execution path a skill uses, so a skill works in any agent with shell access and needs no protocol server or other setup beyond installing the skill itself. (abicheck has no MCP server; the CLI is simply the backend.)

Each skill declares, in its frontmatter, the abicheck version range it requires — the releases that actually provide the CLI surface it drives — and checks the installed version before doing anything else rather than degrading silently. The current portfolio targets 0.6.x and 0.7.x: several commands and options these workflows depend on (aggregate, project plan, output.view: [root-cause], --diagnostic-comparison, --contract) postdate the 0.5.0 release, so an older installation is refused up front instead of failing partway through a workflow.

Contributing

Edit skills-src/, never the generated trees, including the committed skills/ tree (python scripts/gen_agent_skills.py regenerates it). skills-src/CLAUDE.md is the contributor contract — the three-layer model, the shared-fragment rules, and the admission bar a second public skill would have to clear. The phased plan is G36.

python scripts/gen_agent_skills.py          # regenerate all three trees
python scripts/gen_agent_skills.py --check  # what CI gates on