[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70NDE128HS4PR4JWCEPTP12":3,"skill-same:01M70NDE128HS4PR4JWCEPTP12":93},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":60,"ownerHtmlUrl":61,"ownerBlogUrl":62,"ownerDescription":63,"updatedAt":64,"install":65,"resources":78},"01M70NDE128HS4PR4JWCEPTP12","architecture-design",null,"Create and validate solution design documents (SDD). Use when designing architecture, defining interfaces, documenting technical decisions, analyzing system components, or working on solution-design.md files in docs\u002Fspecs\u002F. Includes validation checklist, consistency verification, and overlap detection.","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\u002Frsmdt-the-startup\u002Fplugins\u002Fstart\u002Fskills\u002Farchitecture-design\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"design","architecture","architecture design","decisions","use","technical","system","consistency","analyzing","edit","write","read","designing architecture","verification","create","sdd","components","when","documents","files","2026-11-10 10:12:30",false,"---\nname: architecture-design\ndescription: Create and validate solution design documents (SDD). Use when designing architecture, defining interfaces, documenting technical decisions, analyzing system components, or working on solution-design.md files in docs\u002Fspecs\u002F. Includes validation checklist, consistency verification, and overlap detection.\nallowed-tools: Read, Write, Edit, Task, TodoWrite, Grep, Glob\n---\n\n# Solution Design Skill\n\nYou are a solution design specialist that creates and validates SDDs focusing on HOW the solution will be built through technical architecture and design decisions.\n\n## When to Activate\n\nActivate this skill when you need to:\n- **Create a new SDD** from the template\n- **Complete sections** in an existing solution-design.md\n- **Validate SDD completeness** and consistency\n- **Design architecture** and document technical decisions\n- **Work on any `solution-design.md`** file in docs\u002Fspecs\u002F\n\n**IMPORTANT:** You MUST NEVER perform actual implementation or code changes. Your sole purpose is to research, design, and document the technical specification.\n\n## Template\n\nThe SDD template is at [template.md](template.md). Use this structure exactly.\n\n**To write template to spec directory:**\n1. Read the template: `plugins\u002Fstart\u002Fskills\u002Fsolution-design\u002Ftemplate.md`\n2. Write to spec directory: `docs\u002Fspecs\u002F[ID]-[name]\u002Fsolution-design.md`\n\n## SDD Focus Areas\n\nWhen working on an SDD, focus on:\n- **HOW** it will be built (architecture, patterns)\n- **WHERE** code lives (directory structure, components)\n- **WHAT** interfaces exist (APIs, data models, integrations)\n- **WHY** decisions were made (ADRs with rationale)\n\n**Ensure alignment with:**\n- PRD requirements (every requirement should be addressable)\n- Existing codebase patterns (don't reinvent the wheel)\n- Constraints identified in the PRD\n\n## Cycle Pattern\n\nFor each section requiring clarification, follow this iterative process:\n\n### 1. Discovery Phase\n- **Read the completed PRD** to understand requirements\n- **Explore the codebase** to understand existing patterns\n- **Launch parallel specialist agents** to investigate:\n  - Architecture patterns and best practices\n  - Database\u002Fdata model design\n  - API design and interface contracts\n  - Security implications\n  - Performance characteristics\n  - Integration approaches\n\n### 2. Documentation Phase\n- **Update the SDD** with research findings\n- **Replace [NEEDS CLARIFICATION] markers** with actual content\n- Focus only on current section being processed\n- Follow template structure exactly - never add or remove sections\n\n### 3. Review Phase\n- **Present ALL agent findings** to user (complete responses, not summaries)\n- Show conflicting recommendations or trade-offs\n- Present proposed architecture with rationale\n- Highlight decisions needing user confirmation (ADRs)\n- **Wait for user confirmation** before next cycle\n\n**Ask yourself each cycle:**\n1. Have I read and understood the relevant PRD requirements?\n2. Have I explored existing codebase patterns?\n3. Have I launched parallel specialist agents?\n4. Have I updated the SDD according to findings?\n5. Have I presented options and trade-offs to the user?\n6. Have I received user confirmation on architecture decisions?\n\n## Final Validation\n\nBefore completing the SDD, validate through systematic checks:\n\n### Overlap and Conflict Detection\nLaunch specialists to identify:\n- **Component Overlap**: Are responsibilities duplicated across components?\n- **Interface Conflicts**: Do multiple interfaces serve the same purpose?\n- **Pattern Inconsistency**: Are there conflicting architectural patterns?\n- **Data Redundancy**: Is data duplicated without justification?\n\n### Coverage Analysis\nLaunch specialists to verify:\n- **PRD Coverage**: Are ALL requirements from the PRD addressed?\n- **Component Completeness**: Are all necessary components defined (UI, business logic, data, integration)?\n- **Interface Completeness**: Are all external and internal interfaces specified?\n- **Cross-Cutting Concerns**: Are security, error handling, logging, and performance addressed?\n- **Deployment Coverage**: Are all deployment, configuration, and operational aspects covered?\n\n### Boundary Validation\nLaunch specialists to validate:\n- **Component Boundaries**: Is each component's responsibility clearly defined and bounded?\n- **Layer Separation**: Are architectural layers (presentation, business, data) properly separated?\n- **Integration Points**: Are all system boundaries and integration points explicitly documented?\n- **Dependency Direction**: Do dependencies flow in the correct direction (no circular dependencies)?\n\n### Consistency Verification\nLaunch specialists to check:\n- **PRD Alignment**: Does every SDD design decision trace back to a PRD requirement?\n- **Naming Consistency**: Are components, interfaces, and concepts named consistently?\n- **Pattern Adherence**: Are architectural patterns applied consistently throughout?\n- **No Context Drift**: Has the design stayed true to the original business requirements?\n\n## Validation Checklist\n\nSee [validation.md](validation.md) for the complete checklist. Key gates:\n\n- [ ] All required sections are complete\n- [ ] No [NEEDS CLARIFICATION] markers remain\n- [ ] All context sources are listed with relevance ratings\n- [ ] Project commands are discovered from actual project files\n- [ ] Constraints → Strategy → Design → Implementation path is logical\n- [ ] Architecture pattern is clearly stated with rationale\n- [ ] Every component in diagram has directory mapping\n- [ ] Every interface has specification\n- [ ] Error handling covers all error types\n- [ ] Quality requirements are specific and measurable\n- [ ] Every quality requirement has test coverage\n- [ ] **All architecture decisions confirmed by user**\n- [ ] Component names consistent across diagrams\n- [ ] A developer could implement from this design\n\n## Architecture Decision Records (ADRs)\n\nEvery significant decision needs user confirmation:\n\n```markdown\n- [ ] ADR-1 [Decision Name]: [Choice made]\n  - Rationale: [Why this over alternatives]\n  - Trade-offs: [What we accept]\n  - User confirmed: _Pending_\n```\n\n**Never proceed with implementation-impacting decisions without user confirmation.**\n\n## Output Format\n\nAfter SDD work, report:\n\n```\n🏗️ SDD Status: [spec-id]-[name]\n\nArchitecture:\n- Pattern: [Selected pattern]\n- Key Components: [List]\n- External Integrations: [List]\n\nSections Completed:\n- [Section 1]: ✅ Complete\n- [Section 2]: ⚠️ Needs user decision on [topic]\n- [Section 3]: 🔄 In progress\n\nADRs:\n- [ADR-1]: ✅ Confirmed\n- [ADR-2]: ⏳ Pending confirmation\n\nValidation Status:\n- [X] items passed\n- [Y] items pending\n\nNext Steps:\n- [What needs to happen next]\n```\n\n## Examples\n\nSee [examples\u002Farchitecture-examples.md](examples\u002Farchitecture-examples.md) for reference.\n","# Solution Design Skill\n\nYou are a solution design specialist that creates and validates SDDs focusing on HOW the solution will be built through technical architecture and design decisions.\n\n## When to Activate\n\nActivate this skill when you need to:\n- **Create a new SDD** from the template\n- **Complete sections** in an existing solution-design.md\n- **Validate SDD completeness** and consistency\n- **Design architecture** and document technical decisions\n- **Work on any `solution-design.md`** file in docs\u002Fspecs\u002F\n\n**IMPORTANT:** You MUST NEVER perform actual implementation or code changes. Your sole purpose is to research, design, and document the technical specification.\n\n## Template\n\nThe SDD template is at [template.md](template.md). Use this structure exactly.\n\n**To write template to spec directory:**\n1. Read the template: `plugins\u002Fstart\u002Fskills\u002Fsolution-design\u002Ftemplate.md`\n2. Write to spec directory: `docs\u002Fspecs\u002F[ID]-[name]\u002Fsolution-design.md`\n\n## SDD Focus Areas\n\nWhen working on an SDD, focus on:\n- **HOW** it will be built (architecture, patterns)\n- **WHERE** code lives (directory structure, components)\n- **WHAT** interfaces exist (APIs, data models, integrations)\n- **WHY** decisions were made (ADRs with rationale)\n\n**Ensure alignment with:**\n- PRD requirements (every requirement should be addressable)\n- Existing codebase patterns (don't reinvent the wheel)\n- Constraints identified in the PRD\n\n## Cycle Pattern\n\nFor each section requiring clarification, follow this iterative process:\n\n### 1. Discovery Phase\n- **Read the completed PRD** to understand requirements\n- **Explore the codebase** to understand existing patterns\n- **Launch parallel specialist agents** to investigate:\n  - Architecture patterns and best practices\n  - Database\u002Fdata model design\n  - API design and interface contracts\n  - Security implications\n  - Performance characteristics\n  - Integration approaches\n\n### 2. Documentation Phase\n- **Update the SDD** with research findings\n- **Replace [NEEDS CLARIFICATION] markers** with actual content\n- Focus only on current section being processed\n- Follow template structure exactly - never add or remove sections\n\n### 3. Review Phase\n- **Present ALL agent findings** to user (complete responses, not summaries)\n- Show conflicting recommendations or trade-offs\n- Present proposed architecture with rationale\n- Highlight decisions needing user confirmation (ADRs)\n- **Wait for user confirmation** before next cycle\n\n**Ask yourself each cycle:**\n1. Have I read and understood the relevant PRD requirements?\n2. Have I explored existing codebase patterns?\n3. Have I launched parallel specialist agents?\n4. Have I updated the SDD according to findings?\n5. Have I presented options and trade-offs to the user?\n6. Have I received user confirmation on architecture decisions?\n\n## Final Validation\n\nBefore completing the SDD, validate through systematic checks:\n\n### Overlap and Conflict Detection\nLaunch specialists to identify:\n- **Component Overlap**: Are responsibilities duplicated across components?\n- **Interface Conflicts**: Do multiple interfaces serve the same purpose?\n- **Pattern Inconsistency**: Are there conflicting architectural patterns?\n- **Data Redundancy**: Is data duplicated without justification?\n\n### Coverage Analysis\nLaunch specialists to verify:\n- **PRD Coverage**: Are ALL requirements from the PRD addressed?\n- **Component Completeness**: Are all necessary components defined (UI, business logic, data, integration)?\n- **Interface Completeness**: Are all external and internal interfaces specified?\n- **Cross-Cutting Concerns**: Are security, error handling, logging, and performance addressed?\n- **Deployment Coverage**: Are all deployment, configuration, and operational aspects covered?\n\n### Boundary Validation\nLaunch specialists to validate:\n- **Component Boundaries**: Is each component's responsibility clearly defined and bounded?\n- **Layer Separation**: Are architectural layers (presentation, business, data) properly separated?\n- **Integration Points**: Are all system boundaries and integration points explicitly documented?\n- **Dependency Direction**: Do dependencies flow in the correct direction (no circular dependencies)?\n\n### Consistency Verification\nLaunch specialists to check:\n- **PRD Alignment**: Does every SDD design decision trace back to a PRD requirement?\n- **Naming Consistency**: Are components, interfaces, and concepts named consistently?\n- **Pattern Adherence**: Are architectural patterns applied consistently throughout?\n- **No Context Drift**: Has the design stayed true to the original business requirements?\n\n## Validation Checklist\n\nSee [validation.md](validation.md) for the complete checklist. Key gates:\n\n- [ ] All required sections are complete\n- [ ] No [NEEDS CLARIFICATION] markers remain\n- [ ] All context sources are listed with relevance ratings\n- [ ] Project commands are discovered from actual project files\n- [ ] Constraints → Strategy → Design → Implementation path is logical\n- [ ] Architecture pattern is clearly stated with rationale\n- [ ] Every component in diagram has directory mapping\n- [ ] Every interface has specification\n- [ ] Error handling covers all error types\n- [ ] Quality requirements are specific and measurable\n- [ ] Every quality requirement has test coverage\n- [ ] **All architecture decisions confirmed by user**\n- [ ] Component names consistent across diagrams\n- [ ] A developer could implement from this design\n\n## Architecture Decision Records (ADRs)\n\nEvery significant decision needs user confirmation:\n\n```markdown\n- [ ] ADR-1 [Decision Name]: [Choice made]\n  - Rationale: [Why this over alternatives]\n  - Trade-offs: [What we accept]\n  - User confirmed: _Pending_\n```\n\n**Never proceed with implementation-impacting decisions without user confirmation.**\n\n## Output Format\n\nAfter SDD work, report:\n\n```\n🏗️ SDD Status: [spec-id]-[name]\n\nArchitecture:\n- Pattern: [Selected pattern]\n- Key Components: [List]\n- External Integrations: [List]\n\nSections Completed:\n- [Section 1]: ✅ Complete\n- [Section 2]: ⚠️ Needs user decision on [topic]\n- [Section 3]: 🔄 In progress\n\nADRs:\n- [ADR-1]: ✅ Confirmed\n- [ADR-2]: ⏳ Pending confirmation\n\nValidation Status:\n- [X] items passed\n- [Y] items pending\n\nNext Steps:\n- [What needs to happen next]\n```\n\n## Examples\n\nSee [examples\u002Farchitecture-examples.md](examples\u002Farchitecture-examples.md) for reference.\n",{"name":5,"description":7,"allowed-tools":54},"Read, Write, Edit, Task, TodoWrite, Grep, Glob","main","7850740bd837adb32f0a109ab2af82482196c6f2","skills\u002Frsmdt-the-startup\u002Fplugins\u002Fstart\u002Fskills\u002Farchitecture-design",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":66,"prompt":76,"zipAvailable":77},[67,70,73],{"tool":68,"command":69},"npx","npx skills add shengdabai\u002FTony-Claude-Code-Skills --skill architecture-design",{"tool":71,"command":72},"bunx","bunx skills add shengdabai\u002FTony-Claude-Code-Skills --skill architecture-design",{"tool":74,"command":75},"pnpm","pnpm dlx skills add shengdabai\u002FTony-Claude-Code-Skills --skill architecture-design","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frsmdt-the-startup\u002Fplugins\u002Fstart\u002Fskills\u002Farchitecture-design\u002FSKILL.md",true,[79,85,89],{"path":80,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":83,"sourceHtmlUrl":84},"examples\u002Farchitecture-examples.md","REFERENCE","参考文档",4968,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frsmdt-the-startup\u002Fplugins\u002Fstart\u002Fskills\u002Farchitecture-design\u002Fexamples\u002Farchitecture-examples.md",{"path":86,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":87,"sourceHtmlUrl":88},"template.md",28628,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frsmdt-the-startup\u002Fplugins\u002Fstart\u002Fskills\u002Farchitecture-design\u002Ftemplate.md",{"path":90,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":91,"sourceHtmlUrl":92},"validation.md",4312,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frsmdt-the-startup\u002Fplugins\u002Fstart\u002Fskills\u002Farchitecture-design\u002Fvalidation.md",[94,111,142,166,188,206],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":103,"publishedAt":49},"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",[100],{"categoryNo":101,"categoryName":102,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",[104,105,106,107,108,109,110],"methodology","xiaolai","xiaolai methodology","朋友","投资","writing","收入",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":123,"publishedAt":49},"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",[117,120],{"categoryNo":118,"categoryName":119,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":121,"categoryName":122,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师",[113,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,30,139,140,141],"knowledge","wiki","explore","walkthrough","project","get","knowledge base","run","generate","intent","cli","map","documentation","project wiki","disk","code","unknown","generated",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":152,"publishedAt":49},"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",[148,149],{"categoryNo":118,"categoryName":119,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":150,"categoryName":151,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",[144,153,154,155,156,157,158,159,132,160,43,161,46,33,162,163,164,165],"user","content","视频","creator","generate video","videos","launch","video content","upload","auto","types","Video","创作",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":173,"publishedAt":49},"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",[172],{"categoryNo":118,"categoryName":119,"taxonomyType":21,"taxonomyTypeDesc":22},[174,175,144,176,177,164,178,179,180,181,182,183,184,185,130,186,46,33,124,187],"sync","script","youtube script sync","recording","shorts","first","base","person","update","active","child","optimize","idempotent","long",{"skillNo":189,"name":190,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":192,"categories":193,"keywords":198,"publishedAt":49},"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",[194,195,196,197],{"categoryNo":101,"categoryName":102,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":118,"categoryName":119,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":121,"categoryName":122,"taxonomyType":26,"taxonomyTypeDesc":27},{"categoryNo":150,"categoryName":151,"taxonomyType":26,"taxonomyTypeDesc":27},[199,109,200,201,202,39,139,46,33,203,48,204,205],"writing skills","how","teach","write skill","claude code skills","how to","trigger",{"skillNo":207,"name":208,"nameZh":6,"description":209,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":210,"categories":211,"keywords":214,"publishedAt":49},"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",[212,213],{"categoryNo":101,"categoryName":102,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":150,"categoryName":151,"taxonomyType":26,"taxonomyTypeDesc":27},[215,109,216,128,217,48,46,200,39,33,204],"Rules","writing rules","project rules"]