Yagni Slice

YAGNI Slice

When to use

• Building a new feature, endpoint, CLI flag, or UI flow from a concrete ask.
• A change request is vague enough that over-building is a risk.
• Reviewing your own plan and noticing frameworks, plugins, or generics "for later".

When not to use

• The user explicitly requested a reusable library, public API, or multi-tenant design.
• Migrating an established pattern already used elsewhere in the codebase.
• Hardening for a documented compliance or security requirement.

Assumptions

• Access to the repo, issue/PR text, and ability to run existing tests.
• Product intent is the written ask (issue, message, acceptance criteria) — not inferred future needs.
• Do not delete large modules, force-push, or rewrite public APIs without explicit confirmation.

Workflow

1. Quote the acceptance criteria in one short list (what "done" means).
2. Draft the thinnest implementation path that hits every criterion.
3. Cut anything not required for those criteria (extra configs, indirection, unused types).
4. Implement the slice; stop when criteria are met and tests prove it.
5. List deferred ideas in the PR/notes — do not code them.

Steps

1. Ask → checklist — Convert the request into 3–7 testable bullets. If a bullet is "support every X", challenge it down to the needed X.
2. Reuse first — Search the repo for an existing helper before inventing a new layer.
3. One path — Prefer a straight-line implementation over strategy/plugin/factory patterns unless two real call sites already exist.
4. No speculative files — Do not add empty utils/, types/future.ts, or feature flags "just in case".
5. Diff budget — If the diff grows beyond the ask, split or delete the extras before merging.
6. Name deferrals — In the PR body, note follow-ups explicitly so they are not smuggled into this change.

Success criteria

• Every acceptance bullet is met by the change.
• No unused abstractions, dead config keys, or unreachable code paths were introduced for hypothetical needs.
• Diff is explainable as one concern in a short summary.
• Deferred work is written down, not partially implemented.
• Destructive or breaking cleanup was confirmed or avoided.

Out of scope

• Large-scale architecture redesigns requested as the primary goal.
• Dependency policy (use a dedicated no-new-deps style skill).
• Incident response where speed overrides elegance (use incident-hotfix).