[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-86478754-bc88-49ac-b0f8-cc424c64f8b7":3,"$f5W0SJszijcRritRR6bABpCNv-6HgGXkw7WlBQ_uKYSk":43},{"id":4,"title":5,"description":6,"categoryId":7,"moduleId":8,"tags":9,"prompt":10,"icon":11,"source":12,"sourceUrl":13,"authorId":14,"authorName":15,"isPublic":16,"stars":17,"runs":18,"createdAt":19,"updatedAt":19,"module":20,"category":27,"packages":34},"86478754-bc88-49ac-b0f8-cc424c64f8b7","kaizen","持续改进、防错和标准化指南。当用户希望提高代码质量、重构或讨论流程改进时，使用此技能。","cat_life_career","mod_other","sickn33,other","---\nname: kaizen\ndescription: \"Guide for continuous improvement, error proofing, and standardization. Use this skill when the user wants to improve code quality, refactor, or discuss process improvements.\"\nrisk: unknown\nsource: community\ndate_added: \"2026-02-27\"\n---\n\n# Kaizen: Continuous Improvement\n\n## Overview\n\nSmall improvements, continuously. Error-proof by design. Follow what works. Build only what's needed.\n\n**Core principle:** Many small improvements beat one big change. Prevent errors at design time, not with fixes.\n\n## When to Use\n**Always applied for:**\n\n- Code implementation and refactoring\n- Architecture and design decisions\n- Process and workflow improvements\n- Error handling and validation\n\n**Philosophy:** Quality through incremental progress and prevention, not perfection through massive effort.\n\n## The Four Pillars\n\n### 1. Continuous Improvement (Kaizen)\n\nSmall, frequent improvements compound into major gains.\n\n#### Principles\n\n**Incremental over revolutionary:**\n\n- Make smallest viable change that improves quality\n- One improvement at a time\n- Verify each change before next\n- Build momentum through small wins\n\n**Always leave code better:**\n\n- Fix small issues as you encounter them\n- Refactor while you work (within scope)\n- Update outdated comments\n- Remove dead code when you see it\n\n**Iterative refinement:**\n\n- First version: make it work\n- Second pass: make it clear\n- Third pass: make it efficient\n- Don't try all three at once\n\n\u003CGood>\n```typescript\n\u002F\u002F Iteration 1: Make it work\nconst calculateTotal = (items: Item[]) => {\n  let total = 0;\n  for (let i = 0; i \u003C items.length; i++) {\n    total += items[i].price * items[i].quantity;\n  }\n  return total;\n};\n\n\u002F\u002F Iteration 2: Make it clear (refactor)\nconst calculateTotal = (items: Item[]): number => {\nreturn items.reduce((total, item) => {\nreturn total + (item.price \\* item.quantity);\n}, 0);\n};\n\n\u002F\u002F Iteration 3: Make it robust (add validation)\nconst calculateTotal = (items: Item[]): number => {\nif (!items?.length) return 0;\n\nreturn items.reduce((total, item) => {\nif (item.price \u003C 0 || item.quantity \u003C 0) {\nthrow new Error('Price and quantity must be non-negative');\n}\nreturn total + (item.price \\* item.quantity);\n}, 0);\n};\n\n````\nEach step is complete, tested, and working\n\u003C\u002FGood>\n\n\u003CBad>\n```typescript\n\u002F\u002F Trying to do everything at once\nconst calculateTotal = (items: Item[]): number => {\n  \u002F\u002F Validate, optimize, add features, handle edge cases all together\n  if (!items?.length) return 0;\n  const validItems = items.filter(item => {\n    if (item.price \u003C 0) throw new Error('Negative price');\n    if (item.quantity \u003C 0) throw new Error('Negative quantity');\n    return item.quantity > 0; \u002F\u002F Also filtering zero quantities\n  });\n  \u002F\u002F Plus caching, plus logging, plus currency conversion...\n  return validItems.reduce(...); \u002F\u002F Too many concerns at once\n};\n````\n\nOverwhelming, error-prone, hard to verify\n\u003C\u002FBad>\n\n#### In Practice\n\n**When implementing features:**\n\n1. Start with simplest version that works\n2. Add one improvement (error handling, validation, etc.)\n3. Test and verify\n4. Repeat if time permits\n5. Don't try to make it perfect immediately\n\n**When refactoring:**\n\n- Fix one smell at a time\n- Commit after each improvement\n- Keep tests passing throughout\n- Stop when \"good enough\" (diminishing returns)\n\n**When reviewing code:**\n\n- Suggest incremental improvements (not rewrites)\n- Prioritize: critical → important → nice-to-have\n- Focus on highest-impact changes first\n- Accept \"better than before\" even if not perfect\n\n### 2. Poka-Yoke (Error Proofing)\n\nDesign systems that prevent errors at compile\u002Fdesign time, not runtime.\n\n#### Principles\n\n**Make errors impossible:**\n\n- Type system catches mistakes\n- Compiler enforces contracts\n- Invalid states unrepresentable\n- Errors caught early (left of production)\n\n**Design for safety:**\n\n- Fail fast and loudly\n- Provide helpful error messages\n- Make correct path obvious\n- Make incorrect path difficult\n\n**Defense in layers:**\n\n1. Type system (compile time)\n2. Validation (runtime, early)\n3. Guards (preconditions)\n4. Error boundaries (graceful degradation)\n\n#### Type System Error Proofing\n\n\u003CGood>\n```typescript\n\u002F\u002F Error: string status can be any value\ntype OrderBad = {\n  status: string; \u002F\u002F Can be \"pending\", \"PENDING\", \"pnding\", anything!\n  total: number;\n};\n\n\u002F\u002F Good: Only valid states possible\ntype OrderStatus = 'pending' | 'processing' | 'shipped' | 'delivered';\ntype Order = {\nstatus: OrderStatus;\ntotal: number;\n};\n\n\u002F\u002F Better: States with associated data\ntype Order =\n| { status: 'pending'; createdAt: Date }\n| { status: 'processing'; startedAt: Date; estimatedCompletion: Date }\n| { status: 'shipped'; trackingNumber: string; shippedAt: Date }\n| { status: 'delivered'; deliveredAt: Date; signature: string };\n\n\u002F\u002F Now impossible to have shipped without trackingNumber\n\n````\nType system prevents entire classes of errors\n\u003C\u002FGood>\n\n\u003CGood>\n```typescript\n\u002F\u002F Make invalid states unrepresentable\ntype NonEmptyArray\u003CT> = [T, ...T[]];\n\nconst firstItem = \u003CT>(items: NonEmptyArray\u003CT>): T => {\n  return items[0]; \u002F\u002F Always safe, never undefined!\n};\n\n\u002F\u002F Caller must prove array is non-empty\nconst items: number[] = [1, 2, 3];\nif (items.length > 0) {\n  firstItem(items as NonEmptyArray\u003Cnumber>); \u002F\u002F Safe\n}\n````\n\nFunction signature guarantees safety\n\u003C\u002FGood>\n\n#### Validation Error Proofing\n\n\u003CGood>\n```typescript\n\u002F\u002F Error: Validation after use\nconst processPayment = (amount: number) => {\n  const fee = amount * 0.03; \u002F\u002F Used before validation!\n  if (amount \u003C= 0) throw new Error('Invalid amount');\n  \u002F\u002F ...\n};\n\n\u002F\u002F Good: Validate immediately\nconst processPayment = (amount: number) => {\nif (amount \u003C= 0) {\nthrow new Error('Payment amount must be positive');\n}\nif (amount > 10000) {\nthrow new Error('Payment exceeds maximum allowed');\n}\n\nconst fee = amount \\* 0.03;\n\u002F\u002F ... now safe to use\n};\n\n\u002F\u002F Better: Validation at boundary with branded type\ntype PositiveNumber = number & { readonly \\_\\_brand: 'PositiveNumber' };\n\nconst validatePositive = (n: number): PositiveNumber => {\nif (n \u003C= 0) throw new Error('Must be positive');\nreturn n as PositiveNumber;\n};\n\nconst processPayment = (amount: PositiveNumber) => {\n\u002F\u002F amount is guaranteed positive, no need to check\nconst fee = amount \\* 0.03;\n};\n\n\u002F\u002F Validate at system boundary\nconst handlePaymentRequest = (req: Request) => {\nconst amount = validatePositive(req.body.amount); \u002F\u002F Validate once\nprocessPayment(amount); \u002F\u002F Use everywhere safely\n};\n\n````\nValidate once at boundary, safe everywhere else\n\u003C\u002FGood>\n\n#### Guards and Preconditions\n\n\u003CGood>\n```typescript\n\u002F\u002F Early returns prevent deeply nested code\nconst processUser = (user: User | null) => {\n  if (!user) {\n    logger.error('User not found');\n    return;\n  }\n\n  if (!user.email) {\n    logger.error('User email missing');\n    return;\n  }\n\n  if (!user.isActive) {\n    logger.info('User inactive, skipping');\n    return;\n  }\n\n  \u002F\u002F Main logic here, guaranteed user is valid and active\n  sendEmail(user.email, 'Welcome!');\n};\n````\n\nGuards make assumptions explicit and enforced\n\u003C\u002FGood>\n\n#### Configuration Error Proofing\n\n\u003CGood>\n```typescript\n\u002F\u002F Error: Optional config with unsafe defaults\ntype ConfigBad = {\n  apiKey?: string;\n  timeout?: number;\n};\n\nconst client = new APIClient({ timeout: 5000 }); \u002F\u002F apiKey missing!\n\n\u002F\u002F Good: Required config, fails early\ntype Config = {\napiKey: string;\ntimeout: number;\n};\n\nconst loadConfig = (): Config => {\nconst apiKey = process.env.API_KEY;\nif (!apiKey) {\nthrow new Error('API_KEY environment variable required');\n}\n\nreturn {\napiKey,\ntimeout: 5000,\n};\n};\n\n\u002F\u002F App fails at startup if config invalid, not during request\nconst config = loadConfig();\nconst client = new APIClient(config);\n\n````\nFail at startup, not in production\n\u003C\u002FGood>\n\n#### In Practice\n\n**When designing APIs:**\n- Use types to constrain inputs\n- Make invalid states unrepresentable\n- Return Result\u003CT, E> instead of throwing\n- Document preconditions in types\n\n**When handling errors:**\n- Validate at system boundaries\n\n- Use guards for preconditions\n- Fail fast with clear messages\n- Log context for debugging\n\n**When configuring:**\n- Required over optional with defaults\n- Validate all config at startup\n- Fail deployment if config invalid\n- Don't allow partial configurations\n\n### 3. Standardized Work\nFollow established patterns. Document what works. Make good practices easy to follow.\n\n#### Principles\n\n**Consistency over cleverness:**\n- Follow existing codebase patterns\n- Don't reinvent solved problems\n- New pattern only if significantly better\n- Team agreement on new patterns\n\n**Documentation lives with code:**\n- README for setup and architecture\n- CLAUDE.md for AI coding conventions\n- Comments for \"why\", not \"what\"\n- Examples for complex patterns\n\n**Automate standards:**\n- Linters enforce style\n- Type checks enforce contracts\n- Tests verify behavior\n- CI\u002FCD enforces quality gates\n\n#### Following Patterns\n\n\u003CGood>\n```typescript\n\u002F\u002F Existing codebase pattern for API clients\nclass UserAPIClient {\n  async getUser(id: string): Promise\u003CUser> {\n    return this.fetch(`\u002Fusers\u002F${id}`);\n  }\n}\n\n\u002F\u002F New code follows the same pattern\nclass OrderAPIClient {\n  async getOrder(id: string): Promise\u003COrder> {\n    return this.fetch(`\u002Forders\u002F${id}`);\n  }\n}\n````\n\nConsistency makes codebase predictable\n\u003C\u002FGood>\n\n\u003CBad>\n```typescript\n\u002F\u002F Existing pattern uses classes\nclass UserAPIClient { \u002F* ... *\u002F }\n\n\u002F\u002F New code introduces different pattern without discussion\nconst getOrder = async (id: string): Promise\u003COrder> => {\n\u002F\u002F Breaking consistency \"because I prefer functions\"\n};\n\n````\nInconsistency creates confusion\n\u003C\u002FBad>\n\n#### Error Handling Patterns\n\n\u003CGood>\n```typescript\n\u002F\u002F Project standard: Result type for recoverable errors\ntype Result\u003CT, E> = { ok: true; value: T } | { ok: false; error: E };\n\n\u002F\u002F All services follow this pattern\nconst fetchUser = async (id: string): Promise\u003CResult\u003CUser, Error>> => {\n  try {\n    const user = await db.users.findById(id);\n    if (!user) {\n      return { ok: false, error: new Error('User not found') };\n    }\n    return { ok: true, value: user };\n  } catch (err) {\n    return { ok: false, error: err as Error };\n  }\n};\n\n\u002F\u002F Callers use consistent pattern\nconst result = await fetchUser('123');\nif (!result.ok) {\n  logger.error('Failed to fetch user', result.error);\n  return;\n}\nconst user = result.value; \u002F\u002F Type-safe!\n````\n\nStandard pattern across codebase\n\u003C\u002FGood>\n\n#### Documentation Standards\n\n\u003CGood>\n```typescript\n\u002F**\n * Retries an async operation with exponential backoff.\n *\n * Why: Network requests fail temporarily; retrying improves reliability\n * When to use: External API calls, database operations\n * When not to use: User input validation, internal function calls\n *\n * @example\n * const result = await retry(\n *   () => fetch('https:\u002F\u002Fapi.example.com\u002Fdata'),\n *   { maxAttempts: 3, baseDelay: 1000 }\n * );\n *\u002F\nconst retry = async \u003CT>(\n  operation: () => Promise\u003CT>,\n  options: RetryOptions\n): Promise\u003CT> => {\n  \u002F\u002F Implementation...\n};\n```\nDocuments why, when, and how\n\u003C\u002FGood>\n\n#### In Practice\n\n**Before adding new patterns:**\n\n- Search codebase for similar problems solved\n- Check CLAUDE.md for project conventions\n- Discuss with team if breaking from pattern\n- Update docs when introducing new pattern\n\n**When writing code:**\n\n- Match existing file structure\n- Use same naming conventions\n- Follow same error handling approach\n- Import from same locations\n\n**When reviewing:**\n\n- Check consistency with existing code\n- Point to examples in codebase\n- Suggest aligning with standards\n- Update CLAUDE.md if new standard emerges\n\n### 4. Just-In-Time (JIT)\n\nBuild what's needed now. No more, no less. Avoid premature optimization and over-engineering.\n\n#### Principles\n\n**YAGNI (You Aren't Gonna Need It):**\n\n- Implement only current requirements\n- No \"just in case\" features\n- No \"we might need this later\" code\n- Delete speculation\n\n**Simplest thing that works:**\n\n- Start with straightforward solution\n- Add complexity only when needed\n- Refactor when requirements change\n- Don't anticipate future needs\n\n**Optimize when measured:**\n\n- No premature optimization\n- Profile before optimizing\n- Measure impact of changes\n- Accept \"good enough\" performance\n\n#### YAGNI in Action\n\n\u003CGood>\n```typescript\n\u002F\u002F Current requirement: Log errors to console\nconst logError = (error: Error) => {\n  console.error(error.message);\n};\n```\nSimple, meets current need\n\u003C\u002FGood>\n\n\u003CBad>\n```typescript\n\u002F\u002F Over-engineered for \"future needs\"\ninterface LogTransport {\n  write(level: LogLevel, message: string, meta?: LogMetadata): Promise\u003Cvoid>;\n}\n\nclass ConsoleTransport implements LogTransport { \u002F_... _\u002F }\nclass FileTransport implements LogTransport { \u002F_ ... _\u002F }\nclass RemoteTransport implements LogTransport { \u002F_ ..._\u002F }\n\nclass Logger {\nprivate transports: LogTransport[] = [];\nprivate queue: LogEntry[] = [];\nprivate rateLimiter: RateLimiter;\nprivate formatter: LogFormatter;\n\n\u002F\u002F 200 lines of code for \"maybe we'll need it\"\n}\n\nconst logError = (error: Error) => {\nLogger.getInstance().log('error', error.message);\n};\n\n````\nBuilding for imaginary future requirements\n\u003C\u002FBad>\n\n**When to add complexity:**\n- Current requirement demands it\n- Pain points identified through use\n- Measured performance issues\n- Multiple use cases emerged\n\n\u003CGood>\n```typescript\n\u002F\u002F Start simple\nconst formatCurrency = (amount: number): string => {\n  return `$${amount.toFixed(2)}`;\n};\n\n\u002F\u002F Requirement evolves: support multiple currencies\nconst formatCurrency = (amount: number, currency: string): string => {\n  const symbols = { USD: '$', EUR: '€', GBP: '£' };\n  return `${symbols[currency]}${amount.toFixed(2)}`;\n};\n\n\u002F\u002F Requirement evolves: support localization\nconst formatCurrency = (amount: number, locale: string): string => {\n  return new Intl.NumberFormat(locale, {\\n    style: 'currency',\n    currency: locale === 'en-US' ? 'USD' : 'EUR',\n  }).format(amount);\n};\n````\n\nComplexity added only when needed\n\u003C\u002FGood>\n\n#### Premature Abstraction\n\n\u003CBad>\n```typescript\n\u002F\u002F One use case, but building generic framework\nabstract class BaseCRUDService\u003CT> {\n  abstract getAll(): Promise\u003CT[]>;\n  abstract getById(id: string): Promise\u003CT>;\n  abstract create(data: Partial\u003CT>): Promise\u003CT>;\n  abstract update(id: string, data: Partial\u003CT>): Promise\u003CT>;\n  abstract delete(id: string): Promise\u003Cvoid>;\n}\n\nclass GenericRepository\u003CT> { \u002F_300 lines _\u002F }\nclass QueryBuilder\u003CT> { \u002F_ 200 lines_\u002F }\n\u002F\u002F ... building entire ORM for single table\n\n````\nMassive abstraction for uncertain future\n\u003C\u002FBad>\n\n\u003CGood>\n```typescript\n\u002F\u002F Simple functions for current needs\nconst getUsers = async (): Promise\u003CUser[]> => {\n  return db.query('SELECT * FROM users');\n};\n\nconst getUserById = async (id: string): Promise\u003CUser | null> => {\n  return db.query('SELECT * FROM users WHERE id = $1', [id]);\n};\n\n\u002F\u002F When pattern emerges across multiple entities, then abstract\n````\n\nAbstract only when pattern proven across 3+ cases\n\u003C\u002FGood>\n\n#### Performance Optimization\n\n\u003CGood>\n```typescript\n\u002F\u002F Current: Simple approach\nconst filterActiveUsers = (users: User[]): User[] => {\n  return users.filter(user => user.isActive);\n};\n\n\u002F\u002F Benchmark shows: 50ms for 1000 users (acceptable)\n\u002F\u002F ✓ Ship it, no optimization needed\n\n\u002F\u002F Later: After profiling shows this is bottleneck\n\u002F\u002F Then optimize with indexed lookup or caching\n\n````\nOptimize based on measurement, not assumptions\n\u003C\u002FGood>\n\n\u003CBad>\n```typescript\n\u002F\u002F Premature optimization\nconst filterActiveUsers = (users: User[]): User[] => {\n  \u002F\u002F \"This might be slow, so let's cache and index\"\n  const cache = new WeakMap();\n  const indexed = buildBTreeIndex(users, 'isActive');\n  \u002F\u002F 100 lines of optimization code\n  \u002F\u002F Adds complexity, harder to maintain\n  \u002F\u002F No evidence it was needed\n};\\\n````\n\nComplex solution for unmeasured problem\n\u003C\u002FBad>\n\n#### In Practice\n\n**When implementing:**\n\n- Solve the immediate problem\n- Use straightforward approach\n- Resist \"what if\" thinking\n- Delete speculative code\n\n**When optimizing:**\n\n- Profile first, optimize second\n- Measure before and after\n- Document why optimization needed\n- Keep simple version in tests\n\n**When abstracting:**\n\n- Wait for 3+ similar cases (Rule of Three)\n- Make abstraction as simple as possible\n- Prefer duplication over wrong abstraction\n- Refactor when pattern clear\n\n## Integration with Commands\n\nThe Kaizen skill guides how you work. The commands provide structured analysis:\n\n- **`\u002Fwhy`**: Root cause analysis (5 Whys)\n- **`\u002Fcause-and-effect`**: Multi-factor analysis (Fishbone)\n- **`\u002Fplan-do-check-act`**: Iterative improvement cycles\n- **`\u002Fanalyse-problem`**: Comprehensive documentation (A3)\n- **`\u002Fanalyse`**: Smart method selection (Gemba\u002FVSM\u002FMuda)\n\nUse commands for structured problem-solving. Apply skill for day-to-day development.\n\n## Red Flags\n\n**Violating Continuous Improvement:**\n\n- \"I'll refactor it later\" (never happens)\n- Leaving code worse than you found it\n- Big bang rewrites instead of incremental\n\n**Violating Poka-Yoke:**\n\n- \"Users should just be careful\"\n- Validation after use instead of before\n- Optional config with no validation\n\n**Violating Standardized Work:**\n\n- \"I prefer to do it my way\"\n- Not checking existing patterns\n- Ignoring project conventions\n\n**Violating Just-In-Time:**\n\n- \"We might need this someday\"\n- Building frameworks before using them\n- Optimizing without measuring\n\n## Remember\n\n**Kaizen is about:**\n\n- Small improvements continuously\n- Preventing errors by design\n- Following proven patterns\n- Building only what's needed\n\n**Not about:**\n\n- Perfection on first try\n- Massive refactoring projects\n- Clever abstractions\n- Premature optimization\n\n**Mindset:** Good enough today, better tomorrow. Repeat.\n\n## Limitations\n- Use this skill only when the task clearly matches the scope described above.\n- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.\n- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.\n","","imported","https:\u002F\u002Fgithub.com\u002Fsickn33\u002Fantigravity-awesome-skills","user_system_seed","SkillOPIC",true,68,1215,"2026-05-16 13:24:51",{"id":8,"name":21,"slug":22,"icon":23,"description":24,"sort":25,"createdAt":26},"其他","other","mdi-page-next-outline","其他类型Skill",5,"2026-05-16 12:53:40",{"id":7,"name":28,"slug":29,"icon":30,"description":31,"moduleId":8,"sort":32,"skillCount":33,"createdAt":26},"职场发展","career","mdi-briefcase-outline","面试准备、简历优化、职业规划",4,575,[35],{"id":36,"skillId":4,"version":37,"fileName":38,"fileSize":39,"filePath":40,"fileHash":41,"manifest":42,"createdAt":19},"1e454e24-9f8e-4f8e-b00e-60fbeddfbea4","1.0.0","kaizen.zip",7001,"uploads\u002Fskills\u002F86478754-bc88-49ac-b0f8-cc424c64f8b7\u002Fkaizen.zip","2b38ff05e782aa93611458bba48a6c240f36e67eac5457640f4212563375557d","[{\"path\":\"SKILL.md\",\"isDirectory\":false,\"size\":17887}]",{"code":44,"message":45,"data":46},200,"success",{"items":47,"stats":48,"page":51},[],{"averageRating":49,"totalRatings":49,"ratingCounts":50},0,[49,49,49,49,49],{"limit":52,"offset":49,"hasMore":53,"nextOffset":52,"ratedOnly":16},15,false]