skills.rest
mintuz
mintuzCOMMUNITY
Explore all skills by this author →
WebsiteGitHub

yagni

Enforces minimal-scope code changes with TDD discipline and explicit plan boundaries.

3|Updated Nov 8, 2014
Search Tags:#tdd#code review#refactoring#yagni#scope control#testing discipline#minimal implementation
One-click install
npx skills add https://github.com/mintuz/.dotfiles --skill yagni-mintuz
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: yagni
Source: https://github.com/mintuz/.dotfiles/tree/main/agents/.agents/skills/yagni
Command: npx skills add https://github.com/mintuz/.dotfiles --skill yagni-mintuz

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It prevents overengineering during code changes by enforcing the YAGNI principle: no speculative abstractions, no scope creep, and no test sprawl beyond what the accepted requirement demands. ## Core Features & Use Cases - Scope-Bounded Planning: Requires an explicit plan stating goals, non-goals, acceptance criteria, and what stays untouched before any execution. - TDD Discipline: Mandates a failing test before every behaviour change while capping test scope to one main path and one critical failure path per behaviour. - Action Boundaries: Distinguishes reversible operations (test runs, diffs, safe git restores) from irreversible ones that require user confirmation. - Use Case: When asked to fix a bug, the agent finds every caller, fixes the shared contract once, writes one failing test first, and stops—rather than adding compatibility layers or refactoring unrelated modules. ## Quick Start Apply the yagni skill to this task and implement only the minimum change needed to satisfy the requirement.

Frequently Asked Questions about yagni

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How should I apply TDD without creating test sprawl?▼

Write one failing test per behaviour change, covering one main path and at most one critical failure path. Do not backfill unrelated modules, add parametrized grids, or introduce new test frameworks the requirement did not ask for.

When should I ask the user before changing code?▼

Ask when the requirement is ambiguous or a material choice is open, and always before irreversible operations like losing uncommitted work. Reversible actions such as test runs, diffs, and safe git restores need no confirmation.

What is the difference between YAGNI and removing existing complexity?▼

YAGNI keeps unnecessary mechanism out of new work, while removing mechanism from existing working code belongs to a separate reducer-style workflow. A pure removal task adds no behaviour, keeps tests as regression checks, and adds no new tests for the removal itself.

Why does my bug fix keep growing in scope?▼

Scope grows when you patch each caller instead of fixing the shared contract once, or when you add compatibility layers and dual implementations. Find every caller first, put the fix where the accepted contract lives, and stop when the failing test passes.

Related Skills

Explore More Software Engineering Skills→
JKhyroJKhyro

systematic-debugging

Trace root causes of software bugs before proposing fixes.

Community
Advanced
ryonakaeryonakae
11

update-docs

Update README and docs markdown files after code changes using git diff.

Community
Intermediate
testdoubletestdouble
198

refactor

Refactor code iteratively with test-gated validation after each step.

Official
Advanced
kapilvirenahujakapilvirenahuja
3

garura:refactor

Produce behavior-preserving refactor commit sequences with green test gates.

Community
Advanced