home / skills / yanko-belov / code-craft / kiss

kiss skill

/skills/kiss

This skill helps you replace overengineered solutions with simple, clear code that works and ships faster.

npx playbooks add skill yanko-belov/code-craft --skill kiss

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.9 KB
---
name: keep-it-simple
description: Use when tempted to write clever code. Use when solution feels complex. Use when showing off skills instead of solving problems.
---

# KISS (Keep It Simple, Stupid)

## Overview

**The simplest solution that works is the best solution.**

Clever code impresses no one. Simple code ships faster, breaks less, and others can maintain it.

## When to Use

- Solution feels complex
- Writing "elegant" or "clever" code
- Multiple approaches exist
- Tempted to show off skills
- Using advanced patterns for simple problems

## The Iron Rule

```
NEVER choose clever over clear. Simple wins.
```

**No exceptions:**
- Not for "it's more elegant"
- Not for "it shows advanced skills"
- Not for "it's technically better"
- Not for "it's a nice one-liner"

## Detection: The "Clever" Smell

If you're proud of how clever your code is, simplify it:

```typescript
// ❌ VIOLATION: Clever one-liner
const isPalindrome = (s: string): boolean =>
  (s = s.toLowerCase().replace(/[^a-z0-9]/g, '')) === [...s].reverse().join('');

// ✅ CORRECT: Simple and clear
function isPalindrome(str: string): boolean {
  const cleaned = str.toLowerCase().replace(/[^a-z0-9]/g, '');
  
  for (let i = 0; i < cleaned.length / 2; i++) {
    if (cleaned[i] !== cleaned[cleaned.length - 1 - i]) {
      return false;
    }
  }
  
  return true;
}
```

## The Cost of Complexity

| Complex Code | Impact |
|--------------|--------|
| Clever one-liners | Unreadable, hard to debug |
| Nested ternaries | Logic becomes opaque |
| Over-abstraction | Indirection hides intent |
| Premature optimization | Complexity without measured benefit |
| Design pattern overuse | Patterns for patterns' sake |

## Correct Pattern: Obvious Code

Write code that a junior developer can understand in 30 seconds:

```typescript
// ❌ COMPLEX: "Elegant" functional chain
const result = data
  .filter(Boolean)
  .map(x => transform(x))
  .reduce((acc, x) => ({ ...acc, [x.id]: x }), {})
  .values()
  .filter(x => x.active)
  .sort((a, b) => b.date - a.date)
  .slice(0, 10);

// ✅ SIMPLE: Clear steps with names
const validItems = data.filter(Boolean);
const transformed = validItems.map(transform);
const activeItems = transformed.filter(item => item.active);
const sorted = activeItems.sort((a, b) => b.date - a.date);
const topTen = sorted.slice(0, 10);
```

## Pressure Resistance Protocol

### 1. "It's More Elegant"
**Pressure:** "This one-liner is more elegant than the verbose version"

**Response:** Elegance is clarity, not brevity. Simple code is more elegant than clever code.

**Action:** Use the clear version. Name intermediate variables.

### 2. "It Shows Advanced Skills"
**Pressure:** "I want to demonstrate I know advanced patterns"

**Response:** Senior engineers are recognized for simple solutions, not complex ones.

**Action:** Solve the problem simply. Save cleverness for where it's needed.

### 3. "It's Technically Better"
**Pressure:** "The complex version is O(n) vs O(n log n)"

**Response:** Premature optimization. Is this actually a bottleneck?

**Action:** Write simple code. Optimize only when profiling shows need.

### 4. "Let Me Show Multiple Approaches"
**Pressure:** "I'll provide two implementations to show versatility"

**Response:** One clear solution is better than multiple options.

**Action:** Pick the simplest approach. Provide only that.

## Red Flags - STOP and Reconsider

If you notice ANY of these, simplify:

- Code requires explanation comments
- Nested ternaries `? : ? :`
- Multiple chained operations (5+)
- Regex that needs decoding
- Proud of how clever it is
- "One-liner" implementations
- Junior couldn't understand in 30 seconds
- Multiple solutions "for versatility"

**All of these mean: Rewrite simply.**

## Simplification Techniques

| Complex | Simple |
|---------|--------|
| Nested ternaries | if/else statements |
| Long chains | Named intermediate variables |
| Clever regex | Multiple simple checks |
| One-liner | Multi-line with comments |
| Implicit | Explicit |
| Magic numbers | Named constants |

## Quick Reference

| Symptom | Action |
|---------|--------|
| "Elegant" one-liner | Expand to clear multi-line |
| Nested ternary | Convert to if/else |
| Complex chain | Break into named steps |
| Multiple approaches | Pick simplest one |
| Pride in cleverness | Rewrite simply |

## Common Rationalizations (All Invalid)

| Excuse | Reality |
|--------|---------|
| "It's more elegant" | Clear code is more elegant than clever code. |
| "Shows advanced skills" | Simple solutions show more skill. |
| "It's a nice one-liner" | One-liners are often unreadable. |
| "Technically better" | Premature optimization is bad. |
| "Multiple options show versatility" | One clear solution is better. |
| "It's how experts do it" | Experts write simple code. |

## The Bottom Line

**Simple beats clever. Clear beats concise. Obvious beats elegant.**

When solving a problem: find the simplest solution that works. If a junior dev can't understand it in 30 seconds, simplify it.

Overview

This skill enforces the KISS principle: prefer the simplest solution that works. It helps you avoid clever one-liners, over-abstraction, and premature optimization so code is readable, maintainable, and debuggable. Use it when complexity creeps in or when you feel tempted to show off.

How this skill works

The skill inspects code for "clever" smells: long chained operations, nested ternaries, dense regex, one-liners, and solutions that require explanation. It recommends replacing them with obvious steps: named intermediate variables, simple loops or if/else blocks, and clear constants. It also provides quick responses to common pressures that push complexity.

When to use it

  • When a solution feels complex or hard to explain
  • When you’re tempted to write a clever one-liner
  • When multiple approaches are possible and you’re choosing for style
  • When using advanced patterns for a simple problem
  • During code reviews to enforce readability standards

Best practices

  • Choose one clear implementation and avoid multiple alternatives in the same code path
  • Name intermediate values so intent is explicit
  • Prefer explicit control flow (for/if) over nested ternaries and dense chains
  • Avoid complex regex; break checks into readable steps
  • Optimize only after profiling shows a real need

Example use cases

  • Refactoring a long chained array transformation into named steps for clarity
  • Replacing a terse functional one-liner with a simple loop that a junior dev can follow
  • Pushing back in a code review when a PR includes clever but unreadable code
  • Deciding not to apply a design pattern that hides intent for a small feature
  • Converting a regex-heavy validation into explicit checks when maintainability matters

FAQ

What if performance suffers after simplifying?

Measure first. Simplify by default, then profile. Optimize only the hot spots identified by metrics, not preemptively.

Isn’t some clever code acceptable in libraries?

Only when it’s thoroughly documented, well-tested, and justified by measurable benefits. Prefer simple, well-named layers even in libraries.