Coding

code-quality-principles

Try it

Applies KISS, YAGNI, and SOLID principles for clean code with reduced complexity

What it does

**Night Market Skill** — ported from claude-night-market/conserve. For the full experience with agents, hooks, and commands, install the Claude Code plugin.

The skill document

Night Market Skill — ported from claude-night-market/conserve. For the full experience with agents, hooks, and commands, install the Claude Code plugin.

Code Quality Principles

Guidance on KISS, YAGNI, and SOLID principles with language-specific examples.

When To Use

  • Improving code readability and maintainability
  • Applying SOLID, KISS, YAGNI principles during refactoring

When NOT To Use

  • Throwaway scripts or one-time data migrations
  • Performance-critical code where readability trades are justified

KISS (Keep It Simple, Stupid)

Principle: Avoid unnecessary complexity. Prefer obvious solutions over clever ones.

Guidelines

PreferAvoid
Simple conditionalsComplex regex for simple checks
Explicit codeMagic numbers/strings
Standard patternsClever shortcuts
Direct solutionsOver-abstracted layers

Python Example

# Bad: Overly clever one-liner
users = [u for u in (db.get(id) for id in ids) if u and u.active and not u.banned]

# Good: Clear and readable
users = []
for user_id in ids:
    user = db.get(user_id)
    if user and user.active and not user.banned:
        users.append(user)

Rust Example

// Bad: Unnecessary complexity
fn process(data: &[u8]) -> Result, Box> {
    data.iter()
        .map(|&b| b.checked_add(1).ok_or("overflow"))
        .collect::, _>>()
        .map_err(|e| e.into())
}

// Good: Simple and clear
fn process(data: &[u8]) -> Result, &'static str> {
    let mut result = Vec::with_capacity(data.len());
    for &byte in data {
        result.push(byte.checked_add(1).ok_or("overflow")?);
    }
    Ok(result)
}

