Use when Code implementation and refactoring, architecturing or designing systems, process and workflow improvements, error handling and validation. Provide tehniquest to avoid over-engineering and apply iterative improvements.

Kaizen: Continuous Improvement Apply continuous improvement mindset suggest small iterative improvements, error proof designs, follow established patterns, avoid over engineering; automatically applied to guide quality and simplicity 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 Always applied for: 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 <Good Each step is complete, tested, and working </Good <Bad Overwhelming, error prone, hard to verify </Bad In Practice When implementing features: 1. Start with simplest version that works 2. Add one improvement (error handling, validation, etc.) 3. Test and verify 4. Repeat if time permits 5. Don't try to make it perfect immediately When refactoring: Fix one smell at a time Commit after each improvement Keep tests passing throughout Stop when "good enough" (diminishing returns) When reviewing code: Suggest incremental improvements (not rewrites) Prioritize: critical → important → nice to have Focus on highest impact changes first Accept "better than before" even if not perfect 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) Type System Error Proofing <Good Type system prevents entire classes of errors </Good <Good Function signature guarantees safety </Good Validation Error Proofing <Good Validate once at boundary, safe everywhere else </Good Guards and Preconditions <Good Guards make assumptions explicit and enforced </Good Configuration Error Proofing <Good Fail at startup, not in production </Good In Practice When designing APIs: Use types to constrain inputs Make invalid states unrepresentable Return Result<T, E instead of throwing Document preconditions in types When handling errors: Validate at system boundaries Use guards for preconditions Fail fast with clear messages Log context for debugging When configuring: Required over optional with defaults Validate all config at startup Fail deployment if config invalid Don't allow partial configurations 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 Following Patterns <Good Consistency makes codebase predictable </Good <Bad Inconsistency creates confusion </Bad Error Handling Patterns <Good Standard pattern across codebase </Good Documentation Standards <Good Documents why, when, and how </Good In Practice Before adding new patterns: Search codebase for similar problems solved Check CLAUDE.md for project conventions Discuss with team if breaking from pattern Update docs when introducing new pattern When writing code: Match existing file structure Use same naming conventions Follow same error handling approach Import from same locations When reviewing: Check consistency with existing code Point to examples in codebase Suggest aligning with standards Update CLAUDE.md if new standard emerges 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 YAGNI in Action <Good Simple, meets current need </Good <Bad Building for imaginary future requirements </Bad When to add complexity: Current requirement demands it Pain points identified through use Measured performance issues Multiple use cases emerged <Good Complexity added only when needed </Good Premature Abstraction <Bad Massive abstraction for uncertain future </Bad <Good Abstract only when pattern proven across 3+ cases </Good Performance Optimization <Good Optimize based on measurement, not assumptions </Good <Bad Complex solution for unmeasured problem </Bad In Practice When implementing: Solve the immediate problem Use straightforward approach Resist "what if" thinking Delete speculative code When optimizing: Profile first, optimize second Measure before and after Document why optimization needed Keep simple version in tests When abstracting: Wait for 3+ similar cases (Rule of Three) Make abstraction as simple as possible Prefer duplication over wrong abstraction Refactor when pattern clear Integration with Commands The Kaizen skill guides how you work. The commands provide structured analysis: /why : Root cause analysis (5 Whys) /cause and effect : Multi factor analysis (Fishbone) /plan do check act : Iterative improvement cycles /analyse problem : Comprehensive documentation (A3) /analyse : Smart method selection (Gemba/VSM/Muda) Use commands for structured problem solving. Apply skill for day to day development. Red Flags Violating Continuous Improvement: "I'll refactor it later" (never happens) Leaving code worse than you found it Big bang rewrites instead of incremental Violating Poka Yoke: "Users should just be careful" Validation after use instead of before Optional config with no validation Violating Standardized Work: "I prefer to do it my way" Not checking existing patterns Ignoring project conventions Violating Just In Time: "We might need this someday" Building frameworks before using them Optimizing without measuring Remember Kaizen is about: Small improvements continuously Preventing errors by design Following proven patterns Building only what's needed Not about: Perfection on first try Massive refactoring projects Clever abstractions Premature optimization Mindset: Good enough today, better tomorrow. Repeat.

kaizen