Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/mickeyyaya/evolve-loopnpx agentmods add skills/mickeyyaya/evolve-loop/engineering-craftWrote 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/mickeyyaya/evolve-loop/engineering-craft)<a href="https://agentmods.dev/skills/mickeyyaya/evolve-loop/engineering-craft"><img src="https://agentmods.dev/badge/skills/mickeyyaya/evolve-loop/engineering-craft/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/mickeyyaya/evolve-loop/engineering-craft"><img src="https://agentmods.dev/badge/skills/mickeyyaya/evolve-loop/engineering-craft.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00040 | $0.01445 |
| Opus 5.5 | $0.00016 | $0.00578 |
| Sonnet 5.5 | $0.00008 | $0.00289 |
| Haiku 4.5 | $0.00004 | $0.00145 |
Grade A, and why
engineering-craft 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 23d 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 — 69 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Engineering Craft — how code gets written here
The craft companion to
fable(which governs how you operate; this governs the code you produce). Content is distilled from 2025-26 measured evidence — mutation-testing studies, million-commit analyses of AI-written code, and benchmarked skill collections — not textbook restatement. Sources: knowledge-base/research/coding-craft-2026/.
Iron Laws (RIGID — no exceptions, no negotiation)
- No production code without a failing test first. Watch it fail, for the RIGHT reason (assertion failure on the missing behavior — not a compile error, not a typo). If code came first anyway: delete it, write the test, start over. Yes, really.
- Completion = machine evidence. Every task ends with a runnable check (test run, build, diff) whose real output you show. "Should work" is not a state of code.
- Search before you write. Before adding any function/type/helper: search for the existing one. Duplication is the measured #1 AI-code pathology (+81% duplicated blocks since 2023). Extending beats re-creating; consolidating beats both.
- Never weaken a test to make it pass. Tests encode intent. If a test is wrong, fix it in a commit that says so; if it's right, fix the code. Deleting/skipping/loosening assertions to go green is falsifying evidence.
- The diff you ship is the smallest correct one. No drive-by refactors, no unrequested "improvements", no formatting churn outside touched lines. File separate work separately.
- Mock only network/clock/subprocess — never your own logic.
Rationalization table (RIGID — if you think it, stop)
| The thought | The reality |
|---|---|
| "This is too simple to need a test" | Simple code breaks too; the test costs 2 minutes and is the only proof you ran it. |
| "I'll add tests after it works" | After-tests pass by construction and verify nothing. Red-first or start over. |
| "A mock is easier here" | Agents over-mock measurably (mocks in 36% of agent commits touching tests vs 26% of non-agent commits). Mock only process boundaries (network, clock, subprocess) — never your own logic. |
| "I'll extract an interface for testability" | Interfaces-for-mocking is inverted design. Consumer-side interfaces, only when ≥2 real implementations exist. (Different threshold from rule-of-three, which governs code duplication.) |
| "While I'm here, I'll clean this up" | Scope creep buries the actual change in review noise. Note it, file it, move on. |
| "Coverage is high, tests are good" | 85% coverage can hide a 57% mutation kill rate. Ask: would this test FAIL if the logic inverted? |
| "This helper probably doesn't exist yet" | Search first (Iron Law 3). The codebase is bigger than your context. |
| "The linter/reviewer is wrong, I'll ignore it" | Decline visibly with a reason, or comply. Silent disagreement re-litigates forever. |
What ships with it
3 files 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.
- 23d ago Changed f77262dbf50d
- 1mo ago First seen · 69 lines · 40 tokens per session scan A a4224cd3c768
engineering-craft is a skill published in the GitHub repository mickeyyaya/evolve-loop (6 stars, last pushed today), licensed Apache-2.0. It adds 40 tokens to every session and 1,445 once invoked, about $0.0002 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-09-03.
Other skills, from other repositories
plan
Analyzes architecture, selects patterns, assesses testability, then decomposes work into ordered TDD tasks with exact verification commands and explicit acceptance mapping. Works from an approved spec (zuvo:brainstorm output) or directly from a user-provided description.
unbiased-review
Use when reviewing a spec, plan, or implementation produced by another session - verifies its claims against the actual repo, grades TDD and hexagonal discipline, and reports severity-ranked findings without writing the fix. Triggers on "review this spec/plan/implementation", "second opinion on", "check this design"…
brooks-sweep
Full-sweep mode: runs a unified analysis across all quality dimensions — code decay, architecture, tech debt, and test quality — then applies fixes directly to the codebase. Safe changes are auto-applied; risky changes are confirmed before execution. Drawing on twelve classic engineering books. Triggers when: user…
brooks-test
Test quality review drawing on twelve classic engineering books — with primary focus on xUnit Test Patterns, The Art of Unit Testing, How Google Tests Software, and Working Effectively with Legacy Code — that diagnoses structural problems in an existing test suite: brittleness, mock abuse, coverage illusions, slow…
software-code-refactoring
Improve production code quality while preserving all existing test behavior. Commonly used for the Refactor phase of TDD red-green-refactor, but applicable to any codebase with tests. Use when production code works but needs cleanup — reducing duplication, improving naming, simplifying complexity, aligning with…
testing-principles
Language-agnostic testing principles for choosing which tests a change needs, test quality, and proof ownership, with frontend and browser E2E implementation references. Use when writing tests, deciding test scope, or reviewing test quality.