kotlin-footguns

By maxrave-dev — creator and maintainer of SimpMusic, the 10.8k-star cross-platform music app every lesson in this repository was mined from.

224 battle-tested traps mapping the footguns of Kotlin, Compose Multiplatform and desktop JVM development, packaged as nine agent skills plus a scanner that checks a change against them. Mined from a production codebase, not written from documentation.

The traps are grouped into nine area skills in the open agent-skills format, readable by Claude Code and any coding agent that understands the format — and just as readable by a human. Each area skill is an index of its traps; each trap is a standalone markdown file the agent opens when the work in front of it matches. The corpus is 27,000+ lines across 224 files, and in most of them the largest section is Traps: the specific ways a technique fails in practice, each paired with a way to verify the failure and the fix on your own tree.

Why this repository exists

Most agent-skill collections for Kotlin and Android are written from official documentation. They tell an agent what the API is supposed to do. This repository records what happened when its author shipped against those APIs for years: the API that reports success while discarding your data, the build flag that means something different on one platform, the verification step that passes on broken code, the migration that deleted the wrong thing first.

None of it is theory. Every lesson here is older than the document that describes it — each one had already been paid for in crash reports, failed releases, review rounds and user-filed issues before it was written down.

Where the lessons come from

The source is SimpMusic, a cross-platform music client built with Kotlin and Compose Multiplatform, in continuous production since April 2023. As of this writing it has earned more than 10,800 GitHub stars and 550 forks, and ships to real users on Android, Windows, macOS and Linux through GitHub releases, F-Droid, IzzyOnDroid and OpenAPK.

That codebase spans territory most sample projects never touch: a native media engine bound over JNA, dual-player crossfade and DSP chains, a Room database at real-user scale, desktop packaging and code-signing for three operating systems, CI that builds all of it, and a UI written entirely in Compose. The traps are the distillation of that surface area.

The corpus itself is deliberately service-neutral. The traps teach architecture and failure modes, never the mechanics of any third-party service; no service names or vendor field names appear in any trap file. What was learned integrating specific services survives here as the generic core that applies to whichever API you are consuming.

What is inside

Each area skill lists its traps under headings, each with the description that tells an agent when to open it. The whole index on one page is CATALOG.md. A tenth skill, footgun-scan, checks code against the traps (below).

Why nine skills and not 224

Until version 2.0 every trap was its own skill, and the set crowded out everything else in the agent's skill listing. Claude Code lists every installed skill's name and description on every turn, inside a budget of 1% of the context window (8,000 characters for a 200K-token window), and lists whatever does not fit by name alone, least-used first. The 224 descriptions came to about 124,000 characters and the names alone to 7,500, so at that budget every trap reached the agent as a bare name, and so did every other skill the user had installed, their own included.

As nine area skills plus the scanner the listing is about 2,700 characters. The agent loads an area's index when the work touches that area, sees every trap in it at once with the symptom that should send it to each one, and opens only the files that apply.

Scanning a change

footgun-scan turns the traps into a check. It matches 32 patterns against the lines a change adds; each pattern is tied to one trap, and the agent opens that trap to confirm or dismiss every hit. Ask for it in plain words ("check my uncommitted Kotlin changes for footguns"), or run the script yourself, for example as a CI step:

python3 .claude/skills/footgun-scan/scripts/scan.py --base origin/main --fail

A hit is likely when the shape is wrong unless the exception its trap names holds, and look when it marks a place the trap says to inspect. Over the whole of SimpMusic and its core module the scanner raised 26 likely hits, and all 26 matched their trap on inspection: 22 vertical slides left at their half-height default, two fades from Color.Transparent into a colour, and two values spliced into migration SQL. The look hits are places to read, not verdicts.

Does it help?

evals/ holds thirteen claude plugin eval cases, each run with the plugin and without it. With it, all twelve trap questions passed in every run and the agent opened the right trap file every time. Without it they averaged 0.56. On five of them the model already knew the lesson. On four it was confidently wrong: it described a Room connection-routing rule and a resource formatter that do not exist. The full table and its caveats are in evals/README.md.

Anatomy of a trap

Every trap file follows the same discipline:

• Frontmatter — a name matching its file name and a description that states coverage, the trigger for reaching for it, and the symptom it explains. The area index repeats that description, so the agent chooses on exactly this text.
• A short orientation — the working pattern, with code where code is clearer than prose.
• Traps — the dominant section: concrete failure modes, why each happens mechanically, and what to do instead.
• Verifying it — commands to run against your own codebase to confirm or rule out each claim. Quantities are expressed as commands you run rather than numbers that go stale.

Files are kept between 60 and 140 lines. A trap you cannot read in two minutes is a trap an agent will not load in context.

The area indexes and CATALOG.md are generated: after adding or editing a trap, run python3 scripts/build_index.py. It refreshes every index line from the trap's own description, fails if a file is unlisted, listed twice or missing, or if a cross-reference names a trap that does not exist, and reports how much of the listing budget the skills take. Add --check to verify without writing.

How the corpus was verified

Extraction ran as a five-batch pipeline, and no file shipped as first drafted. Each batch was reviewed by independent adversarial lanes that received only the files and the source tree — never the author's reasoning — and were instructed to refute, not confirm. Findings were repaired in separate fix lanes, and a repair was accepted only with the re-run evidence attached. A follow-up delta batch, mined later from the source project's continued development, went through the same pipeline at wider fan-out: ten write lanes, ten adversarial verify lanes and seven fix lanes. A second delta batch, mined from the v2.0.0 release sprint, ran four write lanes against two adversarial verify lanes and repaired every one of the twenty-eight findings they raised — among them a published claim the reviewers refuted fro