kaizen

Name: kaizen
Author: NeoLabHQ

904installs132forks

How to install kaizen?

neolabhq/context-engineering-kit/kaizen

$npx -y skills add NeoLabHQ/context-engineering-kit --skill kaizen

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# Kaizen: Continuous Improvement
2
3	Apply continuous improvement mindset - suggest small iterative improvements, error-proof designs, follow established patterns, avoid over-engineering; automatically applied to guide quality and simplicity
4
5	## Overview
6
7	Small improvements, continuously. Error-proof by design. Follow what works. Build only what's needed.
8
9	Core principle: Many small improvements beat one big change. Prevent errors at design time, not with fixes.
10
11	## When to Use
12
13	Always applied for:
14
15	- Code implementation and refactoring
16	- Architecture and design decisions
17	- Process and workflow improvements
18	- Error handling and validation
19
20	Philosophy: Quality through incremental progress and prevention, not perfection through massive effort.
21
22	## The Four Pillars
23
24	### 1. Continuous Improvement (Kaizen)
25
26	Small, frequent improvements compound into major gains.
27
28	#### Principles
29
30	Incremental over revolutionary:
31
32	- Make smallest viable change that improves quality
33	- One improvement at a time
34	- Verify each change before next
35	- Build momentum through small wins
36
37	Always leave code better:
38
39	- Fix small issues as you encounter them
40	- Refactor while you work (within scope)
41	- Update outdated comments
42	- Remove dead code when you see it
43
44	Iterative refinement:
45
46	- First version: make it work
47	- Second pass: make it clear
48	- Third pass: make it efficient
49	- Don't try all three at once
50
51	<Good>
52	```typescript
53	// Iteration 1: Make it work
54	const calculateTotal = (items: Item[]) => {
55	let total = 0;
56	for (let i = 0; i < items.length; i++) {
57	total += items[i].price * items[i].quantity;
58	}
59	return total;
60	};
61
62	// Iteration 2: Make it clear (refactor)
63	const calculateTotal = (items: Item[]): number => {
64	return items.reduce((total, item) => {
65	return total + (item.price * item.quantity);
66	}, 0);
67	};
68
69	// Iteration 3: Make it robust (add validation)
70	const calculateTotal = (items: Item[]): number => {
71	if (!items?.length) return 0;
72
73	return items.reduce((total, item) => {
74	if (item.price < 0 \|\| item.quantity < 0) {
75	throw new Error('Price and quantity must be non-negative');
76	}
77	return total + (item.price * item.quantity);
78	}, 0);
79	};
80
81	```
82	Each step is complete, tested, and working
83	</Good>
84
85	<Bad>
86	```typescript
87	// Trying to do everything at once
88	const calculateTotal = (items: Item[]): number => {
89	// Validate, optimize, add features, handle edge cases all together
90	if (!items?.length) return 0;
91	const validItems = items.filter(item => {
92	if (item.price < 0) throw new Error('Negative price');
93	if (item.quantity < 0) throw new Error('Negative quantity');
94	return item.quantity > 0; // Also filtering zero quantities
95	});
96	// Plus caching, plus logging, plus currency conversion...
97	return validItems.reduce(...); // Too many concerns at once
98	};
99	```
100
101	Overwhelming, error-prone, hard to verify
102	</Bad>
103
104	#### In Practice
105
106	When implementing features:
107
108	1. Start with simplest version that works
109	2. Add one improvement (error handling, validation, etc.)
110	3. Test and verify
111	4. Repeat if time permits
112	5. Don't try to make it perfect immediately
113
114	When refactoring:
115
116	- Fix one smell at a time
117	- Commit after each improvement
118	- Keep tests passing throughout
119	- Stop when "good enough" (diminishing returns)
120
121	When reviewing code:
122
123	- Suggest incremental improvements (not rewrites)
124	- Prioritize: critical → important → nice-to-have
125	- Focus on highest-impact changes first
126	- Accept "better than before" even if not perfect
127
128	### 2. Poka-Yoke (Error Proofing)
129
130	Design systems that prevent errors at compile/design time, not runtime.
131
132	#### Principles
133
134	Make errors impossible:
135
136	- Type system catches mistakes
137	- Compiler enforces contracts
138	- Invalid states unrepresentable
139	- Errors caught early (left of production)
140
141	Design for safety:
142
143	- Fail fast and loudly
144	- Provide helpful error messages
145	- Make correct path obvious
146	- Make incorrect path difficult
147
148	Defense in layers:
149
150	1. Type system (compile time)
151	2. Validation (runtime, early)
152	3. Guards (preconditions)
153	4. Error boundaries (graceful degradation)
154
155	#### Type System Error Proofing
156
157	<Good>
158	```typescript
159	// Error: string status can be any value
160	type OrderBad = {
161	status: string; // Can be "pending", "PENDING", "pnding", anything!
162	total: number;
163	};
164
165	// Good: Only valid states possible
166	type OrderStatus = 'pending' \| 'processing' \| 'shipped' \| 'delivered';
167	type Order = {
168	status: OrderStatus;
169	total: number;
170	};
171
172	// Better: States with associated data
173	type Order =
174	\| { status: 'pending'; createdAt: Date }
175	\| { status: 'processing'; startedAt: Date; estimatedCompletion: Date }
176	\| { status: 'shipped'; trackingNumber: string; shippedAt: Date }
177	\| { status: 'delivered'; deliveredAt: Date; signa

People who liked this also viewed

6 picks

Type

kaizen

904installs132forks

View on GitHub

How to install kaizen?

neolabhq/context-engineering-kit/kaizen

$npx -y skills add NeoLabHQ/context-engineering-kit --skill kaizen

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Kaizen: Continuous Improvement
2
3	Apply continuous improvement mindset - suggest small iterative improvements, error-proof designs, follow established patterns, avoid over-engineering; automatically applied to guide quality and simplicity
4
5	## Overview
6
7	Small improvements, continuously. Error-proof by design. Follow what works. Build only what's needed.
8
9	Core principle: Many small improvements beat one big change. Prevent errors at design time, not with fixes.
10
11	## When to Use
12
13	Always applied for:
14
15	- Code implementation and refactoring
16	- Architecture and design decisions
17	- Process and workflow improvements
18	- Error handling and validation
19
20	Philosophy: Quality through incremental progress and prevention, not perfection through massive effort.
21
22	## The Four Pillars
23
24	### 1. Continuous Improvement (Kaizen)
25
26	Small, frequent improvements compound into major gains.
27
28	#### Principles
29
30	Incremental over revolutionary:
31
32	- Make smallest viable change that improves quality
33	- One improvement at a time
34	- Verify each change before next
35	- Build momentum through small wins
36
37	Always leave code better:
38
39	- Fix small issues as you encounter them
40	- Refactor while you work (within scope)
41	- Update outdated comments
42	- Remove dead code when you see it
43
44	Iterative refinement:
45
46	- First version: make it work
47	- Second pass: make it clear
48	- Third pass: make it efficient
49	- Don't try all three at once
50
51	<Good>
52	```typescript
53	// Iteration 1: Make it work
54	const calculateTotal = (items: Item[]) => {
55	let total = 0;
56	for (let i = 0; i < items.length; i++) {
57	total += items[i].price * items[i].quantity;
58	}
59	return total;
60	};
61
62	// Iteration 2: Make it clear (refactor)
63	const calculateTotal = (items: Item[]): number => {
64	return items.reduce((total, item) => {
65	return total + (item.price * item.quantity);
66	}, 0);
67	};
68
69	// Iteration 3: Make it robust (add validation)
70	const calculateTotal = (items: Item[]): number => {
71	if (!items?.length) return 0;
72
73	return items.reduce((total, item) => {
74	if (item.price < 0 \|\| item.quantity < 0) {
75	throw new Error('Price and quantity must be non-negative');
76	}
77	return total + (item.price * item.quantity);
78	}, 0);
79	};
80
81	```
82	Each step is complete, tested, and working
83	</Good>
84
85	<Bad>
86	```typescript
87	// Trying to do everything at once
88	const calculateTotal = (items: Item[]): number => {
89	// Validate, optimize, add features, handle edge cases all together
90	if (!items?.length) return 0;
91	const validItems = items.filter(item => {
92	if (item.price < 0) throw new Error('Negative price');
93	if (item.quantity < 0) throw new Error('Negative quantity');
94	return item.quantity > 0; // Also filtering zero quantities
95	});
96	// Plus caching, plus logging, plus currency conversion...
97	return validItems.reduce(...); // Too many concerns at once
98	};
99	```
100
101	Overwhelming, error-prone, hard to verify
102	</Bad>
103
104	#### In Practice
105
106	When implementing features:
107
108	1. Start with simplest version that works
109	2. Add one improvement (error handling, validation, etc.)
110	3. Test and verify
111	4. Repeat if time permits
112	5. Don't try to make it perfect immediately
113
114	When refactoring:
115
116	- Fix one smell at a time
117	- Commit after each improvement
118	- Keep tests passing throughout
119	- Stop when "good enough" (diminishing returns)
120
121	When reviewing code:
122
123	- Suggest incremental improvements (not rewrites)
124	- Prioritize: critical → important → nice-to-have
125	- Focus on highest-impact changes first
126	- Accept "better than before" even if not perfect
127
128	### 2. Poka-Yoke (Error Proofing)
129
130	Design systems that prevent errors at compile/design time, not runtime.
131
132	#### Principles
133
134	Make errors impossible:
135
136	- Type system catches mistakes
137	- Compiler enforces contracts
138	- Invalid states unrepresentable
139	- Errors caught early (left of production)
140
141	Design for safety:
142
143	- Fail fast and loudly
144	- Provide helpful error messages
145	- Make correct path obvious
146	- Make incorrect path difficult
147
148	Defense in layers:
149
150	1. Type system (compile time)
151	2. Validation (runtime, early)
152	3. Guards (preconditions)
153	4. Error boundaries (graceful degradation)
154
155	#### Type System Error Proofing
156
157	<Good>
158	```typescript
159	// Error: string status can be any value
160	type OrderBad = {
161	status: string; // Can be "pending", "PENDING", "pnding", anything!
162	total: number;
163	};
164
165	// Good: Only valid states possible
166	type OrderStatus = 'pending' \| 'processing' \| 'shipped' \| 'delivered';
167	type Order = {
168	status: OrderStatus;
169	total: number;
170	};
171
172	// Better: States with associated data
173	type Order =
174	\| { status: 'pending'; createdAt: Date }
175	\| { status: 'processing'; startedAt: Date; estimatedCompletion: Date }
176	\| { status: 'shipped'; trackingNumber: string; shippedAt: Date }
177	\| { status: 'delivered'; deliveredAt: Date; signa

People who liked this also viewed

6 picks

Type