YAGNI (You Aren't Gonna Need It)

Principle: Don't implement features until they are actually needed.

Guidelines

DoDon't
Solve current problemBuild for hypothetical futures
Add when 3rd use case appearsCreate abstractions for 1 use case
Delete dead codeKeep "just in case" code
Minimal viable solutionPremature optimization

Python Example

# Bad: Premature abstraction for one use case
class AbstractDataProcessor:
    def process(self, data): ...
    def validate(self, data): ...
    def transform(self, data): ...

class CSVProcessor(AbstractDataProcessor):
    def process(self, data):
        return self.transform(self.validate(data))

# Good: Simple function until more cases appear
def process_csv(data: list[str]) -> list[dict]:
    return [parse_row(row) for row in data if row.strip()]

TypeScript Example

// Bad: Over-engineered config system
interface ConfigProvider {
  get(key: K): T[K];
  set(key: K, value: T[K]): void;
  watch(key: K, callback: (v: T[K]) => void): void;
}

// Good: Simple config for current needs
const config = {
  apiUrl: process.env.API_URL || 'http://localhost:3000',
  timeout: 5000,
};

SOLID Principles

Single Responsibility Principle

Each module/class should have one reason to change.

# Bad: Multiple responsibilities
class UserManager:
    def create_user(self, data): ...
    def send_welcome_email(self, user): ...  # Email responsibility
    def generate_report(self, users): ...     # Reporting responsibility

# Good: Separated responsibilities
class UserRepository:
    def create(self, data): ...

class EmailService:
    def send_welcome(self, user): ...

class UserReportGenerator:
    def generate(self, users): ...

Open/Closed Principle

Open for extension, closed for modification.

# Bad: Requires modification for new types
def calculate_area(shape):
    if shape.type == "circle":
        return 3.14 * shape.radius ** 2
    elif shape.type == "rectangle":
        return shape.width * shape.height
    # Must modify to add new shapes

# Good: Extensible without modification
from abc import ABC, abstractmethod

class Shape(ABC):
    @abstractmethod
    def area(self) -> float: ...

class Circle(Shape):
    def __init__(self, radius: float):
        self.radius = radius
    def area(self) -> float:
        return 3.14 * self.radius ** 2

Liskov Substitution Principle

Subtypes must be substitutable for their base types.

# Bad: Violates LSP - Square changes Rectangle behavior
class Rectangle:
    def set_width(self, w): self.width = w
    def set_height(self, h): self.height = h

class Square(Rectangle):  # Breaks when used as Rectangle
    def set_width(self, w):
        self.width = self.height = w  # Unexpected side effect

# Good: Separate types with common interface
class Shape(ABC):
    @abstractmethod
    def area(self) -> float: ...

class Rectangle(Shape):
    def __init__(self, width: float, height: float): ...

class Square(Shape):
    def __init__(self, side: float): ...

Interface Segregation Principle

Clients shouldn't depend on interfaces they don't use.

// Bad: Fat interface
interface Worker {
  work(): void;
  eat(): void;
  sleep(): void;
}

// Good: Segregated interfaces
interface Workable {
  work(): void;
}

interface Feedable {
  eat(): void;
}

// Clients only implement what they need
class Robot implements Workable {
  work(): void { /* ... */ }
}

Dependency Inversion Principle

Depend on abstractions, not concretions.

# Bad: Direct dependency on concrete class
class OrderService:
    def __init__(self):
        self.db = PostgresDatabase()  # Tight coupling

# Good: Depend on abstraction
from abc import ABC, abstractmethod

class Database(ABC):
    @abstractmethod
    def save(self, data): ...

class OrderService:
    def __init__(self, db: Database):
        self.db = db  # Injected abstraction

Quick Reference

PrincipleQuestion to AskRed Flag
KISS"Is there a simpler way?"Complex solution for simple problem
YAGNI"Do I need this right now?"Building for hypothetical use cases
SRP"What's the one reason to change?"Class doing multiple jobs
OCP"Can I extend without modifying?"Switch statements for types
LSP"Can subtypes replace base types?"Overridden methods with side effects
ISP"Does client need all methods?"Empty method implementations
DIP"Am I depending on abstractions?"new keyword in business logic

When Principles Conflict

  1. KISS vs SOLID: For small projects, KISS wins. Add SOLID patterns as complexity grows.
  2. YAGNI vs DIP: Don't add abstractions until you have 2+ implementations.
  3. Readability vs DRY: Prefer slight duplication over wrong abstraction.

Integration with Code Review

When reviewing code, check:

  • No unnecessary complexity (KISS)
  • No speculative features (YAGNI)
  • Each class has single responsibility (SRP)
  • No god classes (> 500 lines)
  • Dependencies are injected, not created (DIP)

Verification: Run wc -l to check line counts and rg -c "class " (or grep -c "class " ) to count classes per file.

  • imbue:karpathy-principles - The "Simplicity First" principle wraps KISS, YAGNI, and SOLID into a four-principle synthesis derived from Karpathy's observations on LLM coding pitfalls
  • See docs/quality-gates.md#skill-level-quality-gate-composition for the full gate-skill federation graph

Related skills

Find why your productivity system keeps failing, then apply the smallest fix — capacity math, bottleneck routing, durable local notes.

by Iván855 installs69 stars

Stores durable facts in a categorized, plain-markdown vault on disk, alongside your agent's built-in memory.

by Iván559 installs18 stars

Generate and edit Draw.io, Mermaid, and Excalidraw diagrams from natural language using a structured JSON spec.

by nssa.io1.0k installs47 stars

Join a video meeting as an AI bot with voice, avatar, and screenshare across four operating modes.

by johnpatternai22 installs8 stars

Run Git operations — commits, branches, merges, rebases, conflict resolution, and recovery — with safety rules enforced.

by Iván535 installs31 stars

More from athola

Browse all skills

Evaluate hook security, performance, and SDK compliance. Use for audits

by athola26 installs

Configures pre-commit hooks for linting, type checking, formatting, and testing

by athola25 installs

Executes implementation plans with progress tracking, checkpoint validation, and quality gates. Use after planning is complete and tasks are ready to implement

by athola25 installs

Guide creating Claude Code hooks with security-first design. Use for validation and enforcement

by athola24 installs

Analyze and improve the improvement process. Use for detecting regressions and meta-optimization

by athola24 installs