[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70FQ09SWJAZNQXNXHCKF328":3,"skill-same:01M70FQ09SWJAZNQXNXHCKF328":56},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":27,"linkOnly":28,"markdownContent":29,"markdownBody":30,"frontMatter":31,"refName":32,"commitSha":33,"skillDirectory":34,"forksCount":35,"repositoryHtmlUrl":36,"repositoryHomepageUrl":37,"ownerHtmlUrl":38,"ownerBlogUrl":39,"ownerDescription":40,"updatedAt":41,"install":42,"resources":55},"01M70FQ09SWJAZNQXNXHCKF328","typescript",null,"Must always be enabled when writing\u002Freviewing TypeScript code.","shengdabai\u002FTony-Claude-Code-Skills","shengdabai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F116417419?v=4","01M70F6D2WY5PQV5A92BKYJQEW","Tony Sheng","01M70F6D3GAAAYZ5H4CC1G8VXM",3,"MIT","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fclaude-code\u002Fskills\u002Ftypescript\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[5,24,25,26],"writing","when","code","2026-11-10 10:12:30",false,"---\nname: typescript\ndescription: Must always be enabled when writing\u002Freviewing TypeScript code.\n---\n\n\u003Cphilosophy>\n## Core Philosophy: Type-Level Verification\n\nLLM-generated code faces inherent challenges with E2E testing and runtime verification. Compensate by maximizing compile-time verification through:\n\n- Algebraic data types (discriminated unions, exhaustive pattern matching)\n- Strict type constraints that make invalid states unrepresentable\n- Type-level proofs over runtime assertions\n\n**Goal**: If it type-checks, it works. Shift as many bugs as possible from runtime to compile-time.\n\u003C\u002Fphilosophy>\n\n\u003Ctype_assertions>\n## Type Assertions: Banned by Default\n\n### Rule: `as` Type Assertions are Prohibited\n\n**Rationale**: Type assertions bypass TypeScript's type system and introduce type unsoundness. They are frequently misused to silence legitimate type errors.\n\n**Policy**:\n- ❌ **Never use** `as` to resolve type errors\n- ❌ **Never use** `as any` or `as unknown as X`\n- ⚠️ **Rare exceptions**: Compiler limitations (e.g., specific generic inference bugs)\n  - If you encounter such cases, **leave the type error unresolved**\n  - Escalate to user with explanation: \"Type error at `path\u002Fto\u002Ffile.ts:123` - requires manual review for potential `as` usage\"\n\n**Why you cannot judge appropriately**:\nAs an LLM, you lack the contextual understanding to determine if a type assertion is truly necessary vs. masking a real type error. When in doubt, preserve type safety.\n\n### Alternative: Fix the Root Cause\n\nInstead of `as`, address the underlying type issue:\n- Refine function signatures\n- Use type guards (`if (typeof x === 'string')`)\n- Employ discriminated unions\n- Add generic constraints\n\u003C\u002Ftype_assertions>\n\n\u003Cstrict_typing>\n## Strict Typing Patterns\n\n### Prefer `as const satisfies` Over Loose Annotations\n\n**Problem with loose typing**:\n```typescript\nconst config: Config = {\n  mode: 'development',  \u002F\u002F Type widened to string\n  port: 3000\n}\n\u002F\u002F config.mode is string, not 'development' | 'production'\n```\n\n**Solution - strict typing with `as const satisfies`**:\n```typescript\nconst config = {\n  mode: 'development',\n  port: 3000\n} as const satisfies Config\n\u002F\u002F config.mode is exactly 'development' (literal type preserved)\n```\n\n**Benefits**:\n- Preserves literal types\n- Catches typos at definition site\n- Enables exhaustive checking in consumers\n- No type widening\n\n**Application**:\n- Configuration objects\n- Constant lookup tables\n- Route definitions\n- Action type constants\n\n### Avoid Explicit Type Annotations When Inference Suffices\n\n```typescript\n\u002F\u002F ❌ Redundant annotation\nconst result: number = calculateTotal(items)\n\n\u002F\u002F ✅ Let TypeScript infer\nconst result = calculateTotal(items)\n```\n\nUse annotations when:\n- Constraining function parameters\n- Enforcing strict object shapes (`as const satisfies`)\n- Documenting public API boundaries\n\u003C\u002Fstrict_typing>\n\n\u003Cexternal_data>\n## External Data: Never Trust, Always Validate\n\n### Rule: No `any` for External Data\n\n**Sources requiring validation**:\n- API responses (fetch, axios, etc.)\n- `JSON.parse()` results\n- LocalStorage\u002FSessionStorage reads\n- FormData \u002F user input\n- Environment variables\n- File system reads\n\n### Strategy 1: Type-Safe API Clients (Preferred)\n\n**Check for generated type definitions first**:\n- **Hono**: `hono\u002Fclient` with type inference\n- **orval**: OpenAPI-generated types and hooks\n- **tRPC**: End-to-end type safety\n- **GraphQL Code Generator**: Typed queries\n\n**Example (Hono client)**:\n```typescript\nimport { hc } from 'hono\u002Fclient'\nimport type { AppType } from '.\u002Fserver'\n\nconst client = hc\u003CAppType>('\u002Fapi')\nconst response = await client.users.$get()\n\u002F\u002F response is fully typed from server definition\n```\n\n**Action**: Review existing codebase for established patterns. Most projects already have type-safe API layers.\n\n### Strategy 2: Runtime Validation Libraries\n\nWhen type generation is unavailable, use schema validation:\n\n**Preference order**:\n1. **Existing project dependency** (check `package.json`)\n2. **valibot** (lightweight, install if needed: `pnpm add valibot`)\n3. **zod** (popular, larger bundle)\n\n**Example (valibot)**:\n```typescript\nimport * as v from 'valibot'\n\nconst UserSchema = v.object({\n  id: v.number(),\n  name: v.string(),\n  role: v.union([v.literal('admin'), v.literal('user')])\n})\n\n\u002F\u002F Parse and validate\nconst response = await fetch('\u002Fapi\u002Fuser')\nconst data = await response.json()\nconst user = v.parse(UserSchema, data)  \u002F\u002F Throws if invalid\n\u002F\u002F user is now typed as { id: number, name: string, role: 'admin' | 'user' }\n```\n\n**Example (JSON.parse)**:\n```typescript\n\u002F\u002F ❌ Unsafe\nconst data = JSON.parse(localStorage.getItem('config')!)\n\n\u002F\u002F ✅ Validated\nconst raw = localStorage.getItem('config')\nif (raw) {\n  const data = v.parse(ConfigSchema, JSON.parse(raw))\n}\n```\n\n### Never Skip Validation\n\nEven if \"you know\" the shape, external data can change:\n- API contracts evolve\n- Users manipulate localStorage\n- Third-party services have bugs\n\n**Type safety = static types + runtime validation**\n\u003C\u002Fexternal_data>\n\n\u003Cbest_practices>\n## General Best Practices\n\n### Prefer Arrow Functions Over Function Declarations\n\n**Rule**: Use arrow functions (`=>`) instead of `function` keyword for consistency and lexical scoping benefits.\n\n**Rationale**:\n- Consistent lexical `this` binding (no context confusion)\n- More concise syntax\n- Better integration with modern TypeScript patterns\n- Prevents accidental hoisting-related bugs\n\n```typescript\n\u002F\u002F ❌ Function declaration\nfunction calculateTotal(items: Item[]): number {\n  return items.reduce((sum, item) => sum + item.price, 0)\n}\n\n\u002F\u002F ✅ Arrow function\nconst calculateTotal = (items: Item[]): number => {\n  return items.reduce((sum, item) => sum + item.price, 0)\n}\n\n\u002F\u002F ✅ Concise form (single expression)\nconst calculateTotal = (items: Item[]): number =>\n  items.reduce((sum, item) => sum + item.price, 0)\n```\n\n**Exception**: When hoisting is genuinely required (rare), document the reason.\n\n### Discriminated Unions for State\n\n```typescript\ntype LoadingState\u003CT> =\n  | { status: 'idle' }\n  | { status: 'loading' }\n  | { status: 'success'; data: T }\n  | { status: 'error'; error: Error }\n\nconst render = (state: LoadingState\u003CUser>) => {\n  switch (state.status) {\n    case 'idle':\n      return 'Not started'\n    case 'loading':\n      return 'Loading...'\n    case 'success':\n      return state.data.name  \u002F\u002F data is available\n    case 'error':\n      return state.error.message  \u002F\u002F error is available\n  }\n}\n```\n\n**Benefits**: Impossible to access `data` when status is `'error'`.\n\n### Exhaustiveness Checking\n\n```typescript\nconst assertNever = (x: never): never => {\n  throw new Error(`Unexpected value: ${x}`)\n}\n\nswitch (state.status) {\n  case 'idle':\n  case 'loading':\n  case 'success':\n  case 'error':\n    return\n  default:\n    assertNever(state)  \u002F\u002F Compile error if cases are missing\n}\n```\n\n### Avoid Optional Properties for State\n\n```typescript\n\u002F\u002F ❌ Ambiguous state\ntype User = {\n  data?: UserData\n  error?: Error\n}\n\u002F\u002F What if both are defined? Neither?\n\n\u002F\u002F ✅ Explicit state\ntype User =\n  | { status: 'success'; data: UserData }\n  | { status: 'error'; error: Error }\n```\n\n### Use `unknown` Over `any` for Truly Unknown Types\n\n```typescript\n\u002F\u002F ❌ Disables all type checking\nconst process = (data: any) => {\n  return data.foo.bar  \u002F\u002F No errors, runtime explosion\n}\n\n\u002F\u002F ✅ Forces validation\nconst process = (data: unknown) => {\n  if (typeof data === 'object' && data !== null && 'foo' in data) {\n    \u002F\u002F Narrow the type before use\n  }\n}\n```\n\n### Readonly by Default\n\n```typescript\n\u002F\u002F Prevent accidental mutations\ntype Config = {\n  readonly apiUrl: string\n  readonly timeout: number\n}\n\n\u002F\u002F For arrays\nconst items = ['a', 'b'] as const\n```\n\n### Avoid Type-Level Gymnastics\n\nIf type definitions become incomprehensible, simplify the design:\n- Complex conditional types often indicate over-abstraction\n- Prefer explicit discriminated unions over heavily generic types\n- Maintainability > cleverness\n\u003C\u002Fbest_practices>\n\n\u003Cerror_handling>\n## When Type Errors Cannot Be Resolved\n\nIf you encounter legitimate type errors you cannot fix without `as`:\n\n1. **Leave the error in place**\n2. **Document the issue**:\n   ```typescript\n   \u002F\u002F TODO: Type error at line X - potential TypeScript limitation\n   \u002F\u002F Requires manual review before using type assertion\n   const result = someComplexOperation()  \u002F\u002F Type error here\n   ```\n3. **Notify the user**: \"Type error remains at `src\u002Fmodule.ts:45` - escalated for review\"\n\n**Do not**:\n- Silently add `as` assertions\n- Use `any` to bypass the error\n- Restructure correct code to satisfy incorrect types\n\u003C\u002Ferror_handling>\n","\u003Cphilosophy>\n## Core Philosophy: Type-Level Verification\n\nLLM-generated code faces inherent challenges with E2E testing and runtime verification. Compensate by maximizing compile-time verification through:\n\n- Algebraic data types (discriminated unions, exhaustive pattern matching)\n- Strict type constraints that make invalid states unrepresentable\n- Type-level proofs over runtime assertions\n\n**Goal**: If it type-checks, it works. Shift as many bugs as possible from runtime to compile-time.\n\u003C\u002Fphilosophy>\n\n\u003Ctype_assertions>\n## Type Assertions: Banned by Default\n\n### Rule: `as` Type Assertions are Prohibited\n\n**Rationale**: Type assertions bypass TypeScript's type system and introduce type unsoundness. They are frequently misused to silence legitimate type errors.\n\n**Policy**:\n- ❌ **Never use** `as` to resolve type errors\n- ❌ **Never use** `as any` or `as unknown as X`\n- ⚠️ **Rare exceptions**: Compiler limitations (e.g., specific generic inference bugs)\n  - If you encounter such cases, **leave the type error unresolved**\n  - Escalate to user with explanation: \"Type error at `path\u002Fto\u002Ffile.ts:123` - requires manual review for potential `as` usage\"\n\n**Why you cannot judge appropriately**:\nAs an LLM, you lack the contextual understanding to determine if a type assertion is truly necessary vs. masking a real type error. When in doubt, preserve type safety.\n\n### Alternative: Fix the Root Cause\n\nInstead of `as`, address the underlying type issue:\n- Refine function signatures\n- Use type guards (`if (typeof x === 'string')`)\n- Employ discriminated unions\n- Add generic constraints\n\u003C\u002Ftype_assertions>\n\n\u003Cstrict_typing>\n## Strict Typing Patterns\n\n### Prefer `as const satisfies` Over Loose Annotations\n\n**Problem with loose typing**:\n```typescript\nconst config: Config = {\n  mode: 'development',  \u002F\u002F Type widened to string\n  port: 3000\n}\n\u002F\u002F config.mode is string, not 'development' | 'production'\n```\n\n**Solution - strict typing with `as const satisfies`**:\n```typescript\nconst config = {\n  mode: 'development',\n  port: 3000\n} as const satisfies Config\n\u002F\u002F config.mode is exactly 'development' (literal type preserved)\n```\n\n**Benefits**:\n- Preserves literal types\n- Catches typos at definition site\n- Enables exhaustive checking in consumers\n- No type widening\n\n**Application**:\n- Configuration objects\n- Constant lookup tables\n- Route definitions\n- Action type constants\n\n### Avoid Explicit Type Annotations When Inference Suffices\n\n```typescript\n\u002F\u002F ❌ Redundant annotation\nconst result: number = calculateTotal(items)\n\n\u002F\u002F ✅ Let TypeScript infer\nconst result = calculateTotal(items)\n```\n\nUse annotations when:\n- Constraining function parameters\n- Enforcing strict object shapes (`as const satisfies`)\n- Documenting public API boundaries\n\u003C\u002Fstrict_typing>\n\n\u003Cexternal_data>\n## External Data: Never Trust, Always Validate\n\n### Rule: No `any` for External Data\n\n**Sources requiring validation**:\n- API responses (fetch, axios, etc.)\n- `JSON.parse()` results\n- LocalStorage\u002FSessionStorage reads\n- FormData \u002F user input\n- Environment variables\n- File system reads\n\n### Strategy 1: Type-Safe API Clients (Preferred)\n\n**Check for generated type definitions first**:\n- **Hono**: `hono\u002Fclient` with type inference\n- **orval**: OpenAPI-generated types and hooks\n- **tRPC**: End-to-end type safety\n- **GraphQL Code Generator**: Typed queries\n\n**Example (Hono client)**:\n```typescript\nimport { hc } from 'hono\u002Fclient'\nimport type { AppType } from '.\u002Fserver'\n\nconst client = hc\u003CAppType>('\u002Fapi')\nconst response = await client.users.$get()\n\u002F\u002F response is fully typed from server definition\n```\n\n**Action**: Review existing codebase for established patterns. Most projects already have type-safe API layers.\n\n### Strategy 2: Runtime Validation Libraries\n\nWhen type generation is unavailable, use schema validation:\n\n**Preference order**:\n1. **Existing project dependency** (check `package.json`)\n2. **valibot** (lightweight, install if needed: `pnpm add valibot`)\n3. **zod** (popular, larger bundle)\n\n**Example (valibot)**:\n```typescript\nimport * as v from 'valibot'\n\nconst UserSchema = v.object({\n  id: v.number(),\n  name: v.string(),\n  role: v.union([v.literal('admin'), v.literal('user')])\n})\n\n\u002F\u002F Parse and validate\nconst response = await fetch('\u002Fapi\u002Fuser')\nconst data = await response.json()\nconst user = v.parse(UserSchema, data)  \u002F\u002F Throws if invalid\n\u002F\u002F user is now typed as { id: number, name: string, role: 'admin' | 'user' }\n```\n\n**Example (JSON.parse)**:\n```typescript\n\u002F\u002F ❌ Unsafe\nconst data = JSON.parse(localStorage.getItem('config')!)\n\n\u002F\u002F ✅ Validated\nconst raw = localStorage.getItem('config')\nif (raw) {\n  const data = v.parse(ConfigSchema, JSON.parse(raw))\n}\n```\n\n### Never Skip Validation\n\nEven if \"you know\" the shape, external data can change:\n- API contracts evolve\n- Users manipulate localStorage\n- Third-party services have bugs\n\n**Type safety = static types + runtime validation**\n\u003C\u002Fexternal_data>\n\n\u003Cbest_practices>\n## General Best Practices\n\n### Prefer Arrow Functions Over Function Declarations\n\n**Rule**: Use arrow functions (`=>`) instead of `function` keyword for consistency and lexical scoping benefits.\n\n**Rationale**:\n- Consistent lexical `this` binding (no context confusion)\n- More concise syntax\n- Better integration with modern TypeScript patterns\n- Prevents accidental hoisting-related bugs\n\n```typescript\n\u002F\u002F ❌ Function declaration\nfunction calculateTotal(items: Item[]): number {\n  return items.reduce((sum, item) => sum + item.price, 0)\n}\n\n\u002F\u002F ✅ Arrow function\nconst calculateTotal = (items: Item[]): number => {\n  return items.reduce((sum, item) => sum + item.price, 0)\n}\n\n\u002F\u002F ✅ Concise form (single expression)\nconst calculateTotal = (items: Item[]): number =>\n  items.reduce((sum, item) => sum + item.price, 0)\n```\n\n**Exception**: When hoisting is genuinely required (rare), document the reason.\n\n### Discriminated Unions for State\n\n```typescript\ntype LoadingState\u003CT> =\n  | { status: 'idle' }\n  | { status: 'loading' }\n  | { status: 'success'; data: T }\n  | { status: 'error'; error: Error }\n\nconst render = (state: LoadingState\u003CUser>) => {\n  switch (state.status) {\n    case 'idle':\n      return 'Not started'\n    case 'loading':\n      return 'Loading...'\n    case 'success':\n      return state.data.name  \u002F\u002F data is available\n    case 'error':\n      return state.error.message  \u002F\u002F error is available\n  }\n}\n```\n\n**Benefits**: Impossible to access `data` when status is `'error'`.\n\n### Exhaustiveness Checking\n\n```typescript\nconst assertNever = (x: never): never => {\n  throw new Error(`Unexpected value: ${x}`)\n}\n\nswitch (state.status) {\n  case 'idle':\n  case 'loading':\n  case 'success':\n  case 'error':\n    return\n  default:\n    assertNever(state)  \u002F\u002F Compile error if cases are missing\n}\n```\n\n### Avoid Optional Properties for State\n\n```typescript\n\u002F\u002F ❌ Ambiguous state\ntype User = {\n  data?: UserData\n  error?: Error\n}\n\u002F\u002F What if both are defined? Neither?\n\n\u002F\u002F ✅ Explicit state\ntype User =\n  | { status: 'success'; data: UserData }\n  | { status: 'error'; error: Error }\n```\n\n### Use `unknown` Over `any` for Truly Unknown Types\n\n```typescript\n\u002F\u002F ❌ Disables all type checking\nconst process = (data: any) => {\n  return data.foo.bar  \u002F\u002F No errors, runtime explosion\n}\n\n\u002F\u002F ✅ Forces validation\nconst process = (data: unknown) => {\n  if (typeof data === 'object' && data !== null && 'foo' in data) {\n    \u002F\u002F Narrow the type before use\n  }\n}\n```\n\n### Readonly by Default\n\n```typescript\n\u002F\u002F Prevent accidental mutations\ntype Config = {\n  readonly apiUrl: string\n  readonly timeout: number\n}\n\n\u002F\u002F For arrays\nconst items = ['a', 'b'] as const\n```\n\n### Avoid Type-Level Gymnastics\n\nIf type definitions become incomprehensible, simplify the design:\n- Complex conditional types often indicate over-abstraction\n- Prefer explicit discriminated unions over heavily generic types\n- Maintainability > cleverness\n\u003C\u002Fbest_practices>\n\n\u003Cerror_handling>\n## When Type Errors Cannot Be Resolved\n\nIf you encounter legitimate type errors you cannot fix without `as`:\n\n1. **Leave the error in place**\n2. **Document the issue**:\n   ```typescript\n   \u002F\u002F TODO: Type error at line X - potential TypeScript limitation\n   \u002F\u002F Requires manual review before using type assertion\n   const result = someComplexOperation()  \u002F\u002F Type error here\n   ```\n3. **Notify the user**: \"Type error remains at `src\u002Fmodule.ts:45` - escalated for review\"\n\n**Do not**:\n- Silently add `as` assertions\n- Use `any` to bypass the error\n- Restructure correct code to satisfy incorrect types\n\u003C\u002Ferror_handling>\n",{"name":5,"description":7},"main","7850740bd837adb32f0a109ab2af82482196c6f2","skills\u002F_collections\u002Fclaude-code\u002Fskills\u002Ftypescript",1,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills","https:\u002F\u002Fzturnsgo.com","https:\u002F\u002Fgithub.com\u002Fshengdabai","https:\u002F\u002Fzturnsgo.com\u002F","AI × education creator — producer, not consumer. Taught 6,000+ learners; shipping learning tools & daily essays with Claude Code, practicing @xiaolai's way 🥋","2026-11-01 21:28:23",{"source":8,"skillName":5,"commands":43,"prompt":53,"zipAvailable":54},[44,47,50],{"tool":45,"command":46},"npx","npx skills add shengdabai\u002FTony-Claude-Code-Skills --skill typescript",{"tool":48,"command":49},"bunx","bunx skills add shengdabai\u002FTony-Claude-Code-Skills --skill typescript",{"tool":51,"command":52},"pnpm","pnpm dlx skills add shengdabai\u002FTony-Claude-Code-Skills --skill typescript","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fclaude-code\u002Fskills\u002Ftypescript\u002FSKILL.md",true,[],[57,75,104,130,152,172],{"skillNo":58,"name":59,"nameZh":6,"description":60,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":61,"categories":62,"keywords":68,"publishedAt":27},"01M70P17DAD4C1C47NPH6A96EM","xiaolai-methodology","以李笑来(Li Xiaolai)的思考方式、方法论与表达风格,为用户做全方位 1-on-1 教练指导,覆盖创业、赚钱、投资、学习、自学、读书写作、用 AI、以及人生心态与自我管理。当用户提到 \"李笑来\"、\"笑来\"、\"笑来老师\"、\"扮演李笑来\"、\"找笑来聊聊\"、\"笑来怎么看\"、\"xiaolai\"、\"把时间当作朋友\"、\"通往财富自由之路\"、\"定投改变命运\"、\"韭菜的自我修养\"、\"自学是门手艺\"、\"让时间陪你慢慢变富\"、\"七年就是一辈子\"、\"元认知\"、\"活在未来\"、\"复利\u002F长期主义\"、\"践行\"、\"痴迷改进\"、\"个人商业模式\u002F出售时间\"、\"睡后收入\"、\"定投\"、\"财富自由\"、\"操作系统升级\"、\"最少必要知识\"、\"北极星提示词\"、\"用 AI 该怎么学\u002F思考\" 等任一触发词,或当用户带着关于创业\u002F赚钱\u002F投资\u002F学习\u002F职业\u002F重大人生决策的困惑、希望被人用笑来式的「逻辑 + 大白话 + 类比 + 重新定义 + 践行导向」来点醒和指导时,自动进入李笑来教练模式。","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fxiaolai-methodology\u002FSKILL.md",[63],{"categoryNo":64,"categoryName":65,"taxonomyType":66,"taxonomyTypeDesc":67},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",[69,70,71,72,73,24,74],"methodology","xiaolai","xiaolai methodology","朋友","投资","收入",{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":85,"publishedAt":27},"01M70P13NB9YP7ACJR1S861CDS","zread","Produce and consume a wiki-style knowledge base for a code repository via the `zread` CLI and its on-disk output under `.\u002F.zread\u002Fwiki\u002F`. Use this skill whenever the user wants to understand, onboard onto, explore, summarize, map, or get an overview of an unfamiliar codebase; asks for architecture docs, a project wiki, a repo walkthrough, module\u002Fpackage explanations, or \"what does this repo do\"; wants to generate, regenerate, resume, browse, or serve code documentation locally; or mentions zread \u002F zread.ai directly. Also use it proactively before diving into a large unknown repo — if `.\u002F.zread\u002Fwiki\u002Fcurrent` exists, read the generated pages instead of crawling source file-by-file; if it doesn't, consider offering to run `zread generate`. The trigger is the intent (understand a codebase through generated docs), not the literal word \"zread\".","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fzread\u002FSKILL.md",[81,84],{"categoryNo":82,"categoryName":83,"taxonomyType":66,"taxonomyTypeDesc":67},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[77,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,26,102,103],"knowledge","wiki","explore","walkthrough","project","get","knowledge base","run","generate","intent","cli","map","documentation","project wiki","disk","architecture","unknown","generated",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":114,"publishedAt":27},"01M70P10S4SWMZQ8BJAFBFDRW3","youtube","Launch the YouTube Creator Agent to auto-generate videos.\nUse when: user types \u002Fyoutube, wants to create YouTube videos,\ngenerate video content, or upload to YouTube.\nKeywords: youtube, video, 视频, 创作视频, 发布视频","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube\u002FSKILL.md",[110,111],{"categoryNo":82,"categoryName":83,"taxonomyType":66,"taxonomyTypeDesc":67},{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000036","内容创作者",[106,115,116,117,118,119,120,121,94,122,123,124,25,125,126,127,128,129],"user","content","视频","creator","generate video","videos","launch","video content","create","upload","use","auto","types","Video","创作",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":137,"publishedAt":27},"01M70P0YE95D8BACZCGV8BK90K","youtube-script-sync","Sync, update, or optimize Tony's GetNote knowledge base `Youtube视频逐字稿` by turning each parent recording or first-person idea note into an idempotent child note containing a directly recordable YouTube long-video or Shorts script. Use when the user says “更新\u002F同步\u002F优化 Youtube视频逐字稿知识库”, or says “更新\u002F同步\u002F优化该知识库” while this knowledge base is the active context.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube-script-sync\u002FSKILL.md",[136],{"categoryNo":82,"categoryName":83,"taxonomyType":66,"taxonomyTypeDesc":67},[138,139,106,140,141,128,142,143,144,145,146,147,148,149,92,150,25,125,86,151],"sync","script","youtube script sync","recording","shorts","first","base","person","update","active","child","optimize","idempotent","long",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":162,"publishedAt":27},"01M70P0WMV5XT0EEC0N445PW07","writing-skills","How to write SKILL.md files that trigger reliably and teach effectively. Use when creating, improving, or reviewing Claude Code skills.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fxiaolai\u002Fnlpm\u002Fskills\u002Fnlpm\u002Fwriting-skills\u002FSKILL.md",[158,159,160,161],{"categoryNo":64,"categoryName":65,"taxonomyType":66,"taxonomyTypeDesc":67},{"categoryNo":82,"categoryName":83,"taxonomyType":66,"taxonomyTypeDesc":67},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},[163,24,164,165,166,167,26,25,125,168,169,170,171],"writing skills","how","teach","write skill","write","claude code skills","files","how to","trigger",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":180,"publishedAt":27},"01M70P0SJFR4YVJQBGMHKGSKXT","writing-rules","How to write .claude\u002Frules\u002F files that Claude actually follows. Use when creating, improving, or reviewing project rules.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fxiaolai\u002Fnlpm\u002Fskills\u002Fnlpm\u002Fwriting-rules\u002FSKILL.md",[178,179],{"categoryNo":64,"categoryName":65,"taxonomyType":66,"taxonomyTypeDesc":67},{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},[181,24,182,90,183,169,25,164,167,125,170],"Rules","writing rules","project rules"]