kaizen by sickn33/antigravity-awesome-skills
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill kaizen小改进,持续进行。通过设计防错。遵循行之有效的方法。只构建所需之物。
核心原则: 许多小改进胜过一次大变更。在设计时预防错误,而非事后修复。
始终适用于:
理念: 通过渐进式进步和预防来保证质量,而非通过巨大努力追求完美。
微小、频繁的改进会累积成重大收益。
渐进式优于革命式:
始终保持代码更好:
迭代优化:
// 迭代 1:让它能运行
const calculateTotal = (items: Item[]): number => {
let total = 0;
for (const item of items) {
total += item.price * item.quantity;
}
return total;
};
// 迭代 2:让它更清晰(重构)
const calculateTotal = (items: Item[]): number => {
return items.reduce((total, item) => {
return total + (item.price * item.quantity);
}, 0);
};
// 迭代 3:让它更健壮(添加验证)
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);
};
<Good>
每个步骤都是完整、经过测试且可运行的
</Good>
<Bad>
```typescript
// 试图一次性完成所有事情
const calculateTotal = (items: Item[]): number => {
// 验证、优化、添加功能、处理边缘情况全部一起做
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; // 同时过滤数量为零的情况
});
// 加上缓存、日志记录、货币转换...
return validItems.reduce(...); // 一次处理太多关注点
};
```
</Bad>
<Good>
类型系统防止了整类错误
</Good>
<Good>
```typescript
// 使无效状态无法表示
type NonEmptyArray<T> = [T, ...T[]];
<Good>
在边界验证一次,其他地方都安全
</Good>
<Good>
```typescript
// 提前返回防止深度嵌套代码
const processUser = (user: User | null) => {
if (!user) {
logger.error('User not found');
return;
}
<Good>
在启动时失败,而不是在生产环境中
</Good>
<Good>
```typescript
// 现有代码库的 API 客户端模式
class UserAPIClient {
async getUser(id: string): Promise<User> {
return this.fetch(`/users/${id}`);
}
}
</Bad>
<Good>
```typescript
// 项目标准:Result 类型用于可恢复错误
type Result<T, E> = { ok: true; value: T } | { ok: false; error: E };
</Bad>
<Good>
```typescript
// 从简单开始
const formatCurrency = (amount: number): string => {
return `$${amount.toFixed(2)}`;
};
</Bad>
<Good>
```typescript
// 为当前需求使用简单函数
const getUsers = async (): Promise<User[]> => {
return db.query('SELECT * FROM users');
};
</Good>
<Bad>
```typescript
// 过早优化
const filterActiveUsers = (users: User[]): User[] => {
// "这可能很慢,所以让我们缓存和索引"
const cache = new WeakMap();
const indexed = buildBTreeIndex(users, 'isActive');
// 100 行优化代码
// 增加复杂性,更难维护
// 没有证据表明需要它
};
```
</Bad>
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
令人不知所措、容易出错、难以验证
实现功能时:
重构时:
审查代码时:
设计能在编译/设计时而非运行时防止错误的系统。
使错误不可能发生:
为安全而设计:
分层防御:
// 良好:只允许有效状态
type OrderStatus = 'pending' | 'processing' | 'shipped' | 'delivered';
type Order = { status: OrderStatus; total: number; };
// 更好:带有关联数据的状态
type Order =
| { status: 'pending'; createdAt: Date }
| { status: 'processing'; startedAt: Date; estimatedCompletion: Date }
| { status: 'shipped'; trackingNumber: string; shippedAt: Date }
| { status: 'delivered'; deliveredAt: Date; signature: string };
// 现在不可能出现已发货但没有 trackingNumber 的情况
const firstItem = <T>(items: NonEmptyArray<T>): T => { return items[0]; // 总是安全的,绝不可能是 undefined! };
// 调用者必须证明数组非空 const items: number[] = [1, 2, 3]; if (items.length > 0) { firstItem(items as NonEmptyArray<number>); // 安全 }
</Good>
函数签名保证安全性
#### 验证防错
```typescript
// 良好:立即验证
const processPayment = (amount: number) => {
if (amount <= 0) {
throw new Error('Payment amount must be positive');
}
if (amount > 10000) {
throw new Error('Payment exceeds maximum allowed');
}
const fee = amount * 0.03;
// ... 现在可以安全使用了
};
// 更好:在边界处验证并使用标记类型
type PositiveNumber = number & { readonly __brand: 'PositiveNumber' };
const validatePositive = (n: number): PositiveNumber => {
if (n <= 0) throw new Error('Must be positive');
return n as PositiveNumber;
};
const processPayment = (amount: PositiveNumber) => {
// amount 保证为正数,无需检查
const fee = amount * 0.03;
};
// 在系统边界验证
const handlePaymentRequest = (req: Request) => {
const amount = validatePositive(req.body.amount); // 验证一次
processPayment(amount); // 随处安全使用
};
if (!user.email) { logger.error('User email missing'); return; }
if (!user.isActive) { logger.info('User inactive, skipping'); return; }
// 主逻辑在此,保证用户有效且活跃 sendEmail(user.email, 'Welcome!'); };
</Good>
守卫使假设明确并强制执行
#### 配置防错
```typescript
const client = new APIClient({ timeout: 5000 }); // apiKey 缺失!
// 良好:必需配置,尽早失败
type Config = { apiKey: string; timeout: number; };
const loadConfig = (): Config => {
const apiKey = process.env.API_KEY;
if (!apiKey) {
throw new Error('API_KEY environment variable required');
}
return { apiKey, timeout: 5000, };
};
// 如果配置无效,应用在启动时失败,而不是在请求过程中
const config = loadConfig();
const client = new APIClient(config);
设计 API 时:
Result<T, E> 而非抛出异常处理错误时:
配置时:
遵循既定模式。记录行之有效的方法。使良好实践易于遵循。
一致性优于巧妙性:
文档与代码共存:
自动化标准:
// 新代码遵循相同模式
class OrderAPIClient {
async getOrder(id: string): Promise<Order> {
return this.fetch(/orders/${id});
}
}
</Good>
一致性使代码库可预测
<Bad>
```typescript
// 新代码未经讨论引入了不同模式
const getOrder = async (id: string): Promise<Order> => {
// 打破一致性,"因为我更喜欢函数"
};
不一致性造成混淆
// 所有服务都遵循此模式 const fetchUser = async (id: string): Promise<Result<User, Error>> => { try { const user = await db.users.findById(id); if (!user) { return { ok: false, error: new Error('User not found') }; } return { ok: true, value: user }; } catch (err) { return { ok: false, error: err as Error }; } };
// 调用者使用一致的模式 const result = await fetchUser('123'); if (!result.ok) { logger.error('Failed to fetch user', result.error); return; } const user = result.value; // 类型安全!
</Good>
跨代码库的标准模式
#### 文档标准
#### 实践
**添加新模式前:**
* 在代码库中搜索已解决的类似问题
* 检查 CLAUDE.md 了解项目约定
* 如果偏离模式,与团队讨论
* 引入新模式时更新文档
**编写代码时:**
* 匹配现有文件结构
* 使用相同的命名约定
* 遵循相同的错误处理方法
* 从相同位置导入
**审查时:**
* 检查与现有代码的一致性
* 指向代码库中的示例
* 建议与标准对齐
* 如果出现新标准,更新 CLAUDE.md
### 4. 准时制
构建当前所需之物。不多不少。避免过早优化和过度工程。
#### 原则
**YAGNI(你不需要它):**
* 仅实现当前需求
* 没有"以防万一"的功能
* 没有"我们以后可能需要这个"的代码
* 删除推测性代码
**能工作的最简单方案:**
* 从直接的解决方案开始
* 仅在需要时添加复杂性
* 当需求变化时重构
* 不要预测未来需求
**在测量后优化:**
* 没有过早优化
* 优化前先分析性能
* 测量变更的影响
* 接受"足够好"的性能
#### YAGNI 实践
<Bad>
```typescript
class ConsoleTransport implements LogTransport { /*...*/ }
class FileTransport implements LogTransport { /* ... */ }
class RemoteTransport implements LogTransport { /* ... */ }
class Logger {
private transports: LogTransport[] = [];
private queue: LogEntry[] = [];
private rateLimiter: RateLimiter;
private formatter: LogFormatter;
// 200 行代码用于"也许我们将来需要它"
}
const logError = (error: Error) => {
Logger.getInstance().log('error', error.message);
};
为想象中的未来需求构建
何时添加复杂性:
// 需求演变:支持多种货币
const formatCurrency = (amount: number, currency: string): string => {
const symbols = { USD: '$', EUR: '€', GBP: '£' };
return ${symbols[currency]}${amount.toFixed(2)};
};
// 需求演变:支持本地化 const formatCurrency = (amount: number, locale: string): string => { return new Intl.NumberFormat(locale, { style: 'currency', currency: locale === 'en-US' ? 'USD' : 'EUR', }).format(amount); };
</Good>
仅在需要时添加复杂性
#### 过早抽象
<Bad>
```typescript
class GenericRepository { /*300 行 */ }
class QueryBuilder { /* 200 行*/ }
// ... 为单个表构建整个 ORM
为不确定的未来构建庞大的抽象
const getUserById = async (id: string): Promise<User | null> => { return db.query('SELECT * FROM users WHERE id = $1', [id]); };
// 当模式在多个实体中出现时,再进行抽象
</Good>
仅在模式在 3 个以上案例中得到验证时才进行抽象
#### 性能优化
<Good>
```typescript
// 基准测试显示:1000 个用户耗时 50ms(可接受)
// ✓ 发布它,无需优化
// 之后:分析显示这是瓶颈
// 然后使用索引查找或缓存进行优化
基于测量而非假设进行优化
为未测量的问题提供复杂解决方案
实现时:
优化时:
抽象时:
Kaizen 技能指导您的工作方式。命令提供结构化分析:
/why:根本原因分析(5 Whys)/cause-and-effect:多因素分析(鱼骨图)/plan-do-check-act:迭代改进循环/analyse-problem:全面文档记录(A3)/analyse:智能方法选择(现场观察/价值流图/浪费分析)使用命令进行结构化问题解决。在日常开发中应用此技能。
违反持续改进:
违反防错:
违反标准化工作:
违反准时制:
Kaizen 是关于:
不是关于:
心态: 今天足够好,明天会更好。不断重复。
每周安装次数
325
代码仓库
GitHub 星标
27.1K
首次出现
2026 年 1 月 19 日
安全审计
安装于
opencode259
gemini-cli251
claude-code251
antigravity224
codex222
cursor220
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.
Always applied for:
Philosophy: Quality through incremental progress and prevention, not perfection through massive effort.
Small, frequent improvements compound into major gains.
Incremental over revolutionary:
Always leave code better:
Iterative refinement:
// 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
When implementing features:
When refactoring:
When reviewing code:
Design systems that prevent errors at compile/design time, not runtime.
Make errors impossible:
Design for safety:
Defense in layers:
// 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
}
Function signature guarantees safety
// Good: Validate immediately const processPayment = (amount: number) => { if (amount <= 0) { throw new Error('Payment amount must be positive'); } if (amount > 10000) { throw new Error('Payment exceeds maximum allowed'); }
const fee = amount * 0.03; // ... now safe to use };
// Better: Validation at boundary with branded type type PositiveNumber = number & { readonly __brand: 'PositiveNumber' };
const validatePositive = (n: number): PositiveNumber => { if (n <= 0) throw new Error('Must be positive'); return n as PositiveNumber; };
const processPayment = (amount: PositiveNumber) => { // amount is guaranteed positive, no need to check const fee = amount * 0.03; };
// Validate at system boundary const handlePaymentRequest = (req: Request) => { const amount = validatePositive(req.body.amount); // Validate once processPayment(amount); // Use everywhere safely };
Validate once at boundary, safe everywhere else
</Good>
#### Guards and Preconditions
<Good>
```typescript
// Early returns prevent deeply nested code
const processUser = (user: User | null) => {
if (!user) {
logger.error('User not found');
return;
}
if (!user.email) {
logger.error('User email missing');
return;
}
if (!user.isActive) {
logger.info('User inactive, skipping');
return;
}
// Main logic here, guaranteed user is valid and active
sendEmail(user.email, 'Welcome!');
};
Guards make assumptions explicit and enforced
const client = new APIClient({ timeout: 5000 }); // apiKey missing!
// Good: Required config, fails early type Config = { apiKey: string; timeout: number; };
const loadConfig = (): Config => { const apiKey = process.env.API_KEY; if (!apiKey) { throw new Error('API_KEY environment variable required'); }
return { apiKey, timeout: 5000, }; };
// App fails at startup if config invalid, not during request const config = loadConfig(); const client = new APIClient(config);
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>
```typescript
// Existing codebase pattern for API clients
class UserAPIClient {
async getUser(id: string): Promise<User> {
return this.fetch(`/users/${id}`);
}
}
// New code follows the same pattern
class OrderAPIClient {
async getOrder(id: string): Promise<Order> {
return this.fetch(`/orders/${id}`);
}
}
Consistency makes codebase predictable
// New code introduces different pattern without discussion const getOrder = async (id: string): Promise => { // Breaking consistency "because I prefer functions" };
Inconsistency creates confusion
</Bad>
#### Error Handling Patterns
<Good>
```typescript
// Project standard: Result type for recoverable errors
type Result<T, E> = { ok: true; value: T } | { ok: false; error: E };
// All services follow this pattern
const fetchUser = async (id: string): Promise<Result<User, Error>> => {
try {
const user = await db.users.findById(id);
if (!user) {
return { ok: false, error: new Error('User not found') };
}
return { ok: true, value: user };
} catch (err) {
return { ok: false, error: err as Error };
}
};
// Callers use consistent pattern
const result = await fetchUser('123');
if (!result.ok) {
logger.error('Failed to fetch user', result.error);
return;
}
const user = result.value; // Type-safe!
Standard pattern across codebase
Before adding new patterns:
When writing code:
When reviewing:
Build what's needed now. No more, no less. Avoid premature optimization and over-engineering.
YAGNI (You Aren't Gonna Need It):
Simplest thing that works:
Optimize when measured:
class ConsoleTransport implements LogTransport { /.../ } class FileTransport implements LogTransport { /_ ... / } class RemoteTransport implements LogTransport { / ..._/ }
class Logger { private transports: LogTransport[] = []; private queue: LogEntry[] = []; private rateLimiter: RateLimiter; private formatter: LogFormatter;
// 200 lines of code for "maybe we'll need it" }
const logError = (error: Error) => { Logger.getInstance().log('error', error.message); };
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>
```typescript
// Start simple
const formatCurrency = (amount: number): string => {
return `$${amount.toFixed(2)}`;
};
// Requirement evolves: support multiple currencies
const formatCurrency = (amount: number, currency: string): string => {
const symbols = { USD: '$', EUR: '€', GBP: '£' };
return `${symbols[currency]}${amount.toFixed(2)}`;
};
// Requirement evolves: support localization
const formatCurrency = (amount: number, locale: string): string => {
return new Intl.NumberFormat(locale, {\n style: 'currency',
currency: locale === 'en-US' ? 'USD' : 'EUR',
}).format(amount);
};
Complexity added only when needed
class GenericRepository { /300 lines / } class QueryBuilder { / 200 lines/ } // ... building entire ORM for single table
Massive abstraction for uncertain future
</Bad>
<Good>
```typescript
// Simple functions for current needs
const getUsers = async (): Promise<User[]> => {
return db.query('SELECT * FROM users');
};
const getUserById = async (id: string): Promise<User | null> => {
return db.query('SELECT * FROM users WHERE id = $1', [id]);
};
// When pattern emerges across multiple entities, then abstract
Abstract only when pattern proven across 3+ cases
// Benchmark shows: 50ms for 1000 users (acceptable) // ✓ Ship it, no optimization needed
// Later: After profiling shows this is bottleneck // Then optimize with indexed lookup or caching
Optimize based on measurement, not assumptions
</Good>
<Bad>
```typescript
// Premature optimization
const filterActiveUsers = (users: User[]): User[] => {
// "This might be slow, so let's cache and index"
const cache = new WeakMap();
const indexed = buildBTreeIndex(users, 'isActive');
// 100 lines of optimization code
// Adds complexity, harder to maintain
// No evidence it was needed
};\
Complex solution for unmeasured problem
When implementing:
When optimizing:
When abstracting:
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.
Violating Continuous Improvement:
Violating Poka-Yoke:
Violating Standardized Work:
Violating Just-In-Time:
Kaizen is about:
Not about:
Mindset: Good enough today, better tomorrow. Repeat.
Weekly Installs
325
Repository
GitHub Stars
27.1K
First Seen
Jan 19, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
opencode259
gemini-cli251
claude-code251
antigravity224
codex222
cursor220
生产排程实战指南:离散制造工厂的有限产能排程、换线优化与瓶颈管理
809 周安装