[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M713VPJF2DRV6KBWMS03ET56":3,"skill-same:01M713VPJF2DRV6KBWMS03ET56":63},{"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":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":14,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":48,"install":49,"resources":62},"01M713VPJF2DRV6KBWMS03ET56","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.","sapsapshen\u002Fai-memory-router","sapsapshen","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F20347959?v=4","01M6XDQEF1DP50DKF37H81J3J5","shenmian","01M6XDQEJPE41Y3DT2763X8ZJN",0,"MIT","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fcopilot\u002Fkaizen\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"guide","2026","when","unknown","improvement","for","error","standardization","community","use","code quality","process","user","quality","improve","continuous improvement","refactor","code","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.\"\nrisk: unknown\nsource: community\ndate_added: \"2026-02-27\"\n---\n\n# Kaizen: Continuous Improvement\n\n## Overview\n\nSmall improvements, continuously. Error-proof by design. Follow what works. Build only what's needed.\n\n**Core principle:** Many small improvements beat one big change. Prevent errors at design time, not with fixes.\n\n## When to Use\n**Always applied for:**\n\n- Code implementation and refactoring\n- Architecture and design decisions\n- Process and workflow improvements\n- Error handling and validation\n\n**Philosophy:** Quality through incremental progress and prevention, not perfection through massive effort.\n\n## The Four Pillars\n\n### 1. Continuous Improvement (Kaizen)\n\nSmall, frequent improvements compound into major gains.\n\n#### Principles\n\n**Incremental over revolutionary:**\n\n- Make smallest viable change that improves quality\n- One improvement at a time\n- Verify each change before next\n- Build momentum through small wins\n\n**Always leave code better:**\n\n- Fix small issues as you encounter them\n- Refactor while you work (within scope)\n- Update outdated comments\n- Remove dead code when you see it\n\n**Iterative refinement:**\n\n- First version: make it work\n- Second pass: make it clear\n- Third pass: make it efficient\n- Don't try all three at once\n\n\u003CGood>\n```typescript\n\u002F\u002F Iteration 1: Make it work\nconst calculateTotal = (items: Item[]) => {\n  let total = 0;\n  for (let i = 0; i \u003C items.length; i++) {\n    total += items[i].price * items[i].quantity;\n  }\n  return total;\n};\n\n\u002F\u002F Iteration 2: Make it clear (refactor)\nconst calculateTotal = (items: Item[]): number => {\nreturn items.reduce((total, item) => {\nreturn total + (item.price \\* item.quantity);\n}, 0);\n};\n\n\u002F\u002F Iteration 3: Make it robust (add validation)\nconst calculateTotal = (items: Item[]): number => {\nif (!items?.length) return 0;\n\nreturn items.reduce((total, item) => {\nif (item.price \u003C 0 || item.quantity \u003C 0) {\nthrow new Error('Price and quantity must be non-negative');\n}\nreturn total + (item.price \\* item.quantity);\n}, 0);\n};\n\n````\nEach step is complete, tested, and working\n\u003C\u002FGood>\n\n\u003CBad>\n```typescript\n\u002F\u002F Trying to do everything at once\nconst calculateTotal = (items: Item[]): number => {\n  \u002F\u002F Validate, optimize, add features, handle edge cases all together\n  if (!items?.length) return 0;\n  const validItems = items.filter(item => {\n    if (item.price \u003C 0) throw new Error('Negative price');\n    if (item.quantity \u003C 0) throw new Error('Negative quantity');\n    return item.quantity > 0; \u002F\u002F Also filtering zero quantities\n  });\n  \u002F\u002F Plus caching, plus logging, plus currency conversion...\n  return validItems.reduce(...); \u002F\u002F Too many concerns at once\n};\n````\n\nOverwhelming, error-prone, hard to verify\n\u003C\u002FBad>\n\n#### In Practice\n\n**When implementing features:**\n\n1. Start with simplest version that works\n2. Add one improvement (error handling, validation, etc.)\n3. Test and verify\n4. Repeat if time permits\n5. Don't try to make it perfect immediately\n\n**When refactoring:**\n\n- Fix one smell at a time\n- Commit after each improvement\n- Keep tests passing throughout\n- Stop when \"good enough\" (diminishing returns)\n\n**When reviewing code:**\n\n- Suggest incremental improvements (not rewrites)\n- Prioritize: critical → important → nice-to-have\n- Focus on highest-impact changes first\n- Accept \"better than before\" even if not perfect\n\n### 2. Poka-Yoke (Error Proofing)\n\nDesign systems that prevent errors at compile\u002Fdesign time, not runtime.\n\n#### Principles\n\n**Make errors impossible:**\n\n- Type system catches mistakes\n- Compiler enforces contracts\n- Invalid states unrepresentable\n- Errors caught early (left of production)\n\n**Design for safety:**\n\n- Fail fast and loudly\n- Provide helpful error messages\n- Make correct path obvious\n- Make incorrect path difficult\n\n**Defense in layers:**\n\n1. Type system (compile time)\n2. Validation (runtime, early)\n3. Guards (preconditions)\n4. Error boundaries (graceful degradation)\n\n#### Type System Error Proofing\n\n\u003CGood>\n```typescript\n\u002F\u002F Error: string status can be any value\ntype OrderBad = {\n  status: string; \u002F\u002F Can be \"pending\", \"PENDING\", \"pnding\", anything!\n  total: number;\n};\n\n\u002F\u002F Good: Only valid states possible\ntype OrderStatus = 'pending' | 'processing' | 'shipped' | 'delivered';\ntype Order = {\nstatus: OrderStatus;\ntotal: number;\n};\n\n\u002F\u002F Better: States with associated data\ntype Order =\n| { status: 'pending'; createdAt: Date }\n| { status: 'processing'; startedAt: Date; estimatedCompletion: Date }\n| { status: 'shipped'; trackingNumber: string; shippedAt: Date }\n| { status: 'delivered'; deliveredAt: Date; signature: string };\n\n\u002F\u002F Now impossible to have shipped without trackingNumber\n\n````\nType system prevents entire classes of errors\n\u003C\u002FGood>\n\n\u003CGood>\n```typescript\n\u002F\u002F Make invalid states unrepresentable\ntype NonEmptyArray\u003CT> = [T, ...T[]];\n\nconst firstItem = \u003CT>(items: NonEmptyArray\u003CT>): T => {\n  return items[0]; \u002F\u002F Always safe, never undefined!\n};\n\n\u002F\u002F Caller must prove array is non-empty\nconst items: number[] = [1, 2, 3];\nif (items.length > 0) {\n  firstItem(items as NonEmptyArray\u003Cnumber>); \u002F\u002F Safe\n}\n````\n\nFunction signature guarantees safety\n\u003C\u002FGood>\n\n#### Validation Error Proofing\n\n\u003CGood>\n```typescript\n\u002F\u002F Error: Validation after use\nconst processPayment = (amount: number) => {\n  const fee = amount * 0.03; \u002F\u002F Used before validation!\n  if (amount \u003C= 0) throw new Error('Invalid amount');\n  \u002F\u002F ...\n};\n\n\u002F\u002F Good: Validate immediately\nconst processPayment = (amount: number) => {\nif (amount \u003C= 0) {\nthrow new Error('Payment amount must be positive');\n}\nif (amount > 10000) {\nthrow new Error('Payment exceeds maximum allowed');\n}\n\nconst fee = amount \\* 0.03;\n\u002F\u002F ... now safe to use\n};\n\n\u002F\u002F Better: Validation at boundary with branded type\ntype PositiveNumber = number & { readonly \\_\\_brand: 'PositiveNumber' };\n\nconst validatePositive = (n: number): PositiveNumber => {\nif (n \u003C= 0) throw new Error('Must be positive');\nreturn n as PositiveNumber;\n};\n\nconst processPayment = (amount: PositiveNumber) => {\n\u002F\u002F amount is guaranteed positive, no need to check\nconst fee = amount \\* 0.03;\n};\n\n\u002F\u002F Validate at system boundary\nconst handlePaymentRequest = (req: Request) => {\nconst amount = validatePositive(req.body.amount); \u002F\u002F Validate once\nprocessPayment(amount); \u002F\u002F Use everywhere safely\n};\n\n````\nValidate once at boundary, safe everywhere else\n\u003C\u002FGood>\n\n#### Guards and Preconditions\n\n\u003CGood>\n```typescript\n\u002F\u002F Early returns prevent deeply nested code\nconst processUser = (user: User | null) => {\n  if (!user) {\n    logger.error('User not found');\n    return;\n  }\n\n  if (!user.email) {\n    logger.error('User email missing');\n    return;\n  }\n\n  if (!user.isActive) {\n    logger.info('User inactive, skipping');\n    return;\n  }\n\n  \u002F\u002F Main logic here, guaranteed user is valid and active\n  sendEmail(user.email, 'Welcome!');\n};\n````\n\nGuards make assumptions explicit and enforced\n\u003C\u002FGood>\n\n#### Configuration Error Proofing\n\n\u003CGood>\n```typescript\n\u002F\u002F Error: Optional config with unsafe defaults\ntype ConfigBad = {\n  apiKey?: string;\n  timeout?: number;\n};\n\nconst client = new APIClient({ timeout: 5000 }); \u002F\u002F apiKey missing!\n\n\u002F\u002F Good: Required config, fails early\ntype Config = {\napiKey: string;\ntimeout: number;\n};\n\nconst loadConfig = (): Config => {\nconst apiKey = process.env.API_KEY;\nif (!apiKey) {\nthrow new Error('API_KEY environment variable required');\n}\n\nreturn {\napiKey,\ntimeout: 5000,\n};\n};\n\n\u002F\u002F App fails at startup if config invalid, not during request\nconst config = loadConfig();\nconst client = new APIClient(config);\n\n````\nFail at startup, not in production\n\u003C\u002FGood>\n\n#### In Practice\n\n**When designing APIs:**\n- Use types to constrain inputs\n- Make invalid states unrepresentable\n- Return Result\u003CT, E> instead of throwing\n- Document preconditions in types\n\n**When handling errors:**\n- Validate at system boundaries\n\n- Use guards for preconditions\n- Fail fast with clear messages\n- Log context for debugging\n\n**When configuring:**\n- Required over optional with defaults\n- Validate all config at startup\n- Fail deployment if config invalid\n- Don't allow partial configurations\n\n### 3. Standardized Work\nFollow established patterns. Document what works. Make good practices easy to follow.\n\n#### Principles\n\n**Consistency over cleverness:**\n- Follow existing codebase patterns\n- Don't reinvent solved problems\n- New pattern only if significantly better\n- Team agreement on new patterns\n\n**Documentation lives with code:**\n- README for setup and architecture\n- CLAUDE.md for AI coding conventions\n- Comments for \"why\", not \"what\"\n- Examples for complex patterns\n\n**Automate standards:**\n- Linters enforce style\n- Type checks enforce contracts\n- Tests verify behavior\n- CI\u002FCD enforces quality gates\n\n#### Following Patterns\n\n\u003CGood>\n```typescript\n\u002F\u002F Existing codebase pattern for API clients\nclass UserAPIClient {\n  async getUser(id: string): Promise\u003CUser> {\n    return this.fetch(`\u002Fusers\u002F${id}`);\n  }\n}\n\n\u002F\u002F New code follows the same pattern\nclass OrderAPIClient {\n  async getOrder(id: string): Promise\u003COrder> {\n    return this.fetch(`\u002Forders\u002F${id}`);\n  }\n}\n````\n\nConsistency makes codebase predictable\n\u003C\u002FGood>\n\n\u003CBad>\n```typescript\n\u002F\u002F Existing pattern uses classes\nclass UserAPIClient { \u002F* ... *\u002F }\n\n\u002F\u002F New code introduces different pattern without discussion\nconst getOrder = async (id: string): Promise\u003COrder> => {\n\u002F\u002F Breaking consistency \"because I prefer functions\"\n};\n\n````\nInconsistency creates confusion\n\u003C\u002FBad>\n\n#### Error Handling Patterns\n\n\u003CGood>\n```typescript\n\u002F\u002F Project standard: Result type for recoverable errors\ntype Result\u003CT, E> = { ok: true; value: T } | { ok: false; error: E };\n\n\u002F\u002F All services follow this pattern\nconst fetchUser = async (id: string): Promise\u003CResult\u003CUser, Error>> => {\n  try {\n    const user = await db.users.findById(id);\n    if (!user) {\n      return { ok: false, error: new Error('User not found') };\n    }\n    return { ok: true, value: user };\n  } catch (err) {\n    return { ok: false, error: err as Error };\n  }\n};\n\n\u002F\u002F Callers use consistent pattern\nconst result = await fetchUser('123');\nif (!result.ok) {\n  logger.error('Failed to fetch user', result.error);\n  return;\n}\nconst user = result.value; \u002F\u002F Type-safe!\n````\n\nStandard pattern across codebase\n\u003C\u002FGood>\n\n#### Documentation Standards\n\n\u003CGood>\n```typescript\n\u002F**\n * Retries an async operation with exponential backoff.\n *\n * Why: Network requests fail temporarily; retrying improves reliability\n * When to use: External API calls, database operations\n * When not to use: User input validation, internal function calls\n *\n * @example\n * const result = await retry(\n *   () => fetch('https:\u002F\u002Fapi.example.com\u002Fdata'),\n *   { maxAttempts: 3, baseDelay: 1000 }\n * );\n *\u002F\nconst retry = async \u003CT>(\n  operation: () => Promise\u003CT>,\n  options: RetryOptions\n): Promise\u003CT> => {\n  \u002F\u002F Implementation...\n};\n```\nDocuments why, when, and how\n\u003C\u002FGood>\n\n#### In Practice\n\n**Before adding new patterns:**\n\n- Search codebase for similar problems solved\n- Check CLAUDE.md for project conventions\n- Discuss with team if breaking from pattern\n- Update docs when introducing new pattern\n\n**When writing code:**\n\n- Match existing file structure\n- Use same naming conventions\n- Follow same error handling approach\n- Import from same locations\n\n**When reviewing:**\n\n- Check consistency with existing code\n- Point to examples in codebase\n- Suggest aligning with standards\n- Update CLAUDE.md if new standard emerges\n\n### 4. Just-In-Time (JIT)\n\nBuild what's needed now. No more, no less. Avoid premature optimization and over-engineering.\n\n#### Principles\n\n**YAGNI (You Aren't Gonna Need It):**\n\n- Implement only current requirements\n- No \"just in case\" features\n- No \"we might need this later\" code\n- Delete speculation\n\n**Simplest thing that works:**\n\n- Start with straightforward solution\n- Add complexity only when needed\n- Refactor when requirements change\n- Don't anticipate future needs\n\n**Optimize when measured:**\n\n- No premature optimization\n- Profile before optimizing\n- Measure impact of changes\n- Accept \"good enough\" performance\n\n#### YAGNI in Action\n\n\u003CGood>\n```typescript\n\u002F\u002F Current requirement: Log errors to console\nconst logError = (error: Error) => {\n  console.error(error.message);\n};\n```\nSimple, meets current need\n\u003C\u002FGood>\n\n\u003CBad>\n```typescript\n\u002F\u002F Over-engineered for \"future needs\"\ninterface LogTransport {\n  write(level: LogLevel, message: string, meta?: LogMetadata): Promise\u003Cvoid>;\n}\n\nclass ConsoleTransport implements LogTransport { \u002F_... _\u002F }\nclass FileTransport implements LogTransport { \u002F_ ... _\u002F }\nclass RemoteTransport implements LogTransport { \u002F_ ..._\u002F }\n\nclass Logger {\nprivate transports: LogTransport[] = [];\nprivate queue: LogEntry[] = [];\nprivate rateLimiter: RateLimiter;\nprivate formatter: LogFormatter;\n\n\u002F\u002F 200 lines of code for \"maybe we'll need it\"\n}\n\nconst logError = (error: Error) => {\nLogger.getInstance().log('error', error.message);\n};\n\n````\nBuilding for imaginary future requirements\n\u003C\u002FBad>\n\n**When to add complexity:**\n- Current requirement demands it\n- Pain points identified through use\n- Measured performance issues\n- Multiple use cases emerged\n\n\u003CGood>\n```typescript\n\u002F\u002F Start simple\nconst formatCurrency = (amount: number): string => {\n  return `$${amount.toFixed(2)}`;\n};\n\n\u002F\u002F Requirement evolves: support multiple currencies\nconst formatCurrency = (amount: number, currency: string): string => {\n  const symbols = { USD: '$', EUR: '€', GBP: '£' };\n  return `${symbols[currency]}${amount.toFixed(2)}`;\n};\n\n\u002F\u002F Requirement evolves: support localization\nconst formatCurrency = (amount: number, locale: string): string => {\n  return new Intl.NumberFormat(locale, {\\n    style: 'currency',\n    currency: locale === 'en-US' ? 'USD' : 'EUR',\n  }).format(amount);\n};\n````\n\nComplexity added only when needed\n\u003C\u002FGood>\n\n#### Premature Abstraction\n\n\u003CBad>\n```typescript\n\u002F\u002F One use case, but building generic framework\nabstract class BaseCRUDService\u003CT> {\n  abstract getAll(): Promise\u003CT[]>;\n  abstract getById(id: string): Promise\u003CT>;\n  abstract create(data: Partial\u003CT>): Promise\u003CT>;\n  abstract update(id: string, data: Partial\u003CT>): Promise\u003CT>;\n  abstract delete(id: string): Promise\u003Cvoid>;\n}\n\nclass GenericRepository\u003CT> { \u002F_300 lines _\u002F }\nclass QueryBuilder\u003CT> { \u002F_ 200 lines_\u002F }\n\u002F\u002F ... building entire ORM for single table\n\n````\nMassive abstraction for uncertain future\n\u003C\u002FBad>\n\n\u003CGood>\n```typescript\n\u002F\u002F Simple functions for current needs\nconst getUsers = async (): Promise\u003CUser[]> => {\n  return db.query('SELECT * FROM users');\n};\n\nconst getUserById = async (id: string): Promise\u003CUser | null> => {\n  return db.query('SELECT * FROM users WHERE id = $1', [id]);\n};\n\n\u002F\u002F When pattern emerges across multiple entities, then abstract\n````\n\nAbstract only when pattern proven across 3+ cases\n\u003C\u002FGood>\n\n#### Performance Optimization\n\n\u003CGood>\n```typescript\n\u002F\u002F Current: Simple approach\nconst filterActiveUsers = (users: User[]): User[] => {\n  return users.filter(user => user.isActive);\n};\n\n\u002F\u002F Benchmark shows: 50ms for 1000 users (acceptable)\n\u002F\u002F ✓ Ship it, no optimization needed\n\n\u002F\u002F Later: After profiling shows this is bottleneck\n\u002F\u002F Then optimize with indexed lookup or caching\n\n````\nOptimize based on measurement, not assumptions\n\u003C\u002FGood>\n\n\u003CBad>\n```typescript\n\u002F\u002F Premature optimization\nconst filterActiveUsers = (users: User[]): User[] => {\n  \u002F\u002F \"This might be slow, so let's cache and index\"\n  const cache = new WeakMap();\n  const indexed = buildBTreeIndex(users, 'isActive');\n  \u002F\u002F 100 lines of optimization code\n  \u002F\u002F Adds complexity, harder to maintain\n  \u002F\u002F No evidence it was needed\n};\\\n````\n\nComplex solution for unmeasured problem\n\u003C\u002FBad>\n\n#### In Practice\n\n**When implementing:**\n\n- Solve the immediate problem\n- Use straightforward approach\n- Resist \"what if\" thinking\n- Delete speculative code\n\n**When optimizing:**\n\n- Profile first, optimize second\n- Measure before and after\n- Document why optimization needed\n- Keep simple version in tests\n\n**When abstracting:**\n\n- Wait for 3+ similar cases (Rule of Three)\n- Make abstraction as simple as possible\n- Prefer duplication over wrong abstraction\n- Refactor when pattern clear\n\n## Integration with Commands\n\nThe Kaizen skill guides how you work. The commands provide structured analysis:\n\n- **`\u002Fwhy`**: Root cause analysis (5 Whys)\n- **`\u002Fcause-and-effect`**: Multi-factor analysis (Fishbone)\n- **`\u002Fplan-do-check-act`**: Iterative improvement cycles\n- **`\u002Fanalyse-problem`**: Comprehensive documentation (A3)\n- **`\u002Fanalyse`**: Smart method selection (Gemba\u002FVSM\u002FMuda)\n\nUse commands for structured problem-solving. Apply skill for day-to-day development.\n\n## Red Flags\n\n**Violating Continuous Improvement:**\n\n- \"I'll refactor it later\" (never happens)\n- Leaving code worse than you found it\n- Big bang rewrites instead of incremental\n\n**Violating Poka-Yoke:**\n\n- \"Users should just be careful\"\n- Validation after use instead of before\n- Optional config with no validation\n\n**Violating Standardized Work:**\n\n- \"I prefer to do it my way\"\n- Not checking existing patterns\n- Ignoring project conventions\n\n**Violating Just-In-Time:**\n\n- \"We might need this someday\"\n- Building frameworks before using them\n- Optimizing without measuring\n\n## Remember\n\n**Kaizen is about:**\n\n- Small improvements continuously\n- Preventing errors by design\n- Following proven patterns\n- Building only what's needed\n\n**Not about:**\n\n- Perfection on first try\n- Massive refactoring projects\n- Clever abstractions\n- Premature optimization\n\n**Mindset:** Good enough today, better tomorrow. Repeat.\n","# Kaizen: Continuous Improvement\n\n## Overview\n\nSmall improvements, continuously. Error-proof by design. Follow what works. Build only what's needed.\n\n**Core principle:** Many small improvements beat one big change. Prevent errors at design time, not with fixes.\n\n## When to Use\n**Always applied for:**\n\n- Code implementation and refactoring\n- Architecture and design decisions\n- Process and workflow improvements\n- Error handling and validation\n\n**Philosophy:** Quality through incremental progress and prevention, not perfection through massive effort.\n\n## The Four Pillars\n\n### 1. Continuous Improvement (Kaizen)\n\nSmall, frequent improvements compound into major gains.\n\n#### Principles\n\n**Incremental over revolutionary:**\n\n- Make smallest viable change that improves quality\n- One improvement at a time\n- Verify each change before next\n- Build momentum through small wins\n\n**Always leave code better:**\n\n- Fix small issues as you encounter them\n- Refactor while you work (within scope)\n- Update outdated comments\n- Remove dead code when you see it\n\n**Iterative refinement:**\n\n- First version: make it work\n- Second pass: make it clear\n- Third pass: make it efficient\n- Don't try all three at once\n\n\u003CGood>\n```typescript\n\u002F\u002F Iteration 1: Make it work\nconst calculateTotal = (items: Item[]) => {\n  let total = 0;\n  for (let i = 0; i \u003C items.length; i++) {\n    total += items[i].price * items[i].quantity;\n  }\n  return total;\n};\n\n\u002F\u002F Iteration 2: Make it clear (refactor)\nconst calculateTotal = (items: Item[]): number => {\nreturn items.reduce((total, item) => {\nreturn total + (item.price \\* item.quantity);\n}, 0);\n};\n\n\u002F\u002F Iteration 3: Make it robust (add validation)\nconst calculateTotal = (items: Item[]): number => {\nif (!items?.length) return 0;\n\nreturn items.reduce((total, item) => {\nif (item.price \u003C 0 || item.quantity \u003C 0) {\nthrow new Error('Price and quantity must be non-negative');\n}\nreturn total + (item.price \\* item.quantity);\n}, 0);\n};\n\n````\nEach step is complete, tested, and working\n\u003C\u002FGood>\n\n\u003CBad>\n```typescript\n\u002F\u002F Trying to do everything at once\nconst calculateTotal = (items: Item[]): number => {\n  \u002F\u002F Validate, optimize, add features, handle edge cases all together\n  if (!items?.length) return 0;\n  const validItems = items.filter(item => {\n    if (item.price \u003C 0) throw new Error('Negative price');\n    if (item.quantity \u003C 0) throw new Error('Negative quantity');\n    return item.quantity > 0; \u002F\u002F Also filtering zero quantities\n  });\n  \u002F\u002F Plus caching, plus logging, plus currency conversion...\n  return validItems.reduce(...); \u002F\u002F Too many concerns at once\n};\n````\n\nOverwhelming, error-prone, hard to verify\n\u003C\u002FBad>\n\n#### In Practice\n\n**When implementing features:**\n\n1. Start with simplest version that works\n2. Add one improvement (error handling, validation, etc.)\n3. Test and verify\n4. Repeat if time permits\n5. Don't try to make it perfect immediately\n\n**When refactoring:**\n\n- Fix one smell at a time\n- Commit after each improvement\n- Keep tests passing throughout\n- Stop when \"good enough\" (diminishing returns)\n\n**When reviewing code:**\n\n- Suggest incremental improvements (not rewrites)\n- Prioritize: critical → important → nice-to-have\n- Focus on highest-impact changes first\n- Accept \"better than before\" even if not perfect\n\n### 2. Poka-Yoke (Error Proofing)\n\nDesign systems that prevent errors at compile\u002Fdesign time, not runtime.\n\n#### Principles\n\n**Make errors impossible:**\n\n- Type system catches mistakes\n- Compiler enforces contracts\n- Invalid states unrepresentable\n- Errors caught early (left of production)\n\n**Design for safety:**\n\n- Fail fast and loudly\n- Provide helpful error messages\n- Make correct path obvious\n- Make incorrect path difficult\n\n**Defense in layers:**\n\n1. Type system (compile time)\n2. Validation (runtime, early)\n3. Guards (preconditions)\n4. Error boundaries (graceful degradation)\n\n#### Type System Error Proofing\n\n\u003CGood>\n```typescript\n\u002F\u002F Error: string status can be any value\ntype OrderBad = {\n  status: string; \u002F\u002F Can be \"pending\", \"PENDING\", \"pnding\", anything!\n  total: number;\n};\n\n\u002F\u002F Good: Only valid states possible\ntype OrderStatus = 'pending' | 'processing' | 'shipped' | 'delivered';\ntype Order = {\nstatus: OrderStatus;\ntotal: number;\n};\n\n\u002F\u002F Better: States with associated data\ntype Order =\n| { status: 'pending'; createdAt: Date }\n| { status: 'processing'; startedAt: Date; estimatedCompletion: Date }\n| { status: 'shipped'; trackingNumber: string; shippedAt: Date }\n| { status: 'delivered'; deliveredAt: Date; signature: string };\n\n\u002F\u002F Now impossible to have shipped without trackingNumber\n\n````\nType system prevents entire classes of errors\n\u003C\u002FGood>\n\n\u003CGood>\n```typescript\n\u002F\u002F Make invalid states unrepresentable\ntype NonEmptyArray\u003CT> = [T, ...T[]];\n\nconst firstItem = \u003CT>(items: NonEmptyArray\u003CT>): T => {\n  return items[0]; \u002F\u002F Always safe, never undefined!\n};\n\n\u002F\u002F Caller must prove array is non-empty\nconst items: number[] = [1, 2, 3];\nif (items.length > 0) {\n  firstItem(items as NonEmptyArray\u003Cnumber>); \u002F\u002F Safe\n}\n````\n\nFunction signature guarantees safety\n\u003C\u002FGood>\n\n#### Validation Error Proofing\n\n\u003CGood>\n```typescript\n\u002F\u002F Error: Validation after use\nconst processPayment = (amount: number) => {\n  const fee = amount * 0.03; \u002F\u002F Used before validation!\n  if (amount \u003C= 0) throw new Error('Invalid amount');\n  \u002F\u002F ...\n};\n\n\u002F\u002F Good: Validate immediately\nconst processPayment = (amount: number) => {\nif (amount \u003C= 0) {\nthrow new Error('Payment amount must be positive');\n}\nif (amount > 10000) {\nthrow new Error('Payment exceeds maximum allowed');\n}\n\nconst fee = amount \\* 0.03;\n\u002F\u002F ... now safe to use\n};\n\n\u002F\u002F Better: Validation at boundary with branded type\ntype PositiveNumber = number & { readonly \\_\\_brand: 'PositiveNumber' };\n\nconst validatePositive = (n: number): PositiveNumber => {\nif (n \u003C= 0) throw new Error('Must be positive');\nreturn n as PositiveNumber;\n};\n\nconst processPayment = (amount: PositiveNumber) => {\n\u002F\u002F amount is guaranteed positive, no need to check\nconst fee = amount \\* 0.03;\n};\n\n\u002F\u002F Validate at system boundary\nconst handlePaymentRequest = (req: Request) => {\nconst amount = validatePositive(req.body.amount); \u002F\u002F Validate once\nprocessPayment(amount); \u002F\u002F Use everywhere safely\n};\n\n````\nValidate once at boundary, safe everywhere else\n\u003C\u002FGood>\n\n#### Guards and Preconditions\n\n\u003CGood>\n```typescript\n\u002F\u002F Early returns prevent deeply nested code\nconst processUser = (user: User | null) => {\n  if (!user) {\n    logger.error('User not found');\n    return;\n  }\n\n  if (!user.email) {\n    logger.error('User email missing');\n    return;\n  }\n\n  if (!user.isActive) {\n    logger.info('User inactive, skipping');\n    return;\n  }\n\n  \u002F\u002F Main logic here, guaranteed user is valid and active\n  sendEmail(user.email, 'Welcome!');\n};\n````\n\nGuards make assumptions explicit and enforced\n\u003C\u002FGood>\n\n#### Configuration Error Proofing\n\n\u003CGood>\n```typescript\n\u002F\u002F Error: Optional config with unsafe defaults\ntype ConfigBad = {\n  apiKey?: string;\n  timeout?: number;\n};\n\nconst client = new APIClient({ timeout: 5000 }); \u002F\u002F apiKey missing!\n\n\u002F\u002F Good: Required config, fails early\ntype Config = {\napiKey: string;\ntimeout: number;\n};\n\nconst loadConfig = (): Config => {\nconst apiKey = process.env.API_KEY;\nif (!apiKey) {\nthrow new Error('API_KEY environment variable required');\n}\n\nreturn {\napiKey,\ntimeout: 5000,\n};\n};\n\n\u002F\u002F App fails at startup if config invalid, not during request\nconst config = loadConfig();\nconst client = new APIClient(config);\n\n````\nFail at startup, not in production\n\u003C\u002FGood>\n\n#### In Practice\n\n**When designing APIs:**\n- Use types to constrain inputs\n- Make invalid states unrepresentable\n- Return Result\u003CT, E> instead of throwing\n- Document preconditions in types\n\n**When handling errors:**\n- Validate at system boundaries\n\n- Use guards for preconditions\n- Fail fast with clear messages\n- Log context for debugging\n\n**When configuring:**\n- Required over optional with defaults\n- Validate all config at startup\n- Fail deployment if config invalid\n- Don't allow partial configurations\n\n### 3. Standardized Work\nFollow established patterns. Document what works. Make good practices easy to follow.\n\n#### Principles\n\n**Consistency over cleverness:**\n- Follow existing codebase patterns\n- Don't reinvent solved problems\n- New pattern only if significantly better\n- Team agreement on new patterns\n\n**Documentation lives with code:**\n- README for setup and architecture\n- CLAUDE.md for AI coding conventions\n- Comments for \"why\", not \"what\"\n- Examples for complex patterns\n\n**Automate standards:**\n- Linters enforce style\n- Type checks enforce contracts\n- Tests verify behavior\n- CI\u002FCD enforces quality gates\n\n#### Following Patterns\n\n\u003CGood>\n```typescript\n\u002F\u002F Existing codebase pattern for API clients\nclass UserAPIClient {\n  async getUser(id: string): Promise\u003CUser> {\n    return this.fetch(`\u002Fusers\u002F${id}`);\n  }\n}\n\n\u002F\u002F New code follows the same pattern\nclass OrderAPIClient {\n  async getOrder(id: string): Promise\u003COrder> {\n    return this.fetch(`\u002Forders\u002F${id}`);\n  }\n}\n````\n\nConsistency makes codebase predictable\n\u003C\u002FGood>\n\n\u003CBad>\n```typescript\n\u002F\u002F Existing pattern uses classes\nclass UserAPIClient { \u002F* ... *\u002F }\n\n\u002F\u002F New code introduces different pattern without discussion\nconst getOrder = async (id: string): Promise\u003COrder> => {\n\u002F\u002F Breaking consistency \"because I prefer functions\"\n};\n\n````\nInconsistency creates confusion\n\u003C\u002FBad>\n\n#### Error Handling Patterns\n\n\u003CGood>\n```typescript\n\u002F\u002F Project standard: Result type for recoverable errors\ntype Result\u003CT, E> = { ok: true; value: T } | { ok: false; error: E };\n\n\u002F\u002F All services follow this pattern\nconst fetchUser = async (id: string): Promise\u003CResult\u003CUser, Error>> => {\n  try {\n    const user = await db.users.findById(id);\n    if (!user) {\n      return { ok: false, error: new Error('User not found') };\n    }\n    return { ok: true, value: user };\n  } catch (err) {\n    return { ok: false, error: err as Error };\n  }\n};\n\n\u002F\u002F Callers use consistent pattern\nconst result = await fetchUser('123');\nif (!result.ok) {\n  logger.error('Failed to fetch user', result.error);\n  return;\n}\nconst user = result.value; \u002F\u002F Type-safe!\n````\n\nStandard pattern across codebase\n\u003C\u002FGood>\n\n#### Documentation Standards\n\n\u003CGood>\n```typescript\n\u002F**\n * Retries an async operation with exponential backoff.\n *\n * Why: Network requests fail temporarily; retrying improves reliability\n * When to use: External API calls, database operations\n * When not to use: User input validation, internal function calls\n *\n * @example\n * const result = await retry(\n *   () => fetch('https:\u002F\u002Fapi.example.com\u002Fdata'),\n *   { maxAttempts: 3, baseDelay: 1000 }\n * );\n *\u002F\nconst retry = async \u003CT>(\n  operation: () => Promise\u003CT>,\n  options: RetryOptions\n): Promise\u003CT> => {\n  \u002F\u002F Implementation...\n};\n```\nDocuments why, when, and how\n\u003C\u002FGood>\n\n#### In Practice\n\n**Before adding new patterns:**\n\n- Search codebase for similar problems solved\n- Check CLAUDE.md for project conventions\n- Discuss with team if breaking from pattern\n- Update docs when introducing new pattern\n\n**When writing code:**\n\n- Match existing file structure\n- Use same naming conventions\n- Follow same error handling approach\n- Import from same locations\n\n**When reviewing:**\n\n- Check consistency with existing code\n- Point to examples in codebase\n- Suggest aligning with standards\n- Update CLAUDE.md if new standard emerges\n\n### 4. Just-In-Time (JIT)\n\nBuild what's needed now. No more, no less. Avoid premature optimization and over-engineering.\n\n#### Principles\n\n**YAGNI (You Aren't Gonna Need It):**\n\n- Implement only current requirements\n- No \"just in case\" features\n- No \"we might need this later\" code\n- Delete speculation\n\n**Simplest thing that works:**\n\n- Start with straightforward solution\n- Add complexity only when needed\n- Refactor when requirements change\n- Don't anticipate future needs\n\n**Optimize when measured:**\n\n- No premature optimization\n- Profile before optimizing\n- Measure impact of changes\n- Accept \"good enough\" performance\n\n#### YAGNI in Action\n\n\u003CGood>\n```typescript\n\u002F\u002F Current requirement: Log errors to console\nconst logError = (error: Error) => {\n  console.error(error.message);\n};\n```\nSimple, meets current need\n\u003C\u002FGood>\n\n\u003CBad>\n```typescript\n\u002F\u002F Over-engineered for \"future needs\"\ninterface LogTransport {\n  write(level: LogLevel, message: string, meta?: LogMetadata): Promise\u003Cvoid>;\n}\n\nclass ConsoleTransport implements LogTransport { \u002F_... _\u002F }\nclass FileTransport implements LogTransport { \u002F_ ... _\u002F }\nclass RemoteTransport implements LogTransport { \u002F_ ..._\u002F }\n\nclass Logger {\nprivate transports: LogTransport[] = [];\nprivate queue: LogEntry[] = [];\nprivate rateLimiter: RateLimiter;\nprivate formatter: LogFormatter;\n\n\u002F\u002F 200 lines of code for \"maybe we'll need it\"\n}\n\nconst logError = (error: Error) => {\nLogger.getInstance().log('error', error.message);\n};\n\n````\nBuilding for imaginary future requirements\n\u003C\u002FBad>\n\n**When to add complexity:**\n- Current requirement demands it\n- Pain points identified through use\n- Measured performance issues\n- Multiple use cases emerged\n\n\u003CGood>\n```typescript\n\u002F\u002F Start simple\nconst formatCurrency = (amount: number): string => {\n  return `$${amount.toFixed(2)}`;\n};\n\n\u002F\u002F Requirement evolves: support multiple currencies\nconst formatCurrency = (amount: number, currency: string): string => {\n  const symbols = { USD: '$', EUR: '€', GBP: '£' };\n  return `${symbols[currency]}${amount.toFixed(2)}`;\n};\n\n\u002F\u002F Requirement evolves: support localization\nconst formatCurrency = (amount: number, locale: string): string => {\n  return new Intl.NumberFormat(locale, {\\n    style: 'currency',\n    currency: locale === 'en-US' ? 'USD' : 'EUR',\n  }).format(amount);\n};\n````\n\nComplexity added only when needed\n\u003C\u002FGood>\n\n#### Premature Abstraction\n\n\u003CBad>\n```typescript\n\u002F\u002F One use case, but building generic framework\nabstract class BaseCRUDService\u003CT> {\n  abstract getAll(): Promise\u003CT[]>;\n  abstract getById(id: string): Promise\u003CT>;\n  abstract create(data: Partial\u003CT>): Promise\u003CT>;\n  abstract update(id: string, data: Partial\u003CT>): Promise\u003CT>;\n  abstract delete(id: string): Promise\u003Cvoid>;\n}\n\nclass GenericRepository\u003CT> { \u002F_300 lines _\u002F }\nclass QueryBuilder\u003CT> { \u002F_ 200 lines_\u002F }\n\u002F\u002F ... building entire ORM for single table\n\n````\nMassive abstraction for uncertain future\n\u003C\u002FBad>\n\n\u003CGood>\n```typescript\n\u002F\u002F Simple functions for current needs\nconst getUsers = async (): Promise\u003CUser[]> => {\n  return db.query('SELECT * FROM users');\n};\n\nconst getUserById = async (id: string): Promise\u003CUser | null> => {\n  return db.query('SELECT * FROM users WHERE id = $1', [id]);\n};\n\n\u002F\u002F When pattern emerges across multiple entities, then abstract\n````\n\nAbstract only when pattern proven across 3+ cases\n\u003C\u002FGood>\n\n#### Performance Optimization\n\n\u003CGood>\n```typescript\n\u002F\u002F Current: Simple approach\nconst filterActiveUsers = (users: User[]): User[] => {\n  return users.filter(user => user.isActive);\n};\n\n\u002F\u002F Benchmark shows: 50ms for 1000 users (acceptable)\n\u002F\u002F ✓ Ship it, no optimization needed\n\n\u002F\u002F Later: After profiling shows this is bottleneck\n\u002F\u002F Then optimize with indexed lookup or caching\n\n````\nOptimize based on measurement, not assumptions\n\u003C\u002FGood>\n\n\u003CBad>\n```typescript\n\u002F\u002F Premature optimization\nconst filterActiveUsers = (users: User[]): User[] => {\n  \u002F\u002F \"This might be slow, so let's cache and index\"\n  const cache = new WeakMap();\n  const indexed = buildBTreeIndex(users, 'isActive');\n  \u002F\u002F 100 lines of optimization code\n  \u002F\u002F Adds complexity, harder to maintain\n  \u002F\u002F No evidence it was needed\n};\\\n````\n\nComplex solution for unmeasured problem\n\u003C\u002FBad>\n\n#### In Practice\n\n**When implementing:**\n\n- Solve the immediate problem\n- Use straightforward approach\n- Resist \"what if\" thinking\n- Delete speculative code\n\n**When optimizing:**\n\n- Profile first, optimize second\n- Measure before and after\n- Document why optimization needed\n- Keep simple version in tests\n\n**When abstracting:**\n\n- Wait for 3+ similar cases (Rule of Three)\n- Make abstraction as simple as possible\n- Prefer duplication over wrong abstraction\n- Refactor when pattern clear\n\n## Integration with Commands\n\nThe Kaizen skill guides how you work. The commands provide structured analysis:\n\n- **`\u002Fwhy`**: Root cause analysis (5 Whys)\n- **`\u002Fcause-and-effect`**: Multi-factor analysis (Fishbone)\n- **`\u002Fplan-do-check-act`**: Iterative improvement cycles\n- **`\u002Fanalyse-problem`**: Comprehensive documentation (A3)\n- **`\u002Fanalyse`**: Smart method selection (Gemba\u002FVSM\u002FMuda)\n\nUse commands for structured problem-solving. Apply skill for day-to-day development.\n\n## Red Flags\n\n**Violating Continuous Improvement:**\n\n- \"I'll refactor it later\" (never happens)\n- Leaving code worse than you found it\n- Big bang rewrites instead of incremental\n\n**Violating Poka-Yoke:**\n\n- \"Users should just be careful\"\n- Validation after use instead of before\n- Optional config with no validation\n\n**Violating Standardized Work:**\n\n- \"I prefer to do it my way\"\n- Not checking existing patterns\n- Ignoring project conventions\n\n**Violating Just-In-Time:**\n\n- \"We might need this someday\"\n- Building frameworks before using them\n- Optimizing without measuring\n\n## Remember\n\n**Kaizen is about:**\n\n- Small improvements continuously\n- Preventing errors by design\n- Following proven patterns\n- Building only what's needed\n\n**Not about:**\n\n- Perfection on first try\n- Massive refactoring projects\n- Clever abstractions\n- Premature optimization\n\n**Mindset:** Good enough today, better tomorrow. Repeat.\n",{"name":5,"risk":22,"source":27,"date_added":42,"description":7},"2026-02-27","main","7a38d8e7073e61c16eda85681cb32fb68a8657a5","skills-store\u002Fcopilot\u002Fkaizen","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router","https:\u002F\u002Fgithub.com\u002Fsapsapshen","2026-04-14 21:12:12",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":61},[51,54,57],{"tool":52,"command":53},"npx","npx skills add sapsapshen\u002Fai-memory-router --skill kaizen",{"tool":55,"command":56},"bunx","bunx skills add sapsapshen\u002Fai-memory-router --skill kaizen",{"tool":58,"command":59},"pnpm","pnpm dlx skills add sapsapshen\u002Fai-memory-router --skill kaizen","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fcopilot\u002Fkaizen\u002FSKILL.md",true,[],[64,88,113,123,136,155],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":75,"publishedAt":37},"01M71ATQRKG48SH06FQ697T5G9","wechat-search","Search WeChat Official Account articles using OpenClaw's web search and fetch capabilities with compliance-focused design.","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Fwechat-search-release\u002FSKILL.md",[70],{"categoryNo":71,"categoryName":72,"taxonomyType":73,"taxonomyTypeDesc":74},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[76,77,78,79,80,81,82,83,84,85,86,87],"wechat search","wechat","search","capabilities","openclaw","design","web search","compliance","web","official","fetch","with",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":37},"01M71ATNAVGZB35PFYM2GC5N00","trend-tap","Real-time trending topics aggregator across 7 platforms (X\u002FTwitter, Reddit, Google Trends, Hacker News, Zhihu, Bilibili, Weibo). Trigger: when user says 'trend', 'trends', 'trend tap', '热点', '热搜', or asks what is trending\u002Fhot. Do NOT use web_search — this skill already fetches live data from all platforms with zero API keys.","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Ftrend-tap\u002FSKILL.md",[],[95,96,97,98,99,100,78,101,102,103,104,21,105,106,107,108,109,110,111,112],"trend","trend tap","tap","api keys","Bash","time","trending","hacker","aggregator","do","brew","live","data","google","install","read","across","api",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":37},"01M71ATJ9AM5KM15AA8PS302EB","trend-radar","Real-time trending topics aggregator across 7 platforms (X\u002FTwitter, Reddit, Google Trends, Hacker News, Zhihu, Bilibili, Weibo). Trigger: when user says 'trend', 'trends', 'trend pulse', '热点', '热搜', or asks what is trending\u002Fhot. Do NOT use web_search — this skill already fetches live data from all platforms with zero API keys.","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Ftrend-radar\u002FSKILL.md",[],[120,121,95,105,106,107,108,99,78,110,122,111,112,21,103,102,101,109,100,98],"trend radar","radar","pulse",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":37},"01M71ATGF095N3EJM9G8SD0BB5","tech-news-daily","每日科技新闻汇——从全球多个 RSS 源抓取最新科技新闻，翻译（英→中）、去重、排版成每日简报。当用户询问科技新闻、科技新鲜事、每日科技、技术动态、Daily Tech News 或类似表达时触发此技能。","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Ftech-news-daily\u002FSKILL.md",[],[130,131,132,133,134,135],"news","tech","tech news daily","daily","rss","翻译",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":147,"publishedAt":37},"01M71ATFAEAMQ17M70NQNY7SR8","summarize","Summarize URLs or files with the summarize CLI (web, PDFs, images, audio, YouTube).","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Fsummarize\u002FSKILL.md",[142],{"categoryNo":143,"categoryName":144,"taxonomyType":145,"taxonomyTypeDesc":146},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[138,84,148,149,150,87,105,151,152,153,97,154,109],"Audio","cli","youtube","images","https","files","pdfs",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":161,"publishedAt":37},"01M71ATDNS3R0M4H936PACQAWZ","sonoscli","Control Sonos speakers (discover\u002Fstatus\u002Fplay\u002Fvolume\u002Fgroup).","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Fsonoscli\u002FSKILL.md",[],[157,162,163,164,109,165,152,166,167,168,169,170],"status","play","go","latest","github","discover","control","cmd","volume"]