Refactor Code Incrementally

Applies Kaizen ("continuous improvement") as a day-to-day coding philosophy: many small improvements beat one big change, and errors should be prevented at design time rather than fixed at runtime. It's always applied for code implementation and refactoring, architecture and design decisions, process and workflow improvements, and error handling and validation.

Use continuously during development rather than as a one-off task - it shapes how code gets written and reviewed, not a discrete deliverable. It complements structured problem-solving commands (/why for 5-Whys root cause analysis, /cause-and-effect for Fishbone analysis, /plan-do-check-act for iterative cycles, /analyse-problem for A3 documentation, /analyse for method selection) - use those commands for structured problem-solving and this skill for the day-to-day development mindset.

Four pillars, each with concrete practice:

Continuous Improvement: make the smallest viable change, verify before moving to the next, and iterate in passes - first make it work, then make it clear, then make it robust - rather than trying to do everything at once. When refactoring, fix one smell at a time and keep tests passing throughout; when reviewing, suggest incremental improvements prioritized critical-to-nice-to-have rather than full rewrites.

Poka-Yoke (error-proofing): make errors impossible via layered defense - type system at compile time, validation at runtime boundaries, guards/preconditions, and error boundaries for graceful degradation. Concrete techniques: replace loose string status fields with discriminated union types that make invalid states unrepresentable (e.g. a shipped order state that structurally requires a trackingNumber); validate immediately at system boundaries using branded types (PositiveNumber) so downstream code never re-checks; use early-return guards instead of deep nesting; and make configuration fields required rather than optional-with-unsafe-defaults so a missing API_KEY fails at startup, not mid-request.

Standardized Work: follow existing codebase patterns rather than introducing a new one on a whim - search for how similar problems were already solved, check CLAUDE.md for project conventions, and only deviate with team agreement. Document the "why" and "when" in code comments and docstrings, not the "what." Automate standards enforcement via linters, type checks, and CI/CD quality gates. A worked example shows a project-standard Result<T, E> type used consistently across services instead of ad hoc try/catch.

Just-In-Time (JIT/YAGNI): implement only current requirements, add complexity only when a concrete need or measured pain point demands it, and optimize only after profiling - not preemptively. Concrete anti-pattern: building a full pluggable LogTransport abstraction with rate limiters and formatters for a single console.error call. The Rule of Three applies to abstraction: wait for the pattern to appear across 3+ similar cases before generalizing, and prefer duplication over a wrong abstraction.

Red flags across all four pillars: "I'll refactor it later" (Continuous Improvement violation), "users should just be careful" (Poka-Yoke violation), "I prefer to do it my way" (Standardized Work violation), and "we might need this someday" (JIT violation).

Developers and reviewers who want a concrete, example-driven discipline for incremental code quality - preventing errors through type design, following existing patterns, and resisting premature abstraction or optimization - instead of vague "write good code" guidance.