[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CTKZPERT5HD4AYN72W7DZF":3,"skill-same:01M6CTKZPERT5HD4AYN72W7DZF":59},{"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":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":37,"commitSha":38,"skillDirectory":39,"forksCount":40,"repositoryHtmlUrl":41,"repositoryHomepageUrl":41,"ownerHtmlUrl":42,"ownerBlogUrl":6,"ownerDescription":43,"updatedAt":44,"install":45,"resources":58},"01M6CTKZPERT5HD4AYN72W7DZF","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.","Sam-06060\u002Fjarvis-assistant","Sam-06060","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F208600848?v=4","01M6CRKT7C7FXD21V6HXF293S0","Samson Frank Ganta","01M6CRKTBEKYFD8YX5Z1GT99EE",6,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant\u002Fblob\u002Fmain\u002Fmodules\u002Fagent_skills\u002Fawesome-skills\u002Fplaybooks\u002Fkaizen\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29],"code quality","code","refactor","continuous improvement","improve","quality","user","process","guide","use","community","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":35,"source":29,"date_added":36,"description":7},"unknown","2026-02-27","main","a50a3aa6b39fb0e1b7db88bef1bfc9c93606e126","modules\u002Fagent_skills\u002Fawesome-skills\u002Fplaybooks\u002Fkaizen",0,"https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant","https:\u002F\u002Fgithub.com\u002FSam-06060","Mobile Application Developer | Kotlin | Flutter, KMP, Swfit, Android,Swift UI | Building at Saar It Resources | Creator of Jarvis (AI Assistant)","2026-06-23 05:13:38",{"source":8,"skillName":5,"commands":46,"prompt":56,"zipAvailable":57},[47,50,53],{"tool":48,"command":49},"npx","npx skills add Sam-06060\u002Fjarvis-assistant --skill kaizen",{"tool":51,"command":52},"bunx","bunx skills add Sam-06060\u002Fjarvis-assistant --skill kaizen",{"tool":54,"command":55},"pnpm","pnpm dlx skills add Sam-06060\u002Fjarvis-assistant --skill kaizen","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant\u002Fblob\u002Fmain\u002Fmodules\u002Fagent_skills\u002Fawesome-skills\u002Fplaybooks\u002Fkaizen\u002FSKILL.md",true,[],[60,73,89,116,135,162],{"skillNo":61,"name":62,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":70,"publishedAt":30},"01M6GDRVS6FXX3ESH0C9DW01C0","test_skill","https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant\u002Fblob\u002Fmain\u002Fscratch\u002Ftest_skill\u002FSKILL.md",[65],{"categoryNo":66,"categoryName":67,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[71,72],"Test Skill","test",{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":30},"01M6GDRQ40HX22MA6XWC31RHHK","zustand-store-ts","Create Zustand stores following established patterns with proper TypeScript types and middleware.","https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant\u002Fblob\u002Fmain\u002Fmodules\u002Fagent_skills\u002Fawesome-skills\u002Fplaybooks\u002Fzustand-store-ts\u002FSKILL.md",[],[80,81,82,83,84,85,86,29,87,88],"zustand store ts","zustand","store","with","types","middleware","patterns","create","typescript",{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":98,"publishedAt":30},"01M6GDRKEA0WE670SPFWX5GKCN","zoom-automation","Automate Zoom meeting creation, management, recordings, webinars, and participant tracking via Rube MCP (Composio). Always search tools first for current schemas.","https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant\u002Fblob\u002Fmain\u002Fmodules\u002Fagent_skills\u002Fawesome-skills\u002Fplaybooks\u002Fzoom-automation\u002FSKILL.md",[95],{"categoryNo":96,"categoryName":97,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000023","Skill与智能体开发",[99,100,101,102,103,104,105,106,107,108,109,110,111,112,29,113,114,115],"automation","zoom automation","zoom","first","Tools","search","MCP","via","meeting","automate","critical","creation","webinars","composio","recordings","management","tracking",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":123,"publishedAt":30},"01M6GDRFS1452PC71JQ38S24HR","zoho-crm-automation","Automate Zoho CRM tasks via Rube MCP (Composio): create\u002Fupdate records, search contacts, manage leads, and convert leads. Always search tools first for current schemas.","https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant\u002Fblob\u002Fmain\u002Fmodules\u002Fagent_skills\u002Fawesome-skills\u002Fplaybooks\u002Fzoho-crm-automation\u002FSKILL.md",[122],{"categoryNo":96,"categoryName":97,"taxonomyType":68,"taxonomyTypeDesc":69},[124,99,125,126,127,128,129,29,104,130,112,131,109,108,103,132,87,133,105,134],"crm automation","zoho crm","crm","zoho crm automation","zoho","leads","contacts","records","update","tasks","manage",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":144,"publishedAt":30},"01M6GDRCKQBAVTGHX5XBH26KPZ","zod-validation-expert","Expert in Zod — TypeScript-first schema validation. Covers parsing, custom errors, refinements, type inference, and integration with React Hook Form, Next.js, and tRPC.","https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant\u002Fblob\u002Fmain\u002Fmodules\u002Fagent_skills\u002Fawesome-skills\u002Fplaybooks\u002Fzod-validation-expert\u002FSKILL.md",[141],{"categoryNo":142,"categoryName":143,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000009","前端开发",[145,146,147,148,149,88,150,151,152,153,154,155,83,156,157,158,159,29,160,161],"expert","zod","zod validation expert","validation","react","safe","parsing","errors","schema validation","react hook form","hook","trpc","form","type","next","schema","Next.js",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":169,"publishedAt":30},"01M6GDR658B08K4MY0RWD4A6EH","zeroize-audit","Detects missing zeroization of sensitive data in source code and identifies zeroization removed by compiler optimizations, with assembly-level analysis, and control-flow verification. Use for auditing C\u002FC++\u002FRust code handling secrets, keys, passwords, or other sensitive data.","https:\u002F\u002Fgithub.com\u002FSam-06060\u002Fjarvis-assistant\u002Fblob\u002Fmain\u002Fmodules\u002Fagent_skills\u002Fawesome-skills\u002Fplaybooks\u002Fzeroize-audit\u002FSKILL.md",[168],{"categoryNo":96,"categoryName":97,"taxonomyType":68,"taxonomyTypeDesc":69},[170,171,172,173,174,175,176,177,29,178,179,180,181,182,183,184,185,20,186,105],"zeroize audit","audit","write","passwords","get","project","c++","activate","assembly","read","Bash","secrets","analysis","data","flow","verification","rust"]