[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70HZYVQDXFTS8RZRP4N633W":3,"skill-same:01M70HZYVQDXFTS8RZRP4N633W":88},{"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":31,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":59,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M70HZYVQDXFTS8RZRP4N633W","technical-writing",null,"Create architectural decision records (ADRs), system documentation, API documentation, and operational runbooks. Use when capturing design decisions, documenting system architecture, creating API references, or writing operational procedures.","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\u002Frsmdt-the-startup\u002Fplugins\u002Fteam\u002Fskills\u002Fdevelopment\u002Ftechnical-writing\u002FSKILL.md",[18,23,28],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":29,"categoryName":30,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"writing","technical writing","technical","references","create","documentation","api","architecture","decisions","when","use","design","decision","runbooks","records","system","api documentation","2026-11-10 10:12:30",false,"---\nname: technical-writing\ndescription: Create architectural decision records (ADRs), system documentation, API documentation, and operational runbooks. Use when capturing design decisions, documenting system architecture, creating API references, or writing operational procedures.\n---\n\n# Documentation Creation\n\nA development skill for creating and maintaining technical documentation that preserves knowledge, enables informed decision-making, and supports system operations. This skill provides templates and patterns for common documentation needs.\n\n## When to Use\n\n- Recording architectural or design decisions with context and rationale\n- Documenting system architecture for new team members or stakeholders\n- Creating API documentation for internal or external consumers\n- Writing runbooks for operational procedures and incident response\n- Capturing tribal knowledge before it's lost to team changes\n\n## Core Documentation Types\n\n### Architecture Decision Records (ADRs)\n\nADRs capture the context, options considered, and rationale behind significant architectural decisions. They serve as a historical record that helps future developers understand why the system is built a certain way.\n\n**When to create an ADR:**\n\n- Choosing between different technologies, frameworks, or approaches\n- Making decisions that are difficult or expensive to reverse\n- Establishing patterns that will be followed across the codebase\n- Deprecating existing approaches in favor of new ones\n- Any decision that a future developer might question\n\nSee: `templates\u002Fadr-template.md`\n\n### System Documentation\n\nSystem documentation provides a comprehensive view of how a system works, its components, and their relationships. It helps new team members onboard and serves as a reference for operations.\n\n**Key elements:**\n\n- System overview and purpose\n- Architecture diagrams showing component relationships\n- Data flows and integration points\n- Deployment architecture\n- Operational requirements\n\nSee: `templates\u002Fsystem-doc-template.md`\n\n### API Documentation\n\nAPI documentation describes how to interact with a service, including endpoints, request\u002Fresponse formats, authentication, and error handling.\n\n**Key elements:**\n\n- Authentication and authorization\n- Endpoint reference with examples\n- Request and response schemas\n- Error codes and handling\n- Rate limits and quotas\n- Versioning strategy\n\n### Runbooks\n\nRunbooks provide step-by-step procedures for operational tasks, from routine maintenance to incident response.\n\n**Key elements:**\n\n- Pre-requisites and access requirements\n- Step-by-step procedures with expected outcomes\n- Troubleshooting common issues\n- Escalation paths\n- Recovery procedures\n\n## Documentation Patterns\n\n### Pattern 1: Decision Context First\n\nAlways document the context and constraints that led to a decision before stating the decision itself. Future readers need to understand the \"why\" before the \"what.\"\n\n```markdown\n## Context\n\nWe need to store user session data that must be:\n- Available across multiple application instances\n- Retrieved in under 10ms\n- Retained for 24 hours after last activity\n\nOur current database is PostgreSQL, which would require additional\ninfrastructure for session management.\n\n## Decision\n\nWe will use Redis for session storage.\n```\n\n### Pattern 2: Living Documentation\n\nDocumentation should be updated as part of the development process, not as an afterthought. Integrate documentation updates into your definition of done.\n\n- Update ADRs when decisions change (mark old ones as superseded)\n- Revise system docs when architecture evolves\n- Keep API docs in sync with implementation (prefer generated docs where possible)\n- Review runbooks after each incident for accuracy\n\n### Pattern 3: Audience-Appropriate Detail\n\nTailor documentation depth to its intended audience:\n\n| Audience | Focus | Detail Level |\n|----------|-------|--------------|\n| New developers | Onboarding, getting started | High-level concepts, step-by-step guides |\n| Experienced team | Reference, troubleshooting | Technical details, edge cases |\n| Operations | Deployment, monitoring | Procedures, commands, expected outputs |\n| Business stakeholders | Capabilities, limitations | Non-technical summaries, diagrams |\n\n### Pattern 4: Diagrams Over Prose\n\nUse diagrams to communicate complex relationships. A well-designed diagram can replace pages of text and is easier to maintain.\n\n**Recommended diagram types:**\n\n- **System context**: Shows system boundaries and external interactions\n- **Container**: Shows major components and their relationships\n- **Sequence**: Shows how components interact for specific flows\n- **Data flow**: Shows how data moves through the system\n\n### Pattern 5: Executable Documentation\n\nWhere possible, make documentation executable or verifiable:\n\n- API examples that can be run against a test environment\n- Code snippets that are extracted from actual tested code\n- Configuration examples that are validated in CI\n- Runbook steps that have been recently executed\n\n## ADR Lifecycle\n\nADRs follow a specific lifecycle:\n\n1. **Proposed**: Decision is being discussed, not yet accepted\n2. **Accepted**: Decision has been made and should be followed\n3. **Deprecated**: Decision is being phased out, new work should not follow it\n4. **Superseded**: Decision has been replaced by a newer ADR (link to new one)\n\nWhen superseding an ADR:\n- Add \"Superseded by ADR-XXX\" to the old record\n- Add \"Supersedes ADR-YYY\" to the new record\n- Explain what changed and why in the new ADR's context\n\n## Best Practices\n\n- Write documentation close to the code it describes (prefer docs-as-code)\n- Use templates consistently to make documentation predictable\n- Include diagrams for architecture; text for procedures\n- Date all documents and note last review date\n- Keep ADRs immutable once accepted (create new ones to supersede)\n- Store documentation in version control alongside code\n- Review documentation accuracy during code reviews\n- Delete or archive documentation for removed features\n\n## Anti-Patterns to Avoid\n\n- **Documentation Drift**: Docs that no longer match reality are worse than no docs\n- **Over-Documentation**: Documenting obvious code reduces signal-to-noise\n- **Wiki Sprawl**: Documentation scattered across multiple systems becomes unfindable\n- **Future Fiction**: Documenting features that don't exist yet as if they do\n- **Write-Only Docs**: Creating docs that no one reads or maintains\n\n## References\n\n- `templates\u002Fadr-template.md` - Architecture Decision Record template\n- `templates\u002Fsystem-doc-template.md` - System documentation template\n","# Documentation Creation\n\nA development skill for creating and maintaining technical documentation that preserves knowledge, enables informed decision-making, and supports system operations. This skill provides templates and patterns for common documentation needs.\n\n## When to Use\n\n- Recording architectural or design decisions with context and rationale\n- Documenting system architecture for new team members or stakeholders\n- Creating API documentation for internal or external consumers\n- Writing runbooks for operational procedures and incident response\n- Capturing tribal knowledge before it's lost to team changes\n\n## Core Documentation Types\n\n### Architecture Decision Records (ADRs)\n\nADRs capture the context, options considered, and rationale behind significant architectural decisions. They serve as a historical record that helps future developers understand why the system is built a certain way.\n\n**When to create an ADR:**\n\n- Choosing between different technologies, frameworks, or approaches\n- Making decisions that are difficult or expensive to reverse\n- Establishing patterns that will be followed across the codebase\n- Deprecating existing approaches in favor of new ones\n- Any decision that a future developer might question\n\nSee: `templates\u002Fadr-template.md`\n\n### System Documentation\n\nSystem documentation provides a comprehensive view of how a system works, its components, and their relationships. It helps new team members onboard and serves as a reference for operations.\n\n**Key elements:**\n\n- System overview and purpose\n- Architecture diagrams showing component relationships\n- Data flows and integration points\n- Deployment architecture\n- Operational requirements\n\nSee: `templates\u002Fsystem-doc-template.md`\n\n### API Documentation\n\nAPI documentation describes how to interact with a service, including endpoints, request\u002Fresponse formats, authentication, and error handling.\n\n**Key elements:**\n\n- Authentication and authorization\n- Endpoint reference with examples\n- Request and response schemas\n- Error codes and handling\n- Rate limits and quotas\n- Versioning strategy\n\n### Runbooks\n\nRunbooks provide step-by-step procedures for operational tasks, from routine maintenance to incident response.\n\n**Key elements:**\n\n- Pre-requisites and access requirements\n- Step-by-step procedures with expected outcomes\n- Troubleshooting common issues\n- Escalation paths\n- Recovery procedures\n\n## Documentation Patterns\n\n### Pattern 1: Decision Context First\n\nAlways document the context and constraints that led to a decision before stating the decision itself. Future readers need to understand the \"why\" before the \"what.\"\n\n```markdown\n## Context\n\nWe need to store user session data that must be:\n- Available across multiple application instances\n- Retrieved in under 10ms\n- Retained for 24 hours after last activity\n\nOur current database is PostgreSQL, which would require additional\ninfrastructure for session management.\n\n## Decision\n\nWe will use Redis for session storage.\n```\n\n### Pattern 2: Living Documentation\n\nDocumentation should be updated as part of the development process, not as an afterthought. Integrate documentation updates into your definition of done.\n\n- Update ADRs when decisions change (mark old ones as superseded)\n- Revise system docs when architecture evolves\n- Keep API docs in sync with implementation (prefer generated docs where possible)\n- Review runbooks after each incident for accuracy\n\n### Pattern 3: Audience-Appropriate Detail\n\nTailor documentation depth to its intended audience:\n\n| Audience | Focus | Detail Level |\n|----------|-------|--------------|\n| New developers | Onboarding, getting started | High-level concepts, step-by-step guides |\n| Experienced team | Reference, troubleshooting | Technical details, edge cases |\n| Operations | Deployment, monitoring | Procedures, commands, expected outputs |\n| Business stakeholders | Capabilities, limitations | Non-technical summaries, diagrams |\n\n### Pattern 4: Diagrams Over Prose\n\nUse diagrams to communicate complex relationships. A well-designed diagram can replace pages of text and is easier to maintain.\n\n**Recommended diagram types:**\n\n- **System context**: Shows system boundaries and external interactions\n- **Container**: Shows major components and their relationships\n- **Sequence**: Shows how components interact for specific flows\n- **Data flow**: Shows how data moves through the system\n\n### Pattern 5: Executable Documentation\n\nWhere possible, make documentation executable or verifiable:\n\n- API examples that can be run against a test environment\n- Code snippets that are extracted from actual tested code\n- Configuration examples that are validated in CI\n- Runbook steps that have been recently executed\n\n## ADR Lifecycle\n\nADRs follow a specific lifecycle:\n\n1. **Proposed**: Decision is being discussed, not yet accepted\n2. **Accepted**: Decision has been made and should be followed\n3. **Deprecated**: Decision is being phased out, new work should not follow it\n4. **Superseded**: Decision has been replaced by a newer ADR (link to new one)\n\nWhen superseding an ADR:\n- Add \"Superseded by ADR-XXX\" to the old record\n- Add \"Supersedes ADR-YYY\" to the new record\n- Explain what changed and why in the new ADR's context\n\n## Best Practices\n\n- Write documentation close to the code it describes (prefer docs-as-code)\n- Use templates consistently to make documentation predictable\n- Include diagrams for architecture; text for procedures\n- Date all documents and note last review date\n- Keep ADRs immutable once accepted (create new ones to supersede)\n- Store documentation in version control alongside code\n- Review documentation accuracy during code reviews\n- Delete or archive documentation for removed features\n\n## Anti-Patterns to Avoid\n\n- **Documentation Drift**: Docs that no longer match reality are worse than no docs\n- **Over-Documentation**: Documenting obvious code reduces signal-to-noise\n- **Wiki Sprawl**: Documentation scattered across multiple systems becomes unfindable\n- **Future Fiction**: Documenting features that don't exist yet as if they do\n- **Write-Only Docs**: Creating docs that no one reads or maintains\n\n## References\n\n- `templates\u002Fadr-template.md` - Architecture Decision Record template\n- `templates\u002Fsystem-doc-template.md` - System documentation template\n",{"name":5,"description":7},"main","7850740bd837adb32f0a109ab2af82482196c6f2","skills\u002F_collections\u002Frsmdt-the-startup\u002Fplugins\u002Fteam\u002Fskills\u002Fdevelopment\u002Ftechnical-writing",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":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add shengdabai\u002FTony-Claude-Code-Skills --skill technical-writing",{"tool":70,"command":71},"bunx","bunx skills add shengdabai\u002FTony-Claude-Code-Skills --skill technical-writing",{"tool":73,"command":74},"pnpm","pnpm dlx skills add shengdabai\u002FTony-Claude-Code-Skills --skill technical-writing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Frsmdt-the-startup\u002Fplugins\u002Fteam\u002Fskills\u002Fdevelopment\u002Ftechnical-writing\u002FSKILL.md",true,[78,84],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"templates\u002Fadr-template.md","REFERENCE","参考文档",5356,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Frsmdt-the-startup\u002Fplugins\u002Fteam\u002Fskills\u002Fdevelopment\u002Ftechnical-writing\u002Ftemplates\u002Fadr-template.md",{"path":85,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":86,"sourceHtmlUrl":87},"templates\u002Fsystem-doc-template.md",11721,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Frsmdt-the-startup\u002Fplugins\u002Fteam\u002Fskills\u002Fdevelopment\u002Ftechnical-writing\u002Ftemplates\u002Fsystem-doc-template.md",[89,103,131,153,175,195],{"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":96,"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",[95],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[97,98,99,100,101,32,102],"methodology","xiaolai","xiaolai methodology","朋友","投资","收入",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":113,"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",[109,112],{"categoryNo":110,"categoryName":111,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[105,114,115,116,117,118,119,120,121,122,123,124,125,37,126,127,39,128,129,130],"knowledge","wiki","explore","walkthrough","project","get","knowledge base","run","generate","intent","cli","map","project wiki","disk","code","unknown","generated",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":139,"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",[137,138],{"categoryNo":110,"categoryName":111,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":29,"categoryName":30,"taxonomyType":26,"taxonomyTypeDesc":27},[133,140,141,142,143,144,145,146,122,147,36,148,41,42,149,150,151,152],"user","content","视频","creator","generate video","videos","launch","video content","upload","auto","types","Video","创作",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":160,"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",[159],{"categoryNo":110,"categoryName":111,"taxonomyType":21,"taxonomyTypeDesc":22},[161,162,133,163,164,151,165,166,167,168,169,170,171,172,120,173,41,42,114,174],"sync","script","youtube script sync","recording","shorts","first","base","person","update","active","child","optimize","idempotent","long",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":185,"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",[181,182,183,184],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":110,"categoryName":111,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},{"categoryNo":29,"categoryName":30,"taxonomyType":26,"taxonomyTypeDesc":27},[186,32,187,188,189,190,128,41,42,191,192,193,194],"writing skills","how","teach","write skill","write","claude code skills","files","how to","trigger",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":203,"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",[201,202],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":29,"categoryName":30,"taxonomyType":26,"taxonomyTypeDesc":27},[204,32,205,118,206,192,41,187,190,42,193],"Rules","writing rules","project rules"]