# YAGNI - You Aren't Gonna Need It

## Principle

Don't build features or add complexity for hypothetical future needs.
Build only what's needed for the current requirement.

## The Checklist

For every proposed feature:
- [ ] Needed for current requirement?
- [ ] Solves a real (not hypothetical) problem?
- [ ] Can be added later without major refactoring?
- [ ] Simplest possible solution?

If any answer is NO, don't build it.

## Anti-Patterns

| Don't Do | Do Instead |
|----------|------------|
| Add "flexibility" for unknown future needs | Design for current requirements |
| Create abstractions for single implementation | Use concrete classes |
| Build for scale you don't have | Build for current load |
| Add configuration options "just in case" | Hardcode, make configurable later |
| Implement plugin system with one use case | Direct implementation |

## Examples

### Example 1: Configuration

**Don't:**
```
"Let's make this configurable so we can change it later"
```

**Do:**
```
Hardcode the value. When you need to change it 3+ times,
THEN make it configurable.
```

### Example 2: Abstraction

**Don't:**
```
"Let's create an interface in case we need another implementation"
```

**Do:**
```
Implement the concrete class. When you need a second implementation,
THEN extract the interface.
```

### Example 3: Features

**Don't:**
```
"Users might want to export to CSV, PDF, and Excel someday"
```

**Do:**
```
Implement CSV export. When users ask for PDF, THEN add it.
```

## When to Break YAGNI

Only violate YAGNI if:
- The cost of adding later is significantly higher
- You have a concrete, planned use case (not hypothetical)
- The feature is a core architectural requirement

## Credit

Adapted from obra/superpowers by Jesse Vincent (MIT License)
See: obra/superpowers `skills/brainstorming/SKILL.md` line 51
