Engineering skills for Claude Code, aimed at the bugs that pass code review and fail in production.
Your load test reports a p99 of 4ms. It is measuring the wrong thing, and the real number can be a hundred times worse. Two transactions each check the same invariant, each commit cleanly, and together break it, raising no error anywhere. At 85% CPU you have throughput headroom and no latency headroom at all.
Each skill covers one failure of that kind. You never pick a skill by name. Describe the problem in normal words and the right one loads itself.
npx skills add auralshin/coding-skillsOr as a Claude Code plugin:
claude plugin marketplace add auralshin/coding-skillsclaude plugin install coding-skills@coding-skillsAsk any of these the way you would ask a colleague, without naming a skill:
| What you say | What loads |
|---|---|
| "Two requests both checked the balance and both succeeded" | isolation-anomalies |
| "Our load test says p99 is 4ms but users complain" | coordinated-omission |
| "It came back up and immediately fell over again" | retry-amplification |
| "Rename a column on a live table" | expand-contract |
| "We have full coverage and still shipped a bug" | mutation-testing |
| "Page 900 of this list times out" | keyset-pagination |
To browse instead, run /find-skill, or /find-skill deep pagination is slow to jump straight to one.
| Skill | Covers |
|---|---|
| cyclomatic-complexity | Counting decision points, thresholds, refactors that actually lower the score |
| connascence | A precise taxonomy for coupling: name, meaning, position, algorithm, order, timing, value, identity |
| code-hotspots | churn x complexity from git history, change coupling, bus factor |
| module-depth | Deep vs shallow modules, information leakage, when "small classes" is wrong |
| Skill | Covers |
|---|---|
| parse-dont-validate | Encode checks in types, kill shotgun parsing, illegal states unrepresentable |
| isolation-anomalies | Write skew, lost update, why REPEATABLE READ means two different things |
| expand-contract | Zero-downtime schema and API change, with per-operation recipes |
| hyrums-law | Implicit interfaces, and deliberately randomizing unspecified behavior |
| floating-point | Catastrophic cancellation, Kahan summation, why money is never a float |
| unicode-pitfalls | Grapheme clusters, NFC and NFD, the Turkish dotless i, safe truncation |
| clocks-and-time | Monotonic vs wall clock, NTP jumps, DST arithmetic, hybrid logical clocks |
| Skill | Covers |
|---|---|
| coordinated-omission | The bug making p99 wrong by 100x, and why percentiles cannot be averaged |
| queueing-and-utilization | Little's Law, the utilization knee, why 90% CPU means 10x latency |
| tail-latency | Fan-out amplification, hedged and tied requests, deadline propagation |
| universal-scalability-law | Where adding capacity starts hurting, and fitting the curve to real data |
| retry-amplification | Retry storms, metastable failure, retry budgets, jitter, load shedding |
| cache-stampede | Stampede, penetration, avalanche, hot keys, probabilistic early expiration |
| consistent-hashing | Rings, rendezvous hashing, jump hash, hot shards |
| Skill | Covers |
|---|---|
| query-plans | Reading EXPLAIN ANALYZE, where estimate versus actual is the whole game |
| index-design | Composite column order, sargability, partial and covering indexes, UUID locality |
| mvcc-and-bloat | Why DELETE grows the table, what blocks autovacuum, HOT updates, wraparound |
| connection-pooling | Why fewer connections is faster, PgBouncer modes and what each breaks |
| keyset-pagination | OFFSET is O(n) and skips rows, plus seek pagination and safe batch processing |
| database-queues | FOR UPDATE SKIP LOCKED queues, and the transactional outbox |
| write-amplification | The RUM conjecture, LSM vs B-tree, compaction tuning |
| Skill | Covers |
|---|---|
| mutation-testing | Whether tests detect bugs at all, versus whether lines merely ran |
| metamorphic-testing | Testing without an oracle, via relations between outputs |
| algorithmic-complexity-attacks | ReDoS, hash flooding, zip bombs, billion laughs |
| dependency-confusion | Registry resolution, typosquatting, lockfiles, hash pinning |
Plus start-here, a router that loads only when a question is too broad to match one skill.
Skills use progressive disclosure, so the set is never in context all at once.
| Level | What loads | Cost |
|---|---|---|
| Always | every skill's name and description |
~2.9k tokens |
| On match | the matching body, alone | ~850 words |
| Never automatically | every other body | nothing |
Bodies stay near 850 words, well under the 5k ceiling. Descriptions carry explicit handoffs, so cache-stampede says for retry storms use retry-amplification and overlapping areas route to one skill instead of three.
Each skill follows one shape: what the thing is in plain language, how to measure or detect it, concrete thresholds and runnable code, the fixes ranked, tooling, and an honest note on when it does not apply.
Writing rules, enforced by the validator wherever a machine can check them:
- Payload first, provenance second. Open with the claim, not the citation. "One slow server sets the latency of every request that touches it" leads, and "From Dean and Barroso, 2013" follows.
- Concrete over abstract. Name the number, the failure, the command. Sentences average 13 words and none runs past 45.
- Imperative voice, per Anthropic's skill-authoring guidance, with third-person trigger descriptions.
- No em dashes, no semicolons, no counts in prose. A count goes stale the moment a skill is added.
- Comments under 10 words, carrying the why rather than the what.
python3 scripts/validate.pyChecks the manifests, frontmatter, third-person descriptions, trigger-phrase count, body budget, imperative voice, comment length, and that every skill appears in both the README and the command catalog.
mkdir -p skills/<name>---
name: <name>
description: This skill should be used when the user asks "<phrase>", "<phrase>", or is <situation>.
---The description is the only thing Claude reads before deciding to load, so write it as the situations that should pull it in, phrased the way a developer would actually say them, rather than as a topic label. Then add the skill to commands/find-skill.md and to the tables above, and run the validator.
MIT