| name | kaizen |
| description | Guide for continuous improvement, error proofing, and standardization. Use this skill when the user wants to improve code quality, refactor, or discuss process improvements. |
| category | Document Processing |
| source | antigravity |
| tags | ["typescript","api","claude","ai","workflow","design","document","cro"] |
| url | https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/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
```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
In Practice
When implementing features:
- Start with simplest version that works
- Add one improvement (error handling, validation, etc.)
- Test and verify
- Repeat if time permits
- 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:
- Type system (compile time)
- Validation (runtime, early)
- Guards (preconditions)
- Error boundaries (graceful degradation)
Type System Error Proofing
```typescript
// Error: string status can be any value
type OrderBad = {
status: string; // Can be "pending", "PENDING", "pnding", anything!
total: number;
};
// Good: Only valid states possible
type OrderStatus = 'pending' | 'processing' | 'shipped' | 'delivered';
type Order = {
status: OrderStatus;
total: number;
};
// Better: States with associated data
type Order =
| { status: 'pending'; createdAt: Date }
| { status: 'processing'; startedAt: Date; estimatedCompletion: Date }
| { status: 'shipped'; trackingNumber: string; shippedAt: Date }
| { status: 'delivered'; deliveredAt: Date; signature: string };
// Now impossible to have shipped without trackingNumber
Type system prevents entire classes of errors
</Good>
<Good>
```typescript
// Make invalid states unrepresentable
type NonEmptyArray<T> = [T, ...T[]];
const firstItem = <T>(items: NonEmptyArray<T>): T => {
return items[0]; // Always safe, never undefined!
};
// Caller must prove array is non-empty
const items: number[] = [1, 2, 3];
if (items.length > 0) {
firstItem(items as NonEmptyArray<number>); // Safe
}
Functio
