How do I install the Yagni skill?

Run npx skillmds@latest add oleg494/yagni in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Yagni safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Yagni?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Yagni free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under MIT.

oleg494 (@oleg494) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Yagni by oleg494 — Agent Skill

Name: Yagni
Author: oleg494

Yagni

Always-on. Law of minimalism: don't build what wasn't asked for. Abstraction must pay rent via present value or a genuine change-isolation boundary; hypothetical reuse → inline. New dependency → only if the pain is measurable. Dead code → delete. "For the future" → not a reason. Use for ANY code change.

oleg494 d7267d9 2 files · 3.5 KB Updated Sep 17, 2026

File contents

YAGNI — law of minimalism

Always-on skill. Apply before every code change.

Minimize implementation weight, not the requested outcome. Required formats, callers, compatibility, errors and quality are present needs. Do not ship a reduced MVP or demand a second request for the rest of the original scope.

Rules

Abstraction must justify its complexity by present value. A single-consumer abstraction that exists only for hypothetical reuse is debt: inline until a second need or a genuine change-isolation boundary emerges. Can you remove a layer — same behavior, less code? → remove it.
New dependency → only if the pain is measurable. 30 lines of your own code beat 300KB of someone else's. Start with stdlib/native. moment.js for a single format = no.
Code that can be removed without changing behavior → remove it. Dead code is not commented out forever.
"For the future" is not a sufficient reason. Build for the current task, not a hypothetical one.
Stop when the next abstraction doesn't pay rent this week. An abstraction must pay off now, not "someday".

Filter before every change

DRY — share genuinely identical knowledge when a single source reduces change risk; similar-looking code alone is not evidence of a shared abstraction.
KISS — does the simpler option close the task? → take the simple one. Complexity is justified only when the simple one doesn't cut it.
YAGNI — is this needed NOW? → no → don't do it.

Antipatterns

Generic EventBus with a middleware pipeline for a single notification → just call the function.
Abstract factory for two similar components → two direct components.
Config-driven form builder for three forms → three form components.
"Might come in handy" → it won't.

Code review through a YAGNI lens

Can this abstraction be removed without changing behavior? → remove it.
Is this dependency actually needed? → check whether stdlib solves it.
Is this code used? → no → remove it.
Is this "for the future"? → remove it.

Quote

"Three similar lines of code is better than a premature abstraction. Implement the naive, obviously-correct version first. Optimize only after correctness is proven with tests."

---name: yagnidescription: Always-on. Law of minimalism: don't build what wasn't asked for. Abstraction must pay rent via present value or a genuine change-isolation boundary; hypothetical reuse → inline. New dependency → only if the pain is measurable. Dead code → delete. "For the future" → not a reason. Use for ANY code change.license: MIT---# YAGNI — law of minimalismAlways-on skill. Apply before every code change.Minimize implementation weight, not the requested outcome. Required formats,callers, compatibility, errors and quality are present needs. Do not ship areduced MVP or demand a second request for the rest of the original scope.## Rules1. **Abstraction must justify its complexity by present value.** A single-consumer abstraction that exists only for hypothetical reuse is debt: inline until a second need or a genuine change-isolation boundary emerges. Can you remove a layer — same behavior, less code? → remove it.2. **New dependency → only if the pain is measurable.** 30 lines of your own code beat 300KB of someone else's. Start with stdlib/native. moment.js for a single format = no.3. **Code that can be removed without changing behavior → remove it.** Dead code is not commented out forever.4. **"For the future" is not a sufficient reason.** Build for the current task, not a hypothetical one.5. **Stop when the next abstraction doesn't pay rent this week.** An abstraction must pay off now, not "someday".## Filter before every change- **DRY** — share genuinely identical knowledge when a single source reduces change risk; similar-looking code alone is not evidence of a shared abstraction.- **KISS** — does the simpler option close the task? → take the simple one. Complexity is justified only when the simple one doesn't cut it.- **YAGNI** — is this needed NOW? → no → don't do it.## Antipatterns- Generic EventBus with a middleware pipeline for a single notification → just call the function.- Abstract factory for two similar components → two direct components.- Config-driven form builder for three forms → three form components.- "Might come in handy" → it won't.## Code review through a YAGNI lens- Can this abstraction be removed without changing behavior? → remove it.- Is this dependency actually needed? → check whether stdlib solves it.- Is this code used? → no → remove it.- Is this "for the future"? → remove it.## Quote"Three similar lines of code is better than a premature abstraction. Implement the naive, obviously-correct version first. Optimize only after correctness is proven with tests."

Frequently asked questions