AVAXSKILLS Had Three Real Bugs. When No One Answered, We Sent the Fixes Ourselves.

Updated September 30, 2026: the title said we "fixed" the bugs; we sent fixes as pull requests, which are still open and unmerged.

On August 17, 2026, the same day KUMPLY audited its own KumplyValidatorSetManager contract against Avalanche's real reference implementation and found a bug that would have permanently blocked the L1 from activating, the same method turned up something else: three real, reproducible bugs in AVAXSKILLS itself, the community-maintained package of AI agent skills for building on Avalanche that we'd been using as one of our audit inputs.

What AVAXSKILLS is, and isn't

Worth being precise about this up front. AVAXSKILLS (Ayomisco/avaxskills, Apache-2.0) is a 66-skill index meant to teach AI coding agents how to build on Avalanche: Subnets, precompiles, wallet integration, and more. It's community-maintained, not an Ava Labs product, and nothing here should read as a knock on official Avalanche tooling. The bugs we found were in the skill package's own documentation of that tooling, not in the tooling itself.

Three bugs, filed the same day

The method was simple: instead of trusting a skill file's prose, check what it claims against the actual source it's describing. That turned up three real mismatches, all filed August 17.

Issue #2: the subnet-deployment skill documents CLI commands like platform subnet create that don't exist anywhere in ava-labs/avalanche-cli's real source. Two follow-up comments on the same issue found the identical problem repeated in two more skill files: validator-management tells an agent to run avalanche primaryNetwork addValidator, when the real command group is primary, not primaryNetwork; and custom-vm tells an agent to run avalanche subnet create/deploy, when the current CLI has no subnet command group left at all.

Issue #3: the precompiles skill's genesis example uses the key transactionAllowListConfig. The real key, confirmed against ava-labs/subnet-evm source, is txAllowListConfig. This one is quietly worse than a command that errors out: Subnet-EVM ignores genesis keys it doesn't recognize instead of rejecting them, so copy-pasting this exact block silently does nothing at all.

Issue #4: the wagmi skill states v2 is the latest version. v3 has since shipped, and the skill's own example imports useAccount, a hook wagmi's own type declarations mark @deprecated in favor of useConnection.

Weeks of silence

All three sat open with no maintainer response. Not unusual for a volunteer-maintained package, and not itself damning, just a fact.

From report to pull request

On September 11, 2026, we forked the repo to Eras256/avaxskills and opened three pull requests, each pointed at the issue it closes: PR #5 (subnet-deployment, plus the two follow-up findings), PR #6 (precompiles), and PR #7 (wagmi).

Writing the actual diff found more bugs than the original report

Re-reading the real avalanche-cli and platform-cli source line by line, this time to write a working fix rather than just flag a mismatch, surfaced more than the original issue had: subnet convert-l1 should be convert-to-l1; l1 add-balance doesn't exist, the real command is l1 increase-validator-balance; and the validator-registration example's flags were wrong too, --stakeAmount should be --weight, --startTime/--endTime should be --start-time/--staking-period. Platform CLI itself turned out to be a genuinely separate binary from avalanche-cli, one Ava Labs' own docs only started pointing to with a deprecation notice sometime between the original issue and the PR, weeks apart. We corrected that detail publicly on the issue thread before opening the PR, rather than let the two accounts quietly disagree.

Where it actually stands

As of this post, three PRs, three issues, all still open. None merged. AVAXSKILLS is maintained by one person in their spare time, and that's a completely normal reason for a few weeks of silence, not a strike against the project. We're not going to round "PR opened" up to "accepted," and we'd rather this post age into "still waiting" than into an overclaim someone can check and find wrong.

The habit underneath all of this is the same one that caught the P-Chain conversion bug in our own KumplyValidatorSetManager two days earlier: check the thing against the real, running source, not against what the documentation says about it. It found a critical bug in our own contract, and a quieter but still real one in a tool we use to help write that contract. Full audit trail: docs/audits and docs/AI-USAGE.md.