[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70NMMMM9KG7TMKD6QRS236P":3,"skill-same:01M70NMMMM9KG7TMKD6QRS236P":64},{"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":35,"linkOnly":36,"markdownContent":37,"markdownBody":38,"frontMatter":39,"refName":40,"commitSha":41,"skillDirectory":42,"forksCount":43,"repositoryHtmlUrl":44,"repositoryHomepageUrl":45,"ownerHtmlUrl":46,"ownerBlogUrl":47,"ownerDescription":48,"updatedAt":49,"install":50,"resources":63},"01M70NMMMM9KG7TMKD6QRS236P","using-agent-skills",null,"Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.","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\u002Fusing-agent-skills\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34],"using agent skills","which","discover","meta-skill","session","Meta","use","when","you","task","how","2026-11-10 10:12:30",false,"---\nname: using-agent-skills\ndescription: Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.\n---\n\n# Using Agent Skills\n\n## Overview\n\nAgent Skills is a collection of engineering workflow skills organized by development phase. Each skill encodes a specific process that senior engineers follow. This meta-skill helps you discover and apply the right skill for your current task.\n\n## Skill Discovery\n\nWhen a task arrives, identify the development phase and apply the corresponding skill:\n\n```\nTask arrives\n    │\n    ├── Don't know what you want yet? ──────→ interview-me\n    ├── Have a rough concept, need variants? → idea-refine\n    ├── New project\u002Ffeature\u002Fchange? ──→ spec-driven-development\n    ├── Have a spec, need tasks? ──────→ planning-and-task-breakdown\n    ├── Implementing code? ────────────→ incremental-implementation\n    │   ├── UI work? ─────────────────→ frontend-ui-engineering\n    │   ├── API work? ────────────────→ api-and-interface-design\n    │   ├── Need better context? ─────→ context-engineering\n    │   ├── Need doc-verified code? ───→ source-driven-development\n    │   └── Stakes high \u002F unfamiliar code? ──→ doubt-driven-development\n    ├── Writing\u002Frunning tests? ────────→ test-driven-development\n    │   └── Browser-based? ───────────→ browser-testing-with-devtools\n    ├── Something broke? ──────────────→ debugging-and-error-recovery\n    ├── Reviewing code? ───────────────→ code-review-and-quality\n    │   ├── Too complex? ─────────────→ code-simplification\n    │   ├── Security concerns? ───────→ security-and-hardening\n    │   └── Performance concerns? ────→ performance-optimization\n    ├── Committing\u002Fbranching? ─────────→ git-workflow-and-versioning\n    ├── CI\u002FCD pipeline work? ──────────→ ci-cd-and-automation\n    ├── Deprecating\u002Fmigrating? ────────→ deprecation-and-migration\n    ├── Writing docs\u002FADRs? ───────────→ documentation-and-adrs\n    └── Deploying\u002Flaunching? ─────────→ shipping-and-launch\n```\n\n## Core Operating Behaviors\n\nThese behaviors apply at all times, across all skills. They are non-negotiable.\n\n### 1. Surface Assumptions\n\nBefore implementing anything non-trivial, explicitly state your assumptions:\n\n```\nASSUMPTIONS I'M MAKING:\n1. [assumption about requirements]\n2. [assumption about architecture]\n3. [assumption about scope]\n→ Correct me now or I'll proceed with these.\n```\n\nDon't silently fill in ambiguous requirements. The most common failure mode is making wrong assumptions and running with them unchecked. Surface uncertainty early — it's cheaper than rework.\n\n### 2. Manage Confusion Actively\n\nWhen you encounter inconsistencies, conflicting requirements, or unclear specifications:\n\n1. **STOP.** Do not proceed with a guess.\n2. Name the specific confusion.\n3. Present the tradeoff or ask the clarifying question.\n4. Wait for resolution before continuing.\n\n**Bad:** Silently picking one interpretation and hoping it's right.\n**Good:** \"I see X in the spec but Y in the existing code. Which takes precedence?\"\n\n### 3. Push Back When Warranted\n\nYou are not a yes-machine. When an approach has clear problems:\n\n- Point out the issue directly\n- Explain the concrete downside (quantify when possible — \"this adds ~200ms latency\" not \"this might be slower\")\n- Propose an alternative\n- Accept the human's decision if they override with full information\n\nSycophancy is a failure mode. \"Of course!\" followed by implementing a bad idea helps no one. Honest technical disagreement is more valuable than false agreement.\n\n### 4. Enforce Simplicity\n\nYour natural tendency is to overcomplicate. Actively resist it.\n\nBefore finishing any implementation, ask:\n- Can this be done in fewer lines?\n- Are these abstractions earning their complexity?\n- Would a staff engineer look at this and say \"why didn't you just...\"?\n\nIf you build 1000 lines and 100 would suffice, you have failed. Prefer the boring, obvious solution. Cleverness is expensive.\n\n### 5. Maintain Scope Discipline\n\nTouch only what you're asked to touch.\n\nDo NOT:\n- Remove comments you don't understand\n- \"Clean up\" code orthogonal to the task\n- Refactor adjacent systems as a side effect\n- Delete code that seems unused without explicit approval\n- Add features not in the spec because they \"seem useful\"\n\nYour job is surgical precision, not unsolicited renovation.\n\n### 6. Verify, Don't Assume\n\nEvery skill includes a verification step. A task is not complete until verification passes. \"Seems right\" is never sufficient — there must be evidence (passing tests, build output, runtime data).\n\n## Failure Modes to Avoid\n\nThese are the subtle errors that look like productivity but create problems:\n\n1. Making wrong assumptions without checking\n2. Not managing your own confusion — plowing ahead when lost\n3. Not surfacing inconsistencies you notice\n4. Not presenting tradeoffs on non-obvious decisions\n5. Being sycophantic (\"Of course!\") to approaches with clear problems\n6. Overcomplicating code and APIs\n7. Modifying code or comments orthogonal to the task\n8. Removing things you don't fully understand\n9. Building without a spec because \"it's obvious\"\n10. Skipping verification because \"it looks right\"\n\n## Skill Rules\n\n1. **Check for an applicable skill before starting work.** Skills encode processes that prevent common mistakes.\n\n2. **Skills are workflows, not suggestions.** Follow the steps in order. Don't skip verification steps.\n\n3. **Multiple skills can apply.** A feature implementation might involve `idea-refine` → `spec-driven-development` → `planning-and-task-breakdown` → `incremental-implementation` → `test-driven-development` → `code-review-and-quality` → `code-simplification` → `shipping-and-launch` in sequence.\n\n4. **When in doubt, start with a spec.** If the task is non-trivial and there's no spec, begin with `spec-driven-development`.\n\n## Lifecycle Sequence\n\nFor a complete feature, the typical skill sequence is:\n\n```\n1.  interview-me                → Extract what the user actually wants\n2.  idea-refine                 → Refine vague ideas\n3.  spec-driven-development     → Define what we're building\n4.  planning-and-task-breakdown → Break into verifiable chunks\n5.  context-engineering         → Load the right context\n6.  source-driven-development   → Verify against official docs\n7.  incremental-implementation  → Build slice by slice\n8.  doubt-driven-development    → Cross-examine non-trivial decisions in-flight\n9.  test-driven-development     → Prove each slice works\n10. code-review-and-quality     → Review before merge\n11. code-simplification         → Reduce unnecessary complexity while preserving behavior\n12. git-workflow-and-versioning → Clean commit history\n13. documentation-and-adrs      → Document decisions\n14. deprecation-and-migration   → Retire old systems and move users safely when needed\n15. shipping-and-launch         → Deploy safely\n```\n\nNot every task needs every skill. A bug fix might only need: `debugging-and-error-recovery` → `test-driven-development` → `code-review-and-quality`.\n\n## Quick Reference\n\n| Phase | Skill | One-Line Summary |\n|-------|-------|-----------------|\n| Define | interview-me | Surface what the user actually wants before any plan, spec, or code exists |\n| Define | idea-refine | Refine ideas through structured divergent and convergent thinking |\n| Define | spec-driven-development | Requirements and acceptance criteria before code |\n| Plan | planning-and-task-breakdown | Decompose into small, verifiable tasks |\n| Build | incremental-implementation | Thin vertical slices, test each before expanding |\n| Build | source-driven-development | Verify against official docs before implementing |\n| Build | doubt-driven-development | Adversarial fresh-context review of every non-trivial decision |\n| Build | context-engineering | Right context at the right time |\n| Build | frontend-ui-engineering | Production-quality UI with accessibility |\n| Build | api-and-interface-design | Stable interfaces with clear contracts |\n| Verify | test-driven-development | Failing test first, then make it pass |\n| Verify | browser-testing-with-devtools | Chrome DevTools MCP for runtime verification |\n| Verify | debugging-and-error-recovery | Reproduce → localize → fix → guard |\n| Review | code-review-and-quality | Five-axis review with quality gates |\n| Review | code-simplification | Preserve behavior while reducing unnecessary complexity |\n| Review | security-and-hardening | OWASP prevention, input validation, least privilege |\n| Review | performance-optimization | Measure first, optimize only what matters |\n| Ship | git-workflow-and-versioning | Atomic commits, clean history |\n| Ship | ci-cd-and-automation | Automated quality gates on every change |\n| Ship | deprecation-and-migration | Remove old systems and migrate users safely |\n| Ship | documentation-and-adrs | Document the why, not just the what |\n| Ship | shipping-and-launch | Pre-launch checklist, monitoring, rollback plan |\n","# Using Agent Skills\n\n## Overview\n\nAgent Skills is a collection of engineering workflow skills organized by development phase. Each skill encodes a specific process that senior engineers follow. This meta-skill helps you discover and apply the right skill for your current task.\n\n## Skill Discovery\n\nWhen a task arrives, identify the development phase and apply the corresponding skill:\n\n```\nTask arrives\n    │\n    ├── Don't know what you want yet? ──────→ interview-me\n    ├── Have a rough concept, need variants? → idea-refine\n    ├── New project\u002Ffeature\u002Fchange? ──→ spec-driven-development\n    ├── Have a spec, need tasks? ──────→ planning-and-task-breakdown\n    ├── Implementing code? ────────────→ incremental-implementation\n    │   ├── UI work? ─────────────────→ frontend-ui-engineering\n    │   ├── API work? ────────────────→ api-and-interface-design\n    │   ├── Need better context? ─────→ context-engineering\n    │   ├── Need doc-verified code? ───→ source-driven-development\n    │   └── Stakes high \u002F unfamiliar code? ──→ doubt-driven-development\n    ├── Writing\u002Frunning tests? ────────→ test-driven-development\n    │   └── Browser-based? ───────────→ browser-testing-with-devtools\n    ├── Something broke? ──────────────→ debugging-and-error-recovery\n    ├── Reviewing code? ───────────────→ code-review-and-quality\n    │   ├── Too complex? ─────────────→ code-simplification\n    │   ├── Security concerns? ───────→ security-and-hardening\n    │   └── Performance concerns? ────→ performance-optimization\n    ├── Committing\u002Fbranching? ─────────→ git-workflow-and-versioning\n    ├── CI\u002FCD pipeline work? ──────────→ ci-cd-and-automation\n    ├── Deprecating\u002Fmigrating? ────────→ deprecation-and-migration\n    ├── Writing docs\u002FADRs? ───────────→ documentation-and-adrs\n    └── Deploying\u002Flaunching? ─────────→ shipping-and-launch\n```\n\n## Core Operating Behaviors\n\nThese behaviors apply at all times, across all skills. They are non-negotiable.\n\n### 1. Surface Assumptions\n\nBefore implementing anything non-trivial, explicitly state your assumptions:\n\n```\nASSUMPTIONS I'M MAKING:\n1. [assumption about requirements]\n2. [assumption about architecture]\n3. [assumption about scope]\n→ Correct me now or I'll proceed with these.\n```\n\nDon't silently fill in ambiguous requirements. The most common failure mode is making wrong assumptions and running with them unchecked. Surface uncertainty early — it's cheaper than rework.\n\n### 2. Manage Confusion Actively\n\nWhen you encounter inconsistencies, conflicting requirements, or unclear specifications:\n\n1. **STOP.** Do not proceed with a guess.\n2. Name the specific confusion.\n3. Present the tradeoff or ask the clarifying question.\n4. Wait for resolution before continuing.\n\n**Bad:** Silently picking one interpretation and hoping it's right.\n**Good:** \"I see X in the spec but Y in the existing code. Which takes precedence?\"\n\n### 3. Push Back When Warranted\n\nYou are not a yes-machine. When an approach has clear problems:\n\n- Point out the issue directly\n- Explain the concrete downside (quantify when possible — \"this adds ~200ms latency\" not \"this might be slower\")\n- Propose an alternative\n- Accept the human's decision if they override with full information\n\nSycophancy is a failure mode. \"Of course!\" followed by implementing a bad idea helps no one. Honest technical disagreement is more valuable than false agreement.\n\n### 4. Enforce Simplicity\n\nYour natural tendency is to overcomplicate. Actively resist it.\n\nBefore finishing any implementation, ask:\n- Can this be done in fewer lines?\n- Are these abstractions earning their complexity?\n- Would a staff engineer look at this and say \"why didn't you just...\"?\n\nIf you build 1000 lines and 100 would suffice, you have failed. Prefer the boring, obvious solution. Cleverness is expensive.\n\n### 5. Maintain Scope Discipline\n\nTouch only what you're asked to touch.\n\nDo NOT:\n- Remove comments you don't understand\n- \"Clean up\" code orthogonal to the task\n- Refactor adjacent systems as a side effect\n- Delete code that seems unused without explicit approval\n- Add features not in the spec because they \"seem useful\"\n\nYour job is surgical precision, not unsolicited renovation.\n\n### 6. Verify, Don't Assume\n\nEvery skill includes a verification step. A task is not complete until verification passes. \"Seems right\" is never sufficient — there must be evidence (passing tests, build output, runtime data).\n\n## Failure Modes to Avoid\n\nThese are the subtle errors that look like productivity but create problems:\n\n1. Making wrong assumptions without checking\n2. Not managing your own confusion — plowing ahead when lost\n3. Not surfacing inconsistencies you notice\n4. Not presenting tradeoffs on non-obvious decisions\n5. Being sycophantic (\"Of course!\") to approaches with clear problems\n6. Overcomplicating code and APIs\n7. Modifying code or comments orthogonal to the task\n8. Removing things you don't fully understand\n9. Building without a spec because \"it's obvious\"\n10. Skipping verification because \"it looks right\"\n\n## Skill Rules\n\n1. **Check for an applicable skill before starting work.** Skills encode processes that prevent common mistakes.\n\n2. **Skills are workflows, not suggestions.** Follow the steps in order. Don't skip verification steps.\n\n3. **Multiple skills can apply.** A feature implementation might involve `idea-refine` → `spec-driven-development` → `planning-and-task-breakdown` → `incremental-implementation` → `test-driven-development` → `code-review-and-quality` → `code-simplification` → `shipping-and-launch` in sequence.\n\n4. **When in doubt, start with a spec.** If the task is non-trivial and there's no spec, begin with `spec-driven-development`.\n\n## Lifecycle Sequence\n\nFor a complete feature, the typical skill sequence is:\n\n```\n1.  interview-me                → Extract what the user actually wants\n2.  idea-refine                 → Refine vague ideas\n3.  spec-driven-development     → Define what we're building\n4.  planning-and-task-breakdown → Break into verifiable chunks\n5.  context-engineering         → Load the right context\n6.  source-driven-development   → Verify against official docs\n7.  incremental-implementation  → Build slice by slice\n8.  doubt-driven-development    → Cross-examine non-trivial decisions in-flight\n9.  test-driven-development     → Prove each slice works\n10. code-review-and-quality     → Review before merge\n11. code-simplification         → Reduce unnecessary complexity while preserving behavior\n12. git-workflow-and-versioning → Clean commit history\n13. documentation-and-adrs      → Document decisions\n14. deprecation-and-migration   → Retire old systems and move users safely when needed\n15. shipping-and-launch         → Deploy safely\n```\n\nNot every task needs every skill. A bug fix might only need: `debugging-and-error-recovery` → `test-driven-development` → `code-review-and-quality`.\n\n## Quick Reference\n\n| Phase | Skill | One-Line Summary |\n|-------|-------|-----------------|\n| Define | interview-me | Surface what the user actually wants before any plan, spec, or code exists |\n| Define | idea-refine | Refine ideas through structured divergent and convergent thinking |\n| Define | spec-driven-development | Requirements and acceptance criteria before code |\n| Plan | planning-and-task-breakdown | Decompose into small, verifiable tasks |\n| Build | incremental-implementation | Thin vertical slices, test each before expanding |\n| Build | source-driven-development | Verify against official docs before implementing |\n| Build | doubt-driven-development | Adversarial fresh-context review of every non-trivial decision |\n| Build | context-engineering | Right context at the right time |\n| Build | frontend-ui-engineering | Production-quality UI with accessibility |\n| Build | api-and-interface-design | Stable interfaces with clear contracts |\n| Verify | test-driven-development | Failing test first, then make it pass |\n| Verify | browser-testing-with-devtools | Chrome DevTools MCP for runtime verification |\n| Verify | debugging-and-error-recovery | Reproduce → localize → fix → guard |\n| Review | code-review-and-quality | Five-axis review with quality gates |\n| Review | code-simplification | Preserve behavior while reducing unnecessary complexity |\n| Review | security-and-hardening | OWASP prevention, input validation, least privilege |\n| Review | performance-optimization | Measure first, optimize only what matters |\n| Ship | git-workflow-and-versioning | Atomic commits, clean history |\n| Ship | ci-cd-and-automation | Automated quality gates on every change |\n| Ship | deprecation-and-migration | Remove old systems and migrate users safely |\n| Ship | documentation-and-adrs | Document the why, not just the what |\n| Ship | shipping-and-launch | Pre-launch checklist, monitoring, rollback plan |\n",{"name":5,"description":7},"main","7850740bd837adb32f0a109ab2af82482196c6f2","skills\u002Fusing-agent-skills",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":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add shengdabai\u002FTony-Claude-Code-Skills --skill using-agent-skills",{"tool":56,"command":57},"bunx","bunx skills add shengdabai\u002FTony-Claude-Code-Skills --skill using-agent-skills",{"tool":59,"command":60},"pnpm","pnpm dlx skills add shengdabai\u002FTony-Claude-Code-Skills --skill using-agent-skills","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fusing-agent-skills\u002FSKILL.md",true,[],[65,82,114,139,161,180],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":74,"publishedAt":35},"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",[71],{"categoryNo":72,"categoryName":73,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",[75,76,77,78,79,80,81],"methodology","xiaolai","xiaolai methodology","朋友","投资","writing","收入",{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":94,"publishedAt":35},"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",[88,89],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[84,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113],"knowledge","wiki","explore","walkthrough","project","get","knowledge base","run","generate","intent","cli","map","documentation","project wiki","disk","architecture","code","unknown","generated",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":124,"publishedAt":35},"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",[120,121],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":122,"categoryName":123,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000036","内容创作者",[116,125,126,127,128,129,130,131,103,132,133,134,31,30,135,136,137,138],"user","content","视频","creator","generate video","videos","launch","video content","create","upload","auto","types","Video","创作",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":146,"publishedAt":35},"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",[145],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[147,148,116,149,150,137,151,152,153,154,155,156,157,158,101,159,31,30,95,160],"sync","script","youtube script sync","recording","shorts","first","base","person","update","active","child","optimize","idempotent","long",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":171,"publishedAt":35},"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",[167,168,169,170],{"categoryNo":72,"categoryName":73,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},{"categoryNo":122,"categoryName":123,"taxonomyType":92,"taxonomyTypeDesc":93},[172,80,34,173,174,175,111,31,30,176,177,178,179],"writing skills","teach","write skill","write","claude code skills","files","how to","trigger",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":188,"publishedAt":35},"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",[186,187],{"categoryNo":72,"categoryName":73,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":122,"categoryName":123,"taxonomyType":92,"taxonomyTypeDesc":93},[189,80,190,99,191,177,31,34,175,30,178],"Rules","writing rules","project rules"]