yagni_skill

Overview

This skill enforces the YAGNI (You Ain't Gonna Need It) principle to prevent speculative features and premature complexity. It helps teams decide when to stop adding capabilities "for later" and focus on delivering the minimum that solves the current problem. Use it as a guardrail during design reviews, PRs, and planning sessions.

How this skill works

The skill inspects proposed changes, feature requests, and design notes for speculative language and unnecessary abstractions. It highlights justifications that use terms like "might", "probably", "in case", or "later" and flags added features that exceed the actual requirements. It recommends the minimal implementation path and suggests when to defer extra features until real demand or production deployment.

When to use it

• When someone proposes adding features "for future use" or "just in case"
• During code reviews to catch speculative abstractions or extra endpoints
• In planning sessions to keep MVP scope tight and focused
• When pressure arises to make prototypes production-ready prematurely
• When extra configuration, toggles, or flexibility are added without a clear need

Best practices

• Build the smallest thing that satisfies the explicit requirement
• Defer pagination, search, rate limiting, and other features until users or metrics require them
• Accept clean, maintainable code and necessary error handling, but avoid extra capabilities
• Document why a feature was deferred so future engineers know the trigger for adding it
• Treat "easy to add now" as a non-justification; prefer real user requests or measured signals

Example use cases

• A PR adds multiple endpoints and DB fields for hypothetical future filters — flag and reduce to requested endpoints
• Design doc recommends adding multi-tenant config before a second tenant exists — recommend deferring
• Product asks to make a prototype "production-ready" with full logging and tracing — advise MVP deployment first
• Developer suggests building a generic abstraction for a single-use case — suggest a simple, focused implementation
• Sprint planning where stakeholders push for numerous optional features — refocus on core acceptance criteria