Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/aphrody-code/bxc/m15-anti-patternnpx skills add aphrody-code/bxc --skill m15-anti-patterngit clone --depth 1 https://github.com/aphrody-code/bxcWhat 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 | $0.00101 | $0.01195 |
| Opus 5 | $0.00051 | $0.00598 |
| Sonnet 5 | $0.00020 | $0.00239 |
| Haiku 4.5 | $0.00010 | $0.00120 |
Grade A, and why
m15-anti-pattern 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 2d 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.
This is a copy
100% identical to m15-anti-pattern — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 161 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Anti-Patterns
Layer 2: Design Choices
Core Question
Is this pattern hiding a design problem?
When reviewing code:
- Is this solving the symptom or the cause?
- Is there a more idiomatic approach?
- Does this fight or flow with Rust?
Anti-Pattern → Better Pattern
| Anti-Pattern | Why Bad | Better |
|---|---|---|
.clone() everywhere |
Hides ownership issues | Proper references or ownership |
.unwrap() in production |
Runtime panics | ?, expect, or handling |
Rc when single owner |
Unnecessary overhead | Simple ownership |
unsafe for convenience |
UB risk | Find safe pattern |
OOP via Deref |
Misleading API | Composition, traits |
| Giant match arms | Unmaintainable | Extract to methods |
String everywhere |
Allocation waste | &str, Cow<str> |
Ignoring #[must_use] |
Lost errors | Handle or let _ = |
Thinking Prompt
When seeing suspicious code:
-
Is this symptom or cause?
- Clone to avoid borrow? → Ownership design issue
- Unwrap "because it won't fail"? → Unhandled case
-
What would idiomatic code look like?
- References instead of clones
- Iterators instead of index loops
- Pattern matching instead of flags
-
Does this fight Rust?
- Fighting borrow checker → restructure
- Excessive unsafe → find safe pattern
Trace Up ↑
To design understanding:
"Why does my code have so many clones?"
↑ Ask: Is the ownership model correct?
↑ Check: m09-domain (data flow design)
↑ Check: m01-ownership (reference patterns)
| Anti-Pattern | Trace To | Question |
|---|---|---|
| Clone everywhere | m01-ownership | Who should own this data? |
| Unwrap everywhere | m06-error-handling | What's the error strategy? |
| Rc everywhere | m09-domain | Is ownership clear? |
| Fighting lifetimes | m09-domain | Should data structure change? |
Trace Down ↓
To implementation (Layer 1):
"Replace clone with proper ownership"
↓ m01-ownership: Reference patterns
↓ m02-resource: Smart pointer if needed
"Replace unwrap with proper handling"
↓ m06-error-handling: ? operator
↓ m06-error-handling: expect with message
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 2d ago First seen · 161 lines · 101 tokens per session scan A bcbb49e47b76
m15-anti-pattern is a skill published in the GitHub repository aphrody-code/bxc (2 stars, last pushed 2d ago), licensed Apache-2.0. It adds 101 tokens to every session and 1,195 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to m15-anti-pattern, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
implementing-jsc-classes-rust
Creates JavaScript classes using Bun's Rust bindings generator (.classes.ts). Use when implementing new JS APIs in Rust with JSC integration, prototypes, or constructors.
rust-system-calls
Guides using bunsys for system calls and file I/O in Rust. Use when implementing file operations, opening fds, or any syscall path instead of std::fs or libc.
rust-learner
Learn Rust language features and crate updates. Use when user asks about Rust version changelog, what's new in Rust, crate updates, Cargo.toml dependencies, tokio/serde/axum features, or any Rust ecosystem questions.
rust-crate-ci
Load before editing any Rust crate in this repo (currently runners/swarm-sandbox-runner). Covers the mandatory local validation gate, common rustfmt/clippy pitfalls, and Windows-specific Rust correctness patterns that CI enforces but are hard to catch locally without a Windows toolchain.
release-process
End-to-end release runbook for playwright-rust — version bump, supply-chain refresh, per-crate CHANGELOGs, tag-prefix routing for the three workspace crates, the safer push-then-tag workflow that waits for CI before publishing, and the post-release follow-ups.
doctest-conventions
Conventions for authoring rustdoc doctests in playwright-rust — the norun annotation, module-level placement, hidden scaffolding lines, and how doctests are exercised in CI vs pre-commit.