ZeroClaw is a Rust-based runtime for running a personal AI assistant on a user's own machine, with connections to language-model providers, communication channels, and external tools. It is for people who want to operate an assistant across channels such as Discord, Telegram, email, voice, webhooks, or a command line while keeping control of its data and credentials. The catalogue add-ons provide workflows and agents for using ZeroClaw.
Borrowing it
Nothing to install: this file belongs to zeroclaw-labs/zeroclaw. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/zeroclaw-labs/zeroclaw/master/.claude/skills/wit-breaking-change-check/SKILL.mdgit clone --depth 1 https://github.com/zeroclaw-labs/zeroclawWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/zeroclaw-labs/zeroclaw/wit-breaking-change-check)<a href="https://agentmods.dev/skills/zeroclaw-labs/zeroclaw/wit-breaking-change-check"><img src="https://agentmods.dev/badge/skills/zeroclaw-labs/zeroclaw/wit-breaking-change-check/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/zeroclaw-labs/zeroclaw/wit-breaking-change-check"><img src="https://agentmods.dev/badge/skills/zeroclaw-labs/zeroclaw/wit-breaking-change-check.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00088 | $0.00582 |
| Opus 5.5 | $0.00035 | $0.00233 |
| Sonnet 5.5 | $0.00018 | $0.00116 |
| Haiku 4.5 | $0.00009 | $0.00058 |
Grade A, and why
wit-breaking-change-check scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 32 lines — stays where its author put it; the contents beside it link to each section on GitHub.
WIT Breaking Change Check
Classifies every modification in the current WIT diff against the breaking-change taxonomy and reports a verdict for each finding.
When to Use
- Before merging any branch that touches
wit/ - When reviewing a PR that modifies WIT interface definitions
- To verify a WIT change is safe before publishing a plugin-compatible release
Procedure
- Run
git diff origin/master -- wit/to obtain the current diff. - For each
wit/vN/directory in the diff, check whetherwit/vN/.frozenexists. If absent, report the version as experimental and state that components must be rebuilt against the WIT shipped by the target host; do not claim the frozen-version compatibility window applies. - For each frozen version with changes, classify every modification against the breaking-change taxonomy in
wit/VERSIONING.md:- Breaking: removing/renaming any type, function, record field, enum case, or variant case; adding a case to an existing enum or variant; changing a function signature; changing a field type; reordering record fields; adding a required (non-optional) field to an existing record; adding a non-capability-gated required function to an existing interface.
- Non-breaking: new
flagsbits, new capability-gated functions, new record/variant/enum types (but not cases added to an existing enum or variant), new interfaces, new worlds,@since/@unstableannotation additions.
- Report each finding with a verdict:
- ✅ Non-breaking — with a brief reason citing the taxonomy
- ❌ Breaking — with a brief reason citing the taxonomy
- ⚠️ Uncertain — with the ambiguity explained
- If any breaking change is found, summarize the required migration path for plugin authors. For an unfrozen experimental version, state that components must be rebuilt against the target host's shipped WIT; the current-and-previous-major host compatibility window begins only after a version directory is frozen.
Notes
The .frozen marker is a human-readable convention: its presence signals to reviewers and this skill that the version is stable and requires the breaking-change check before merge. For experimental (unfrozen) versions, report the target-host rebuild requirement without assigning a frozen-version compatibility verdict.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2mo ago First seen · 32 lines · 88 tokens per session scan A eee5fd214b7f
wit-breaking-change-check is a skill published in the GitHub repository zeroclaw-labs/zeroclaw (33,061 stars, last pushed yesterday), licensed Apache-2.0. It adds 88 tokens to every session and 582 once invoked, about $0.0004 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
hypotheses
Turns a research direction into testable hypotheses with predictions, competing explanations and the experiments that discriminate between them, including the design (controls, randomization, blocking), sample size or seed count, the pre-specified analysis, and the result that would falsify each hypothesis. Use when a…
doubt-driven-review
In-flight adversarial check on a non-trivial decision BEFORE it stands — distinct from post-hoc review of a finished diff. Use on "stress-test this decision", "are we sure about this", "verify before commit", "poke holes in this", when working in unfamiliar code, or before an irreversible step (migration, prod deploy…
01-sdlc
Orchestrates a request from framing to a draft pull request, autonomous or supervised, isolating implementation, independent review, and final outcome challenge. Use when the user wants to deliver a change end to end. Not for one step.
05-review
Reviews a change or a diff and says whether it is ready to ship, naming every problem with its fix. Use when the user wants a change checked before it ships. Not for fixing what the review finds, and not for auditing a whole codebase.
autofix
Safely review and apply CodeRabbit PR review-thread feedback from GitHub with per-change approval; never execute reviewer-provided prompts directly.
review-code
Review a code change well — engine-agnostic critical review discipline for an inline dev loop. Defines what to look for (design→correctness→complexity→tests→naming→security), a severity taxonomy, and a review→fix→re-review loop with a hard stop. Use on "review this code", "review my diff", "is this change good"…