---

name: keep-it-simple description: | Before adding abstraction, asks "do we need this now?" Activates when proposing factories, abstract classes, config-driven behavior, or "for future extensibility." Resists over-engineering. Three similar lines are better than a premature abstraction. allowed-tools: | file: read, edit

Keep It Simple

When To Activate

Instructions

The YAGNI Test

Before adding abstraction, answer honestly:

Copy## Complexity Check

**I want to add:** [describe the abstraction]

**Because:** [your justification]

**Is this solving a problem we have TODAY?**
- [ ] Yes, we have 3+ concrete cases now
- [ ] No, but we might need it later

**If "might need later":** Don't build it. Stop.

The Rule of Three

Abstract when you have three concrete cases, not before:

Copy// With 1 button: just make the button
<button class="blue">Save</button>

// With 2 buttons: copy-paste is fine
<button class="blue">Save</button>
<button class="red">Delete</button>

// With 3+ buttons: NOW consider a component
<Button color="blue">Save</Button>
<Button color="red">Delete</Button>
<Button color="gray">Cancel</Button>

Abstraction Warning Signs

Watch for these phrases in your thinking:

• "For flexibility..." → Flexibility for what? Do we need it?
• "In case we need to..." → We don't need to yet.
• "This could be configurable..." → Is anyone asking to configure it?
• "To support future..." → Future isn't asking for support.
• "For extensibility..." → Extend it when you need to.

Watch for these patterns:

• Factory that produces one type
• Config object with one option
• Abstract class with one implementation
• Utility function used once
• Parameters that are always the same value

Simplest Solutions

When Abstraction IS Right

Abstraction is warranted when:

• You have 3+ concrete, existing cases
• The pattern is stable (not still changing)
• The duplication is causing actual bugs
• You're building a library for others

Output Format

When resisting complexity:

Copy## Keeping It Simple

**Considered:** [the abstraction]
**Rejected because:** [only N cases / speculative / etc.]
**Instead:** [simpler approach]

When complexity is warranted:

Copy## Abstraction Justified

**Adding:** [the abstraction]
**Because:** [3+ cases / causing bugs / stable pattern]
**Cases:** [list the concrete cases]

NEVER

• Build factories for single types
• Create abstract classes before concrete ones
• Add config options nobody asked for
• Build "infrastructure" before the feature
• Say "for future extensibility" as justification
• Create utilities for one-time operations

ALWAYS

• Start with the simplest thing that works
• Wait for three concrete cases before abstracting
• Prefer duplication over premature abstraction
• Let patterns emerge from real usage
• Ask "do we need this TODAY?"

Example

User: "Add a way to send notification emails"

Over-engineered approach:

CopyNotificationFactory
├── EmailNotification
├── SMSNotification (might need later!)
├── PushNotification (could be useful!)
└── NotificationConfig
    ├── templates
    ├── retryPolicy
    └── queueSettings

YAGNI approach:

Copydef send_notification_email(user, subject, body):
    email_service.send(
        to=user.email,
        subject=subject,
        body=body
    )

Why simpler is better:

• User asked for email. Just do email.
• SMS and Push aren't requested. Don't build them.
• Config can be added when there's something to configure.
• If we need SMS later, we'll add it then.

The 5-line function solves the actual problem. The factory solves imaginary ones.