
Kaizen
Apply incremental Kaizen habits—small refactors, error-proofing, and standardization—while you implement, design, or tune team workflows with your coding agent.
Overview
Kaizen is a journey-wide agent skill that guides continuous improvement, error proofing, and standardization—usable whenever a solo builder needs incremental quality gains before committing to large refactors or process
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill kaizenWhat is this skill?
- Four pillars: continuous improvement, error proofing, standardization, and building only what is needed
- Iterative refinement pattern: make it work, then clear, then efficient—one pass at a time
- Always leave code better: fix small issues, refactor in scope, update comments, remove dead code
- Incremental over revolutionary: smallest viable quality change, verify before the next step
- Philosophy: prevent errors at design time rather than patching after failures
- Four pillars framework for continuous improvement
Adoption & trust: 607 installs on skills.sh; 40.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You ship fast with an agent but quality drifts—big refactors stall, bugs repeat, and process tweaks never stick because everything becomes a one-off heroic fix.
Who is it for?
Builders who want a repeatable improvement mindset during implementation, refactors, architecture discussions, and workflow tuning with Claude Code, Cursor, or Codex.
Skip if: Situations where you need a one-shot security audit checklist, a codegen template, or a hard gate that blocks coding until a separate brainstorming skill finishes—Kaizen is philosophy and habit, not a compliance scanner.
When should I use this skill?
When the user wants to improve code quality, refactor, or discuss process improvements; always applied for code implementation, architecture, process, error handling, and validation contexts.
What do I get? / Deliverables
Your agent applies small, verified improvements, design-time error prevention, and in-scope cleanup so code and workflows get measurably better each session without a risky rewrite.
- Incremental code or design improvements aligned with Kaizen pillars
- Concrete refactor or error-handling steps executed in scope
- Process or standardization notes the agent can follow on later tasks
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Refactor a handler in three passes—working, clear, efficient—while removing dead code the agent notices in scope.
Standardize how you document architecture decisions so the next feature does not reintroduce the same validation gaps.
Tighten error handling and validation incrementally before release instead of bolting fixes on after QA.
Chip away at recurring production friction with one verified improvement per deploy cycle.
Build only what is needed when scoping an MVP so Kaizen scope discipline avoids gold-plating.
How it compares
Use as procedural methodology alongside task-specific refactor or review skills, not instead of dedicated linters, test suites, or formal code-review checklists.
Common Questions / FAQ
Who is kaizen for?
Solo and indie developers who use agentic coding workflows and want steady quality and process gains without scheduling a full rewrite.
When should I use kaizen?
During Build when implementing or refactoring; during Ship when hardening error handling; during Operate when iterating on technical debt; and anytime you want incremental architecture or workflow improvements with your agent.
Is kaizen safe to install?
It is community-sourced procedural guidance with no built-in tool execution; review the Security Audits panel on this Prism page and treat SKILL.md like any third-party agent instruction before enabling auto-apply.
SKILL.md
READMESKILL.md - Kaizen
# Kaizen: Continuous Improvement ## 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> ```typescript // Iteration 1: Make it work const calculateTotal = (items: Item[]) => { let total = 0; for (let i = 0; i < items.length; i++) { total += items[i].price * items[i].quantity; } return total; }; // Iteration 2: Make it clear (refactor) const calculateTotal = (items: Item[]): number => { return items.reduce((total, item) => { return total + (item.price \* item.quantity); }, 0); }; // Iteration 3: Make it robust (add validation) const calculateTotal = (items: Item[]): number => { if (!items?.length) return 0; return items.reduce((total, item) => { if (item.price < 0 || item.quantity < 0) { throw new Error('Price and quantity must be non-negative'); } return total + (item.price \* item.quantity); }, 0); }; ```` Each step is complete, tested, and working </Good> <Bad> ```typescript // Trying to do everything at once const calculateTotal = (items: Item[]): number => { // Validate, optimize, add features, handle edge cases all together if (!items?.length) return 0; const validItems = items.filter(item => { if (item.price < 0) throw new Error('Negative price'); if (item.quantity < 0) throw new Error('Negative quantity'); return item.quantity > 0; // Also filtering zero quantities }); // Plus caching, plus logging, plus currency conversion... return validItems.reduce(...); // Too many concerns at once }; ```` 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 (com