Kaizen: Continuous Improvement

Apply continuous improvement mindset - suggest small iterative improvements, error-proof designs, follow established patterns, avoid over-engineering

Overview

Small improvements, continuously. Error-proof by design. Follow what works. Build only what's needed.

Core principle: Many small improvements beat one big change. Prevent errors at design time, not with fixes.

When to Use

Invoke explicitly when working on:

• Code implementation and refactoring
• Architecture and design decisions
• Process and workflow improvements
• Error handling and validation

Philosophy: Quality through incremental progress and prevention, not perfection through massive effort.

The Four Pillars

1. Continuous Improvement (Kaizen)

Small, frequent improvements compound into major gains.

Principles

Incremental over revolutionary:

• Make smallest viable change that improves quality
• One improvement at a time
• Verify each change before next
• Build momentum through small wins

Always leave code better:

• Fix small issues as you encounter them
• Refactor while you work (within scope)
• Update outdated comments
• Remove dead code when you see it

Iterative refinement:

• First version: make it work
• Second pass: make it clear
• Third pass: make it efficient
• Don't try all three at once

2. Poka-Yoke (Error Proofing)

Design systems that prevent errors at compile/design time, not runtime.

Principles

Make errors impossible:

• Type system catches mistakes
• Compiler enforces contracts
• Invalid states unrepresentable
• Errors caught early (left of production)

Design for safety:

• Fail fast and loudly
• Provide helpful error messages
• Make correct path obvious
• Make incorrect path difficult

Defense in layers:

1. Type system (compile time)
2. Validation (runtime, early)
3. Guards (preconditions)
4. Error boundaries (graceful degradation)

3. Standardized Work

Follow established patterns. Document what works. Make good practices easy to follow.

Principles

Consistency over cleverness:

• Follow existing codebase patterns
• Don't reinvent solved problems
• New pattern only if significantly better
• Team agreement on new patterns

Documentation lives with code:

• README for setup and architecture
• CLAUDE.md for AI coding conventions
• Comments for "why", not "what"
• Examples for complex patterns

Automate standards:

• Linters enforce style
• Type checks enforce contracts
• Tests verify behavior
• CI/CD enforces quality gates

4. Just-In-Time (JIT)

Build what's needed now. No more, no less. Avoid premature optimization and over-engineering.

Principles

YAGNI (You Aren't Gonna Need It):

• Implement only current requirements
• No "just in case" features
• No "we might need this later" code
• Delete speculation

Simplest thing that works:

• Start with straightforward solution
• Add complexity only when needed
• Refactor when requirements change
• Don't anticipate future needs

Optimize when measured:

• No premature optimization
• Profile before optimizing
• Measure impact of changes
• Accept "good enough" performance

When to add complexity:

• Current requirement demands it
• Pain points identified through use
• Measured performance issues
• Multiple use cases emerged