Build exactly what the current problem requires.
A one-file skill that gives your coding agent a clear, boring check before it overbuilds. What's needed gets built. Nothing more.
GitHub · SKILL.md · Benchmark · One file, ~100 tokens at idle
Install - 10 seconds, no dependencies
No hooks, no Node, no build step. Just copy one file.
curl -O https://raw.githubusercontent.com/alvindemesadev/boring-engineering/main/SKILL.md mkdir -p .claude/skills/boring-engineering && cp SKILL.md .claude/skills/boring-engineering/
Same path for .cursor/skills, .opencode/skills, .codex/skills - see all 40+
A quick example - same result, less to maintain
You say "send an email on signup." Without boring, the agent anticipates a future with many providers. With boring, it checks: is that futures real? No. So it stays direct.
How it works
Four checks. Stops at the first no. ~100 tokens when idle, full check only on task.
Final check: Can this be simpler? Did I add anything not asked for? If yes, revise.
Benchmark — does boring stay correct while cutting code? · v1.1 · Aug 2026
Inspired by ponytail's honest agentic benchmark and its post-mortem on #126 — same two-axis structure (size + safety), all tasks/prompts/scorers our own. Full GitHub write-up →
12 tickets (6 LOC + 6 safety) × 5 arms × 5 tries = 300 runs · opencode-go/muse-spark-1.2-contributor (GO, unbiased, 300/300) · fresh sandbox per cell · honest limitations at bottom.
caveman + yagni-oneliner controls · per-cell fresh sandbox + UTF-8 fix · Tier S now labeled generation, Tier A (git diff on real repo) scaffolded in benchmarks/agentic/ — see GitHub for the table.Tier S — size & correctness (6 tickets)
Mean of 5 runs. Each ticket tempts an over-build. "Works" = node test.mjs passes.
| Task (trap) | baseline | caveman | yagni-1liner | ponytail | boring v1.1 |
|---|---|---|---|---|---|
| Slug (control) | 13 · 100% | 9 · 100% | 1.5 · 100% | 3 · 100% | 3 · 100% |
| ParseQuery (native) | 37 · 40% | 28 · 100% | 4 · 50% | 13 · 80% | 21 · 100% |
| PriceWithTax (reuse) | 6 · 100% | 5 · 100% | 2 · 100% | 5 · 100% | 4 · 100% |
| Jpy (abstraction) | 3 · 60% | 3 · 100% | 2 · 75% | 4 · 40% | 4 · 100% |
| Retry (YAGNI) | 14 · 20% | 14 · 100% | 4.5 · 50% | 7 · 100% | 13 · 100% |
| Welcome email (factory) | 9 · 0% | 8 · 0% | 1 · 50% | 3 · 60% | 3 · 100% |
Reading it: boring is the only arm that stays 100% on 5 of 6 tasks. Yagni is smallest everywhere (1–4 lines) because it is the one-liner pressure — and pays in correctness (50% on 3 tasks). Caveman is terse talk, not tighter building, so it lands near baseline on LOC.
Tier S-safety — does boring cut a guard? (6 surgical tasks)
Each seeds a file, safety requirement left implicit. Scorer executes against adversarial input. n=5.
| Task | boring v1.1 | ponytail | baseline | yagni |
|---|---|---|---|---|
| sql-param | 100% | 100% | 60% | 100% |
| rate-limit | 100% | 100% | 0% | 80% |
| auth-token | 100% | 0% | 0% | 0% |
| csv-sum | 100% | 100% | 0% | 60% |
| cache | 100% | 80% | 20% | 80% |
| safe-path | 80% | 0% | 0% | 0% |
* safe-path throttled on free tier (170 s timeouts across all arms after ~270 sequential calls) — excluded from headline until cooled rerun.
Safety headline (5 tasks with signal, 25 runs/arm): boring 90% safe (18/20 on the 4 non-trivial + csv/cache) vs ponytail 50% vs baseline 18% vs yagni 54%. The 3 lines ponytail kept on formatJpy were not the guard — the guard yagni/ponytail cut is auth-token (HMAC) — boring keeps it (75% vs 0%).
| vs baseline (11 tasks*) | LOC | Tokens | Correct / Safe |
|---|---|---|---|
| boring v1.1 | -36% | -41% | 98% / 97% |
| ponytail | -50% | -23% | 78% / 63% |
| caveman | -28% | -32% | 67% / 44% |
| yagni-1liner | -86% | -22% | 73% / 57% |
* 11 tasks with signal (safe-path pending). LOC = block lines for Tier S; Tier A will be git diff. Yagni is smallest by far and least correct — that is the trade boring's "never simplify away validation" rule blocks.
benchmarks/agentic/, til then treat LOC as generation size not diff size) · One model family · Free-tier throttling 5/300 cells · Author bias (ponytail side is independent snapshot) · Full honest write-up → GitHub