[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AF6SH94KVV6A6K9BQV33F9":3,"skill-same:01M6AF6SH94KVV6A6K9BQV33F9":90},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":49,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M6AF6SH94KVV6A6K9BQV33F9","kaizen",null,"Guide for continuous improvement, error proofing, and standardization. Use this skill when the user wants to improve code quality, refactor, or discuss process improvements.","davila7\u002Fclaude-code-templates","davila7","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6216945?v=4","01M6ADEWWFPS191NFM0Y1EX1JH","Daniel Avila","01M6ADJHGM78PHQRD3XZTFDVKK",33481,"MIT","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fkaizen\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"code quality","code","refactor","continuous improvement","improve","quality","user","process","guide","use","standardization","error","for","improvement","when","2026-11-10 10:12:30",false,"---\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.\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\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","# 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\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",{"name":5,"description":7},"main","2b749c82b5d11fac39d9a6e021ce3f5b8a541bd1","cli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fkaizen",3931,"https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates","https:\u002F\u002Faitmpl.com","https:\u002F\u002Fgithub.com\u002Fdavila7","https:\u002F\u002Fdanielavila.me","Building AI dev tools with LLMs","2026-11-14 06:14:46",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add davila7\u002Fclaude-code-templates --skill kaizen",{"tool":60,"command":61},"bunx","bunx skills add davila7\u002Fclaude-code-templates --skill kaizen",{"tool":63,"command":64},"pnpm","pnpm dlx skills add davila7\u002Fclaude-code-templates --skill kaizen","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fkaizen\u002FSKILL.md",true,[68,74,78,82,86],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"agents\u002Fopenai.yaml","REFERENCE","参考文档",139,"https:\u002F\u002Fgithub.com\u002Ffderuiter\u002FQRCraftly-web\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fteach\u002Fagents\u002Fopenai.yaml",{"path":75,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002FGLOSSARY-FORMAT.md",2122,"https:\u002F\u002Fgithub.com\u002Ffderuiter\u002FQRCraftly-web\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fteach\u002Freferences\u002FGLOSSARY-FORMAT.md",{"path":79,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002FLEARNING-RECORD-FORMAT.md",2747,"https:\u002F\u002Fgithub.com\u002Ffderuiter\u002FQRCraftly-web\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fteach\u002Freferences\u002FLEARNING-RECORD-FORMAT.md",{"path":83,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002FMISSION-FORMAT.md",1540,"https:\u002F\u002Fgithub.com\u002Ffderuiter\u002FQRCraftly-web\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fteach\u002Freferences\u002FMISSION-FORMAT.md",{"path":87,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002FRESOURCES-FORMAT.md",1924,"https:\u002F\u002Fgithub.com\u002Ffderuiter\u002FQRCraftly-web\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fteach\u002Freferences\u002FRESOURCES-FORMAT.md",[91,116,142,175,210,234],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":98,"publishedAt":39},"01M70NHBTQ8BV0A2SCAZXEPHCX","wealthville-pool-scoring","Score DeFi liquidity pools before providing liquidity. Returns a 0-100 pool score and an Enter\u002FHold\u002FExit\u002FReduce\u002FAvoid verdict with calibrated confidence for ~68,800 Solana pools and 575 EVM pools, plus a public miss-inclusive track record. Use when asked whether a pool is worth LPing into, which pools look best right now, or how accurate the scores have actually been.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fweb-data\u002Fwealthville-pool-scoring\u002FSKILL.md",[97],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[99,100,101,102,103,36,104,105,33,38,106,107,108,109,110,111,112,113,114,115],"scoring","pool","wealthville pool scoring","liquidity","which","exit","now","reduce","with","record","track","verdict","evm","solana","how","public","look",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":123,"publishedAt":39},"01M70MB6VR8ERJ4EM8D5KHBMEV","technical-debt-auditor","Scans a codebase and produces a quantified technical debt report with a prioritized remediation plan. Analyzes dead code, TODO\u002FFIXME\u002FHACK markers, dependency staleness, complexity hotspots, code duplication signals, test coverage gaps, unused exports, and outdated patterns. Use this skill when the user asks to audit their codebase for tech debt, wants a health check of their code quality, says things like \"where should I focus refactoring\", \"find code smells\", \"audit my codebase\", \"what technical debt do we have\", \"prioritize cleanup work\", or asks about code quality metrics. Also trigger when the user mentions \"code rot\", \"legacy cleanup\", \"refactoring priorities\", or wants to understand the overall health of a project before a major effort. Trigger even if the user doesn't say \"technical debt\" explicitly — any request to systematically assess code quality and identify improvement priorities belongs here.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fdevelopment\u002Ftechnical-debt-auditor\u002FSKILL.md",[122],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[124,125,126,127,128,129,130,131,132,133,134,38,25,135,136,137,138,139,140,141],"technical debt","debt","technical","technical debt auditor","auditor","coverage","complexity","markers","project","cleanup","unused","todo","work","plan","focus","signals","audit","dependency",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":157,"publishedAt":39},"01M70KPYH9QNHCNME5GJQGE22K","readonly-sql-guard","Make an agent's database access provably read-only. Use when an agent runs caller-supplied SQL against a production\u002FERP\u002Fanalytics database (a \"query\" MCP tool, text-to-SQL, an admin console), or when reviewing DB-access code for write\u002FDDL\u002Fside-effect\u002Ftransaction-escape risks. Checks what a statement CALLS, not just its shape.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fdatabase\u002Freadonly-sql-guard\u002FSKILL.md",[148,151,152],{"categoryNo":149,"categoryName":150,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":153,"categoryName":154,"taxonomyType":155,"taxonomyTypeDesc":156},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[158,159,160,161,162,163,164,36,165,166,167,168,169,170,171,33,172,173,38,174],"readonly","guard","sql guard","sql","readonly sql guard","erp","effect","read-only","db","just","tool","calls","only","MCP","access","database","query",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":179,"licenseFileUrl":180,"sourceHtmlUrl":181,"categories":182,"keywords":186,"publishedAt":39},"01M6AFY6F7CC2BBZP1QD6VTNVC","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Futilities\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Futilities\u002Fweb-artifacts-builder\u002FSKILL.md",[183],{"categoryNo":184,"categoryName":185,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,36,209],"artifacts builder","web","web artifacts builder","artifacts","builder","state","routing","state management","component","css","frontend","ui","Tools","file","components","shadcn","react","Tailwind","suite","jsx","html","single-file","ui components",{"skillNo":211,"name":212,"nameZh":6,"description":213,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":179,"licenseFileUrl":214,"sourceHtmlUrl":215,"categories":216,"keywords":221,"publishedAt":39},"01M6AFWF33SFV9Z3SF4PEEE4BF","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fsecurity\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fsecurity\u002Fwebapp-testing\u002FSKILL.md",[217,220],{"categoryNo":218,"categoryName":219,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":184,"categoryName":185,"taxonomyType":21,"taxonomyTypeDesc":22},[222,223,224,225,226,188,227,197,198,228,229,230,231,36,232,107,233],"webapp testing","testing","webapp","browser","playwright","applications","debugging","toolkit","logs","screenshots","local","behavior",{"skillNo":235,"name":236,"nameZh":6,"description":237,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":179,"licenseFileUrl":238,"sourceHtmlUrl":239,"categories":240,"keywords":248,"publishedAt":39},"01M6AF67Q67JJJ5V51JR2P52KA","discernment-nudge","After you give a substantive answer or draft that the user may act on — advice or recommendations, drafted artifacts such as goals, plans, pitches, proposals, or emails, estimates or projections, analysis or interpretation of data, factual claims they may rely on, or a multi-step argument — invoke this skill BEFORE finalizing your reply and then, if it applies, append 2-3 short follow-up questions, each tied to something specific in what you just produced, that help the user check key facts, probe the reasoning or assumptions, and notice missing context. Do this at most once per conversation. Skip it when the user asked a trivial how-to or simple lookup, wants a purely educational explanation, asked you only to format, convert, or assemble a file from content they provided, is writing code they will run, is doing creative writing or casual chat, or already asked you to double-check, cite, or review — the skill file explains these boundaries and the exact output format.","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fdiscernment-nudge\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fdiscernment-nudge\u002FSKILL.md",[241,244,245],{"categoryNo":242,"categoryName":243,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":246,"categoryName":247,"taxonomyType":155,"taxonomyTypeDesc":156},"01JBSEEDCAT000000000000036","内容创作者",[249,250,251,252,253,254,255,256,190,257,200,25,258,259,260,261,262,170,263,38,264,265,266,267,268,113,269],"discernment nudge","nudge","interpretation","help","run","reasoning","data","writing","lookup","content","review","conversation","short","up","invoke","you","analysis","claims","argument","assemble","recommendations"]