[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6R2AFVHHSMCJACN0Z9PX0D3":3,"skill-same:01M6R2AFVHHSMCJACN0Z9PX0D3":60},{"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":18,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":42,"repositoryHtmlUrl":43,"repositoryHomepageUrl":6,"ownerHtmlUrl":44,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":45,"install":46,"resources":59},"01M6R2AFVHHSMCJACN0Z9PX0D3","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.","Mishit18\u002Fclaude-code-templates","Mishit18","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F244127857?v=4","01M6QXBYKWM76HSKYDNWSKKE41","Mishit Sharma","01M6QXBYRJ0CAVM51S1RTEKTZZ",1,"MIT","https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fkaizen\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33],"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\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\n",{"name":5,"description":7},"main","015422534a7457348a313b6381f0255d3364eb8c","cli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fkaizen",0,"https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates","https:\u002F\u002Fgithub.com\u002FMishit18","2026-11-12 18:26:48",{"source":8,"skillName":5,"commands":47,"prompt":57,"zipAvailable":58},[48,51,54],{"tool":49,"command":50},"npx","npx skills add Mishit18\u002Fclaude-code-templates --skill kaizen",{"tool":52,"command":53},"bunx","bunx skills add Mishit18\u002Fclaude-code-templates --skill kaizen",{"tool":55,"command":56},"pnpm","pnpm dlx skills add Mishit18\u002Fclaude-code-templates --skill kaizen","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fkaizen\u002FSKILL.md",true,[],[61,93,119,146,172,197],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":65,"licenseFileUrl":66,"sourceHtmlUrl":67,"categories":68,"keywords":74,"publishedAt":34},"01M6R4ARN4W2VZRDERDTMN1KP0","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\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Futilities\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Futilities\u002Fweb-artifacts-builder\u002FSKILL.md",[69],{"categoryNo":70,"categoryName":71,"taxonomyType":72,"taxonomyTypeDesc":73},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",[75,76,77,78,79,80,81,82,83,84,85,86,87,88,28,89,90,91,31,92],"web artifacts builder","web","artifacts","artifacts builder","builder","frontend","css","components","react","routing","state management","state","file","Tailwind","single-file","ui components","multi","single",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":65,"licenseFileUrl":97,"sourceHtmlUrl":98,"categories":99,"keywords":104,"publishedAt":34},"01M6R45GXREM5DP8T08MAC788H","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\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fsecurity\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fsecurity\u002Fwebapp-testing\u002FSKILL.md",[100,103],{"categoryNo":101,"categoryName":102,"taxonomyType":72,"taxonomyTypeDesc":73},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":70,"categoryName":71,"taxonomyType":72,"taxonomyTypeDesc":73},[105,106,107,80,108,109,76,110,111,112,113,114,115,116,117,118,31],"testing","webapp testing","webapp","screenshots","playwright","debugging","toolkit","browser","ui","logs","applications","behavior","local","with",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":123,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":34},"01M6R2GYJ470X8EB7R58V0B68K","think-tank","Run a Virtual Think Tank — a structured multi-persona debate — before planning or making architectural\u002Fdesign\u002Fstrategic decisions. Use this skill whenever the user is about to plan a system, make a technology choice, evaluate trade-offs, decide on an approach, or faces any decision where multiple perspectives would sharpen the outcome. Also trigger when the user says \"think tank\", \"debate this\", \"perspectives on\", \"trade-offs\", \"should I use X or Y\", \"help me decide\", \"before we plan\", or asks for pros\u002Fcons of competing approaches. This skill should run BEFORE any implementation planning begins — it produces a structured analysis that feeds into better plans.","https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fthink-tank\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fthink-tank\u002FSKILL.md",[],[127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,33],"think tank","think","design","run","feeds","analysis","persona","plan","sharpen","virtual","decision","choice","decide","perspectives","outcome","me","debate","make","trade-offs",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":65,"licenseFileUrl":150,"sourceHtmlUrl":151,"categories":152,"keywords":156,"publishedAt":34},"01M6R2FSR55AVRFA9YZ8SC2GZG","skill-creator","Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.","https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fskill-creator\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fskill-creator\u002FSKILL.md",[153],{"categoryNo":154,"categoryName":155,"taxonomyType":72,"taxonomyTypeDesc":73},"01JBSEEDCAT000000000000023","Skill与智能体开发",[157,158,159,160,161,162,163,164,165,166,27,167,168,169,118,31,170,33,171],"skill creator","creator","workflows","create","update","capabilities","knowledge","tool","integrations","specialized","new skill","existing skill","users","Existing","new",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":178,"publishedAt":34},"01M6R2FK42ZZ4HJTJVVK9WJBBP","ship-learn-next","Transform learning content (like YouTube transcripts, articles, tutorials) into actionable implementation plans using the Ship-Learn-Next framework. Use when user wants to turn advice, lessons, or educational content into concrete action steps, reps, or a learning quest.","https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fproductivity\u002Fship-learn-next\u002FSKILL.md",[],[179,180,181,182,183,184,185,186,28,187,188,189,190,191,192,193,194,195,196,33],"learn","ship learn next","ship","next","framework","learning","read","write","advice","implementation","youtube","plans","quest","transform","actionable","action","lessons","youtube transcripts",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":65,"licenseFileUrl":201,"sourceHtmlUrl":202,"categories":203,"keywords":210,"publishedAt":34},"01M6R2088G1RHDA5MDX16HASRB","slack-gif-creator","Knowledge and utilities for creating animated GIFs optimized for Slack. Provides constraints, validation tools, and animation concepts. Use when users request animated GIFs for Slack like \"make me a GIF of X doing Y for Slack.\"","https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fenterprise-communication\u002Fslack-gif-creator\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fenterprise-communication\u002Fslack-gif-creator\u002FSKILL.md",[204,207],{"categoryNo":205,"categoryName":206,"taxonomyType":72,"taxonomyTypeDesc":73},"01JBSEEDCAT000000000000005","邮件与沟通",{"categoryNo":208,"categoryName":209,"taxonomyType":72,"taxonomyTypeDesc":73},"01JBSEEDCAT000000000000016","图像与多媒体",[211,212,213,158,214,215,216,217,163,28,142,169,144,218,219,31,220,33],"slack gif creator","slack","gif","validation","Tools","constraints","Animation","Utilities","concepts","request"]