[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JQNFQ47XM7DHSJMG7TY6SC":3,"skill-same:01M6JQNFQ47XM7DHSJMG7TY6SC":108},{"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":26,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":6,"updatedAt":59,"install":60,"resources":73},"01M6JQNFQ47XM7DHSJMG7TY6SC","tdd",null,"Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions \"red-green-refactor\", wants integration tests, or asks for test-first development.","LongLeo287\u002FOmniClaw","LongLeo287","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F141803367?v=4","01M6JK75C62VCNZKR5BRZ386YV","LongLeo","01M6JK75GQ78TSP1ZPXNKK3MCH",9,"MIT","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Ftdd\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[5,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"red-green-refactor","features","bugs","for","with","fix bugs","red","tests","green","build","use","fix","loop","first","refactor","integration","development","integration tests","test","2026-11-10 10:12:30",false,"---\nname: tdd\ndescription: Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions \"red-green-refactor\", wants integration tests, or asks for test-first development.\n---\n\n# Test-Driven Development\n\n## Philosophy\n\n**Core principle**: Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.\n\n**Good tests** are integration-style: they exercise real code paths through public APIs. They describe _what_ the system does, not _how_ it does it. A good test reads like a specification - \"user can checkout with valid cart\" tells you exactly what capability exists. These tests survive refactors because they don't care about internal structure.\n\n**Bad tests** are coupled to implementation. They mock internal collaborators, test private methods, or verify through external means (like querying a database directly instead of using the interface). The warning sign: your test breaks when you refactor, but behavior hasn't changed. If you rename an internal function and tests fail, those tests were testing implementation, not behavior.\n\nSee [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.\n\n## Anti-Pattern: Horizontal Slices\n\n**DO NOT write all tests first, then all implementation.** This is \"horizontal slicing\" - treating RED as \"write all tests\" and GREEN as \"write all code.\"\n\nThis produces **crap tests**:\n\n- Tests written in bulk test _imagined_ behavior, not _actual_ behavior\n- You end up testing the _shape_ of things (data structures, function signatures) rather than user-facing behavior\n- Tests become insensitive to real changes - they pass when behavior breaks, fail when behavior is fine\n- You outrun your headlights, committing to test structure before understanding the implementation\n\n**Correct approach**: Vertical slices via tracer bullets. One test → one implementation → repeat. Each test responds to what you learned from the previous cycle. Because you just wrote the code, you know exactly what behavior matters and how to verify it.\n\n```\nWRONG (horizontal):\n  RED:   test1, test2, test3, test4, test5\n  GREEN: impl1, impl2, impl3, impl4, impl5\n\nRIGHT (vertical):\n  RED→GREEN: test1→impl1\n  RED→GREEN: test2→impl2\n  RED→GREEN: test3→impl3\n  ...\n```\n\n## Workflow\n\n### 1. Planning\n\nBefore writing any code:\n\n- [ ] Confirm with user what interface changes are needed\n- [ ] Confirm with user which behaviors to test (prioritize)\n- [ ] Identify opportunities for [deep modules](deep-modules.md) (small interface, deep implementation)\n- [ ] Design interfaces for [testability](interface-design.md)\n- [ ] List the behaviors to test (not implementation steps)\n- [ ] Get user approval on the plan\n\nAsk: \"What should the public interface look like? Which behaviors are most important to test?\"\n\n**You can't test everything.** Confirm with the user exactly which behaviors matter most. Focus testing effort on critical paths and complex logic, not every possible edge case.\n\n### 2. Tracer Bullet\n\nWrite ONE test that confirms ONE thing about the system:\n\n```\nRED:   Write test for first behavior → test fails\nGREEN: Write minimal code to pass → test passes\n```\n\nThis is your tracer bullet - proves the path works end-to-end.\n\n### 3. Incremental Loop\n\nFor each remaining behavior:\n\n```\nRED:   Write next test → fails\nGREEN: Minimal code to pass → passes\n```\n\nRules:\n\n- One test at a time\n- Only enough code to pass current test\n- Don't anticipate future tests\n- Keep tests focused on observable behavior\n\n### 4. Refactor\n\nAfter all tests pass, look for [refactor candidates](refactoring.md):\n\n- [ ] Extract duplication\n- [ ] Deepen modules (move complexity behind simple interfaces)\n- [ ] Apply SOLID principles where natural\n- [ ] Consider what new code reveals about existing code\n- [ ] Run tests after each refactor step\n\n**Never refactor while RED.** Get to GREEN first.\n\n## Checklist Per Cycle\n\n```\n[ ] Test describes behavior, not implementation\n[ ] Test uses public interface only\n[ ] Test would survive internal refactor\n[ ] Code is minimal for this test\n[ ] No speculative features added\n```\n","# Test-Driven Development\n\n## Philosophy\n\n**Core principle**: Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.\n\n**Good tests** are integration-style: they exercise real code paths through public APIs. They describe _what_ the system does, not _how_ it does it. A good test reads like a specification - \"user can checkout with valid cart\" tells you exactly what capability exists. These tests survive refactors because they don't care about internal structure.\n\n**Bad tests** are coupled to implementation. They mock internal collaborators, test private methods, or verify through external means (like querying a database directly instead of using the interface). The warning sign: your test breaks when you refactor, but behavior hasn't changed. If you rename an internal function and tests fail, those tests were testing implementation, not behavior.\n\nSee [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.\n\n## Anti-Pattern: Horizontal Slices\n\n**DO NOT write all tests first, then all implementation.** This is \"horizontal slicing\" - treating RED as \"write all tests\" and GREEN as \"write all code.\"\n\nThis produces **crap tests**:\n\n- Tests written in bulk test _imagined_ behavior, not _actual_ behavior\n- You end up testing the _shape_ of things (data structures, function signatures) rather than user-facing behavior\n- Tests become insensitive to real changes - they pass when behavior breaks, fail when behavior is fine\n- You outrun your headlights, committing to test structure before understanding the implementation\n\n**Correct approach**: Vertical slices via tracer bullets. One test → one implementation → repeat. Each test responds to what you learned from the previous cycle. Because you just wrote the code, you know exactly what behavior matters and how to verify it.\n\n```\nWRONG (horizontal):\n  RED:   test1, test2, test3, test4, test5\n  GREEN: impl1, impl2, impl3, impl4, impl5\n\nRIGHT (vertical):\n  RED→GREEN: test1→impl1\n  RED→GREEN: test2→impl2\n  RED→GREEN: test3→impl3\n  ...\n```\n\n## Workflow\n\n### 1. Planning\n\nBefore writing any code:\n\n- [ ] Confirm with user what interface changes are needed\n- [ ] Confirm with user which behaviors to test (prioritize)\n- [ ] Identify opportunities for [deep modules](deep-modules.md) (small interface, deep implementation)\n- [ ] Design interfaces for [testability](interface-design.md)\n- [ ] List the behaviors to test (not implementation steps)\n- [ ] Get user approval on the plan\n\nAsk: \"What should the public interface look like? Which behaviors are most important to test?\"\n\n**You can't test everything.** Confirm with the user exactly which behaviors matter most. Focus testing effort on critical paths and complex logic, not every possible edge case.\n\n### 2. Tracer Bullet\n\nWrite ONE test that confirms ONE thing about the system:\n\n```\nRED:   Write test for first behavior → test fails\nGREEN: Write minimal code to pass → test passes\n```\n\nThis is your tracer bullet - proves the path works end-to-end.\n\n### 3. Incremental Loop\n\nFor each remaining behavior:\n\n```\nRED:   Write next test → fails\nGREEN: Minimal code to pass → passes\n```\n\nRules:\n\n- One test at a time\n- Only enough code to pass current test\n- Don't anticipate future tests\n- Keep tests focused on observable behavior\n\n### 4. Refactor\n\nAfter all tests pass, look for [refactor candidates](refactoring.md):\n\n- [ ] Extract duplication\n- [ ] Deepen modules (move complexity behind simple interfaces)\n- [ ] Apply SOLID principles where natural\n- [ ] Consider what new code reveals about existing code\n- [ ] Run tests after each refactor step\n\n**Never refactor while RED.** Get to GREEN first.\n\n## Checklist Per Cycle\n\n```\n[ ] Test describes behavior, not implementation\n[ ] Test uses public interface only\n[ ] Test would survive internal refactor\n[ ] Code is minimal for this test\n[ ] No speculative features added\n```\n",{"name":5,"description":7},"main","c173cdffe08e788a99b91928a831b476b8434838","ecosystem\u002Fskills\u002Ftdd",0,"https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw","https:\u002F\u002Fportfolio-longleo.vercel.app\u002Flabs\u002Fomniclaw.html","https:\u002F\u002Fgithub.com\u002FLongLeo287","https:\u002F\u002Fwww.facebook.com\u002FResourceRookie2023","2026-09-30 00:58:05",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add LongLeo287\u002FOmniClaw --skill tdd",{"tool":66,"command":67},"bunx","bunx skills add LongLeo287\u002FOmniClaw --skill tdd",{"tool":69,"command":70},"pnpm","pnpm dlx skills add LongLeo287\u002FOmniClaw --skill tdd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Ftdd\u002FSKILL.md",true,[74,80,84,88,92,96,100,104],{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"_DIR_IDENTITY.md","REFERENCE","参考文档",288,"https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Ftdd\u002F_DIR_IDENTITY.md",{"path":81,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":82,"sourceHtmlUrl":83},"deep_modules.md",1239,"https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Ftdd\u002Fdeep_modules.md",{"path":85,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":86,"sourceHtmlUrl":87},"interface_design.md",653,"https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Ftdd\u002Finterface_design.md",{"path":89,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":90,"sourceHtmlUrl":91},"mocking.md",1481,"https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Ftdd\u002Fmocking.md",{"path":93,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":94,"sourceHtmlUrl":95},"README.md",441,"https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Ftdd\u002FREADME.md",{"path":97,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":98,"sourceHtmlUrl":99},"refactoring.md",387,"https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Ftdd\u002Frefactoring.md",{"path":101,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":102,"sourceHtmlUrl":103},"schema.json",411,"https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Ftdd\u002Fschema.json",{"path":105,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":106,"sourceHtmlUrl":107},"tests.md",1640,"https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Ftdd\u002Ftests.md",[109,148,168,195,210,237],{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":127,"publishedAt":46},"01M6JR0KQP4MHT32TN40D9CBFX","UI-UX Pro Max","Advanced UI\u002FUX analysis and generation skills with data-driven patterns. Python scripts (core.py, search.py) for systematic UI pattern extraction, design system generation, and component search from curated data sources.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fui_components\u002Fui_ux_pro_max\u002FSKILL.md",[115,118,119,124],{"categoryNo":116,"categoryName":117,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":125,"categoryName":126,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000033","数据分析师",[128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147],"ux","ui","ui ux pro max","max","pro","ui ux","design","component","search","analysis","team","rd","ui-ux","active","systematic","scripts","pattern extraction","sources","advanced","data-driven",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":155,"publishedAt":46},"01M6JR0EF5AEQHP2FSTB57H05P","shadcn-ui","Expert guidance for integrating and building applications with shadcn\u002Fui components, including component discovery, installation, customization, and best practices.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fui_components\u002Fshadcn_ui\u002FSKILL.md",[154],{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},[156,129,157,158,135,159,160,161,162,138,163,164,165,141,166,167,31,30],"shadcn","shadcn ui","components","core","best practices","applications","discovery","customization","guidance","expert","installation","ui components",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":177,"publishedAt":46},"01M6JR08F51BEN17RHFYX65WVE","zustand_store_ts","Create Zustand stores with TypeScript, subscribeWithSelector middleware, and proper state\u002Faction separation. Use when building React state management, creating global stores, or implementing reactive state patterns with Zustand.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fzustand_store_ts\u002FSKILL.md",[174],{"categoryNo":175,"categoryName":176,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[178,179,180,181,182,183,184,185,186,187,188,189,37,190,191,192,31,193,194],"zustand store ts","zustand","store","typescript","microsoft","react","create","state management","state","react state management","management","global","patterns","separation","middleware","action","implementing",{"skillNo":196,"name":179,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":200,"publishedAt":46},"01M6JR00TDMVAFFCZXZ04AN7Q7","Zustand state management guide. Use when working with store code (src\u002Fstore\u002F**), implementing actions, managing state, or creating slices. Triggers on Zustand store development, state management questions, or action implementation.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fzustand\u002FSKILL.md",[],[179,43,185,201,186,202,203,188,204,37,205,206,207,180,31,208,209,193,194],"code","actions","src","guide","implementation","zustand state","triggers","questions","zustand state management",{"skillNo":211,"name":212,"nameZh":6,"description":213,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":214,"categories":215,"keywords":220,"publishedAt":46},"01M6JQZSWV4KWJP112G6XHEP44","youtube_summarizer","Automatically fetch YouTube video transcripts, generate structured summaries, and send full transcripts to messaging platforms. Detects YouTube URLs and provides metadata, key insights, and downloadable transcripts.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fyoutube_summarizer\u002FSKILL.md",[216,219],{"categoryNo":217,"categoryName":218,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236],"youtube","youtube summarizer","summarizer","generate","metadata","messaging","Video","fetch","telegram","transcription","summarization","structured","full","insights","transcripts","summaries",{"skillNo":238,"name":239,"nameZh":6,"description":240,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":241,"categories":242,"keywords":243,"publishedAt":46},"01M6JQZN3QJB6B77JGKJD62DQT","youtube_clipper","YouTube 视频智能剪辑工具。下载视频和字幕，AI 分析生成精细章节（几分钟级别）， 用户选择片段后自动剪辑、翻译字幕为中英双语、烧录字幕到视频，并生成总结文案。 使用场景：当用户需要剪辑 YouTube 视频、生成短视频片段、制作双语字幕版本时。 关键词：视频剪辑、YouTube、字幕翻译、双语字幕、视频下载、clip video","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FOmniClaw\u002Fblob\u002Fmain\u002Fecosystem\u002Fskills\u002Fyoutube_clipper\u002FSKILL.md",[],[221,244,245,227,246,247,248,249,250,251,252,253,254,255,256,257,258],"clipper","youtube clipper","Bash","下载","视频","生成","关键词","翻译","read","write","clip","总结","工具","文案","sonnet"]