[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6EPDJDVZYF7SJAY6AK4THTY":3,"skill-same:01M6EPDJDVZYF7SJAY6AK4THTY":131},{"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":45,"linkOnly":46,"markdownContent":47,"markdownBody":48,"frontMatter":49,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M6EPDJDVZYF7SJAY6AK4THTY","test-driven-development",null,"Red-green-refactor development methodology requiring verified test coverage. Use for feature implementation, bugfixes, refactoring, or any behavior changes where tests must prove correctness.","ComeOnOliver\u002Fskillshub","ComeOnOliver","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F43215937?v=4","01M6E5JNFECJAAVFE0W7SMWWD2","Haoran Shu","01M6E5JNNDQS7AJZDYFQ8TPZCK",67,"MIT","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fcodingcossack\u002Ftest-driven-development\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44],"test driven development","development","test","driven","red","feature","tests","green","feature implementation","implementation","red-green-refactor","test coverage","use","coverage","behavior","refactoring","refactor","methodology","2026-11-10 10:12:30",false,"---\nname: test-driven-development\ndescription: Red-green-refactor development methodology requiring verified test coverage. Use for feature implementation, bugfixes, refactoring, or any behavior changes where tests must prove correctness.\n---\n\n# Test-Driven Development\n\nWrite test first. Watch it fail. Write minimal code to pass. Refactor.\n\n**Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing.\n\n## The Iron Law\n\n```\nNO BEHAVIOR-CHANGING PRODUCTION CODE WITHOUT A FAILING TEST FIRST\n```\n\nWrote code before test? Delete it completely. Implement fresh from tests.\n\n**Refactoring is exempt:** The refactor step changes structure, not behavior. Tests stay green throughout. No new failing test required.\n\n## Red-Green-Refactor Cycle\n\n```\nRED ──► Verify Fail ──► GREEN ──► Verify Pass ──► REFACTOR ──► Verify Pass ──► Next RED\n         │                         │                            │\n         ▼                         ▼                            ▼\n      Wrong failure?           Still failing?              Broke tests?\n      Fix test, retry          Fix code, retry             Fix, retry\n```\n\n### RED - Write Failing Test\n\nWrite one minimal test for one behavior.\n\n**Good example:**\n```typescript\ntest('retries failed operations 3 times', async () => {\n  let attempts = 0;\n  const operation = async () => {\n    attempts++;\n    if (attempts \u003C 3) throw new Error('fail');\n    return 'success';\n  };\n\n  const result = await retryOperation(operation);\n\n  expect(result).toBe('success');\n  expect(attempts).toBe(3);\n});\n```\n*Clear name, tests real behavior, asserts observable outcome*\n\n**Bad example:**\n```typescript\ntest('retry works', async () => {\n  const mock = jest.fn()\n    .mockRejectedValueOnce(new Error())\n    .mockRejectedValueOnce(new Error())\n    .mockResolvedValueOnce('success');\n  await retryOperation(mock);\n  expect(mock).toHaveBeenCalledTimes(3);\n});\n```\n*Vague name, asserts only call count without verifying outcome, tests mock mechanics not behavior*\n\n**Requirements:** One behavior. Clear name. Real code (mocks only if unavoidable).\n\n### Verify RED - Watch It Fail\n\n**MANDATORY. Never skip.**\n\n```bash\nnpm test path\u002Fto\u002Ftest.test.ts\n```\n\nTest must go red for the right reason. Acceptable RED states:\n- Assertion failure (expected behavior missing)\n- Compile\u002Ftype error (function doesn't exist yet)\n\nNot acceptable: Runtime setup errors, import failures, environment issues.\n\nTest passes immediately? You're testing existing behavior—fix test.\nTest errors for wrong reason? Fix error, re-run until it fails correctly.\n\n### GREEN - Minimal Code\n\nWrite simplest code to pass the test.\n\n**Good example:**\n```typescript\nasync function retryOperation\u003CT>(fn: () => Promise\u003CT>): Promise\u003CT> {\n  for (let i = 0; i \u003C 3; i++) {\n    try {\n      return await fn();\n    } catch (e) {\n      if (i === 2) throw e;\n    }\n  }\n  throw new Error('unreachable');\n}\n```\n*Just enough to pass*\n\n**Bad example:**\n```typescript\nasync function retryOperation\u003CT>(\n  fn: () => Promise\u003CT>,\n  options?: { maxRetries?: number; backoff?: 'linear' | 'exponential'; }\n): Promise\u003CT> { \u002F* YAGNI *\u002F }\n```\n*Over-engineered beyond test requirements*\n\nWrite only what the test demands. No extra features, no \"improvements.\"\n\n### Verify GREEN - Watch It Pass\n\n**MANDATORY.**\n\n```bash\nnpm test path\u002Fto\u002Ftest.test.ts\n```\n\nConfirm: Test passes. All other tests still pass. Output pristine (no errors, warnings).\n\nTest fails? Fix code, not test.\nOther tests fail? Fix now before continuing.\n\n### REFACTOR - Clean Up\n\nAfter green only: Remove duplication. Improve names. Extract helpers.\n\nKeep tests green throughout. Add no new behavior.\n\n### Repeat\n\nNext failing test for next behavior.\n\n## Good Tests\n\n**Minimal:** One thing per test. \"and\" in name? Split it. ❌ `test('validates email and domain and whitespace')`\n\n**Clear:** Name describes behavior. ❌ `test('test1')`\n\n**Shows intent:** Demonstrates desired API usage, not implementation details.\n\n## Example: Bug Fix\n\n**Bug:** Empty email accepted\n\n**RED:**\n```typescript\ntest('rejects empty email', async () => {\n  const result = await submitForm({ email: '' });\n  expect(result.error).toBe('Email required');\n});\n```\n\n**Verify RED:**\n```bash\n$ npm test\nFAIL: expected 'Email required', got undefined\n```\n\n**GREEN:**\n```typescript\nfunction submitForm(data: FormData) {\n  if (!data.email?.trim()) {\n    return { error: 'Email required' };\n  }\n  \u002F\u002F ...\n}\n```\n\n**Verify GREEN:**\n```bash\n$ npm test\nPASS\n```\n\n**REFACTOR:** Extract validation helper if pattern repeats.\n\n## Red Flags - STOP and Start Over\n\nAny of these means delete code and restart with TDD:\n\n- Code written before test\n- Test passes immediately (testing existing behavior)\n- Can't explain why test failed\n- Rationalizing \"just this once\" or \"this is different\"\n- Keeping code \"as reference\" while writing tests\n- Claiming \"tests after achieve the same purpose\"\n\n## When Stuck\n\n| Problem | Solution |\n|---------|----------|\n| Don't know how to test | Write the API you wish existed. Write assertion first. |\n| Test too complicated | Design too complicated. Simplify the interface. |\n| Must mock everything | Code too coupled. Introduce dependency injection. |\n| Test setup huge | Extract helpers. Still complex? Simplify design. |\n\n## Legacy Code (No Existing Tests)\n\nThe Iron Law (\"delete and restart\") applies to **new code you wrote without tests**. For inherited code with no tests, use characterization tests:\n\n1. Write tests that capture current behavior (even if \"wrong\")\n2. Run tests, observe actual outputs\n3. Update assertions to match reality (these are \"golden masters\")\n4. Now you have a safety net for refactoring\n5. Apply TDD for new behavior changes\n\nCharacterization tests lock down existing behavior so you can refactor safely. They're the on-ramp, not a permanent state.\n\n## Flakiness Rules\n\nTests must be deterministic. Ban these in unit tests:\n\n- **Real sleeps \u002F delays** → Use fake timers (`vi.useFakeTimers()`, `jest.useFakeTimers()`)\n- **Wall clock time** → Inject clock, assert against injected time\n- **Math.random()** → Seed or inject RNG\n- **Network calls** → Mock at boundary or use MSW\n- **Filesystem race conditions** → Use temp dirs with unique names\n\nFlaky test? Fix or delete. Flaky tests erode trust in the entire suite.\n\n## Debugging Integration\n\nBug found? Write failing test reproducing it first. Then follow TDD cycle. Test proves fix and prevents regression.\n\n## Planning: Test List\n\nBefore diving into the cycle, spend 2 minutes listing the next 3-10 tests you expect to write. This prevents local-optimum design where early tests paint you into a corner.\n\nExample test list for a retry function:\n- retries N times on failure\n- returns result on success\n- throws after max retries exhausted  \n- calls onRetry callback between attempts\n- respects backoff delay\n\nWork through the list in order. Add\u002Fremove tests as you learn.\n\n## Testing Anti-Patterns\n\nWhen writing tests involving mocks, dependencies, or test utilities: See [references\u002Ftesting-anti-patterns.md](references\u002Ftesting-anti-patterns.md) for common pitfalls including testing mock behavior and adding test-only methods to production classes.\n\n## Philosophy and Rationalizations\n\nFor detailed rebuttals to common objections (\"I'll test after\", \"deleting work is wasteful\", \"TDD is dogmatic\"): See [references\u002Ftdd-philosophy.md](references\u002Ftdd-philosophy.md)\n\n## Final Rule\n\n```\nProduction code exists → test existed first and failed first\nOtherwise → not TDD\n```\n","# Test-Driven Development\n\nWrite test first. Watch it fail. Write minimal code to pass. Refactor.\n\n**Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing.\n\n## The Iron Law\n\n```\nNO BEHAVIOR-CHANGING PRODUCTION CODE WITHOUT A FAILING TEST FIRST\n```\n\nWrote code before test? Delete it completely. Implement fresh from tests.\n\n**Refactoring is exempt:** The refactor step changes structure, not behavior. Tests stay green throughout. No new failing test required.\n\n## Red-Green-Refactor Cycle\n\n```\nRED ──► Verify Fail ──► GREEN ──► Verify Pass ──► REFACTOR ──► Verify Pass ──► Next RED\n         │                         │                            │\n         ▼                         ▼                            ▼\n      Wrong failure?           Still failing?              Broke tests?\n      Fix test, retry          Fix code, retry             Fix, retry\n```\n\n### RED - Write Failing Test\n\nWrite one minimal test for one behavior.\n\n**Good example:**\n```typescript\ntest('retries failed operations 3 times', async () => {\n  let attempts = 0;\n  const operation = async () => {\n    attempts++;\n    if (attempts \u003C 3) throw new Error('fail');\n    return 'success';\n  };\n\n  const result = await retryOperation(operation);\n\n  expect(result).toBe('success');\n  expect(attempts).toBe(3);\n});\n```\n*Clear name, tests real behavior, asserts observable outcome*\n\n**Bad example:**\n```typescript\ntest('retry works', async () => {\n  const mock = jest.fn()\n    .mockRejectedValueOnce(new Error())\n    .mockRejectedValueOnce(new Error())\n    .mockResolvedValueOnce('success');\n  await retryOperation(mock);\n  expect(mock).toHaveBeenCalledTimes(3);\n});\n```\n*Vague name, asserts only call count without verifying outcome, tests mock mechanics not behavior*\n\n**Requirements:** One behavior. Clear name. Real code (mocks only if unavoidable).\n\n### Verify RED - Watch It Fail\n\n**MANDATORY. Never skip.**\n\n```bash\nnpm test path\u002Fto\u002Ftest.test.ts\n```\n\nTest must go red for the right reason. Acceptable RED states:\n- Assertion failure (expected behavior missing)\n- Compile\u002Ftype error (function doesn't exist yet)\n\nNot acceptable: Runtime setup errors, import failures, environment issues.\n\nTest passes immediately? You're testing existing behavior—fix test.\nTest errors for wrong reason? Fix error, re-run until it fails correctly.\n\n### GREEN - Minimal Code\n\nWrite simplest code to pass the test.\n\n**Good example:**\n```typescript\nasync function retryOperation\u003CT>(fn: () => Promise\u003CT>): Promise\u003CT> {\n  for (let i = 0; i \u003C 3; i++) {\n    try {\n      return await fn();\n    } catch (e) {\n      if (i === 2) throw e;\n    }\n  }\n  throw new Error('unreachable');\n}\n```\n*Just enough to pass*\n\n**Bad example:**\n```typescript\nasync function retryOperation\u003CT>(\n  fn: () => Promise\u003CT>,\n  options?: { maxRetries?: number; backoff?: 'linear' | 'exponential'; }\n): Promise\u003CT> { \u002F* YAGNI *\u002F }\n```\n*Over-engineered beyond test requirements*\n\nWrite only what the test demands. No extra features, no \"improvements.\"\n\n### Verify GREEN - Watch It Pass\n\n**MANDATORY.**\n\n```bash\nnpm test path\u002Fto\u002Ftest.test.ts\n```\n\nConfirm: Test passes. All other tests still pass. Output pristine (no errors, warnings).\n\nTest fails? Fix code, not test.\nOther tests fail? Fix now before continuing.\n\n### REFACTOR - Clean Up\n\nAfter green only: Remove duplication. Improve names. Extract helpers.\n\nKeep tests green throughout. Add no new behavior.\n\n### Repeat\n\nNext failing test for next behavior.\n\n## Good Tests\n\n**Minimal:** One thing per test. \"and\" in name? Split it. ❌ `test('validates email and domain and whitespace')`\n\n**Clear:** Name describes behavior. ❌ `test('test1')`\n\n**Shows intent:** Demonstrates desired API usage, not implementation details.\n\n## Example: Bug Fix\n\n**Bug:** Empty email accepted\n\n**RED:**\n```typescript\ntest('rejects empty email', async () => {\n  const result = await submitForm({ email: '' });\n  expect(result.error).toBe('Email required');\n});\n```\n\n**Verify RED:**\n```bash\n$ npm test\nFAIL: expected 'Email required', got undefined\n```\n\n**GREEN:**\n```typescript\nfunction submitForm(data: FormData) {\n  if (!data.email?.trim()) {\n    return { error: 'Email required' };\n  }\n  \u002F\u002F ...\n}\n```\n\n**Verify GREEN:**\n```bash\n$ npm test\nPASS\n```\n\n**REFACTOR:** Extract validation helper if pattern repeats.\n\n## Red Flags - STOP and Start Over\n\nAny of these means delete code and restart with TDD:\n\n- Code written before test\n- Test passes immediately (testing existing behavior)\n- Can't explain why test failed\n- Rationalizing \"just this once\" or \"this is different\"\n- Keeping code \"as reference\" while writing tests\n- Claiming \"tests after achieve the same purpose\"\n\n## When Stuck\n\n| Problem | Solution |\n|---------|----------|\n| Don't know how to test | Write the API you wish existed. Write assertion first. |\n| Test too complicated | Design too complicated. Simplify the interface. |\n| Must mock everything | Code too coupled. Introduce dependency injection. |\n| Test setup huge | Extract helpers. Still complex? Simplify design. |\n\n## Legacy Code (No Existing Tests)\n\nThe Iron Law (\"delete and restart\") applies to **new code you wrote without tests**. For inherited code with no tests, use characterization tests:\n\n1. Write tests that capture current behavior (even if \"wrong\")\n2. Run tests, observe actual outputs\n3. Update assertions to match reality (these are \"golden masters\")\n4. Now you have a safety net for refactoring\n5. Apply TDD for new behavior changes\n\nCharacterization tests lock down existing behavior so you can refactor safely. They're the on-ramp, not a permanent state.\n\n## Flakiness Rules\n\nTests must be deterministic. Ban these in unit tests:\n\n- **Real sleeps \u002F delays** → Use fake timers (`vi.useFakeTimers()`, `jest.useFakeTimers()`)\n- **Wall clock time** → Inject clock, assert against injected time\n- **Math.random()** → Seed or inject RNG\n- **Network calls** → Mock at boundary or use MSW\n- **Filesystem race conditions** → Use temp dirs with unique names\n\nFlaky test? Fix or delete. Flaky tests erode trust in the entire suite.\n\n## Debugging Integration\n\nBug found? Write failing test reproducing it first. Then follow TDD cycle. Test proves fix and prevents regression.\n\n## Planning: Test List\n\nBefore diving into the cycle, spend 2 minutes listing the next 3-10 tests you expect to write. This prevents local-optimum design where early tests paint you into a corner.\n\nExample test list for a retry function:\n- retries N times on failure\n- returns result on success\n- throws after max retries exhausted  \n- calls onRetry callback between attempts\n- respects backoff delay\n\nWork through the list in order. Add\u002Fremove tests as you learn.\n\n## Testing Anti-Patterns\n\nWhen writing tests involving mocks, dependencies, or test utilities: See [references\u002Ftesting-anti-patterns.md](references\u002Ftesting-anti-patterns.md) for common pitfalls including testing mock behavior and adding test-only methods to production classes.\n\n## Philosophy and Rationalizations\n\nFor detailed rebuttals to common objections (\"I'll test after\", \"deleting work is wasteful\", \"TDD is dogmatic\"): See [references\u002Ftdd-philosophy.md](references\u002Ftdd-philosophy.md)\n\n## Final Rule\n\n```\nProduction code exists → test existed first and failed first\nOtherwise → not TDD\n```\n",{"name":5,"description":7},"main","def8531e65114c0fca8fb8551c1871ee0eed705c","skills\u002Faiskillstore\u002Fmarketplace\u002Fcodingcossack\u002Ftest-driven-development",24,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub","https:\u002F\u002Fskillshub.wtf","https:\u002F\u002Fgithub.com\u002FComeOnOliver","AI & Blockchain Engineer\r\n","2026-06-24 22:07:19",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add ComeOnOliver\u002Fskillshub --skill test-driven-development",{"tool":65,"command":66},"bunx","bunx skills add ComeOnOliver\u002Fskillshub --skill test-driven-development",{"tool":68,"command":69},"pnpm","pnpm dlx skills add ComeOnOliver\u002Fskillshub --skill test-driven-development","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fcodingcossack\u002Ftest-driven-development\u002FSKILL.md",true,[73,79,83,87,91,95,99,103,107,111,115,119,123,127],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"examples\u002Fclean-pass.md","REFERENCE","参考文档",5818,"https:\u002F\u002Fgithub.com\u002Ftiagoluizpoli\u002Fluna-ai-skills\u002Fblob\u002Fmaster\u002F.agents\u002Fskills\u002Fluna-ai\u002Fcode-review\u002Fexamples\u002Fclean-pass.md",{"path":80,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":81,"sourceHtmlUrl":82},"examples\u002Fdeprecated-migration.md",4617,"https:\u002F\u002Fgithub.com\u002Ftiagoluizpoli\u002Fluna-ai-skills\u002Fblob\u002Fmaster\u002F.agents\u002Fskills\u002Fluna-ai\u002Fcode-review\u002Fexamples\u002Fdeprecated-migration.md",{"path":84,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":85,"sourceHtmlUrl":86},"examples\u002Freact-component-review.md",5188,"https:\u002F\u002Fgithub.com\u002Ftiagoluizpoli\u002Fluna-ai-skills\u002Fblob\u002Fmaster\u002F.agents\u002Fskills\u002Fluna-ai\u002Fcode-review\u002Fexamples\u002Freact-component-review.md",{"path":88,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":89,"sourceHtmlUrl":90},"examples\u002Fsecurity-audit.md",6350,"https:\u002F\u002Fgithub.com\u002Ftiagoluizpoli\u002Fluna-ai-skills\u002Fblob\u002Fmaster\u002F.agents\u002Fskills\u002Fluna-ai\u002Fcode-review\u002Fexamples\u002Fsecurity-audit.md",{"path":92,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Ftdd-philosophy.md",4299,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fcodingcossack\u002Ftest-driven-development\u002Freferences\u002Ftdd-philosophy.md",{"path":96,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Ftesting-anti-patterns.md",6810,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fcodingcossack\u002Ftest-driven-development\u002Freferences\u002Ftesting-anti-patterns.md",{"path":100,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":101,"sourceHtmlUrl":102},"resources\u002Farchitecture-review.md",8574,"https:\u002F\u002Fgithub.com\u002Ftiagoluizpoli\u002Fluna-ai-skills\u002Fblob\u002Fmaster\u002F.agents\u002Fskills\u002Fluna-ai\u002Fcode-review\u002Fresources\u002Farchitecture-review.md",{"path":104,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":105,"sourceHtmlUrl":106},"resources\u002Fcode-quality.md",11664,"https:\u002F\u002Fgithub.com\u002Ftiagoluizpoli\u002Fluna-ai-skills\u002Fblob\u002Fmaster\u002F.agents\u002Fskills\u002Fluna-ai\u002Fcode-review\u002Fresources\u002Fcode-quality.md",{"path":108,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":109,"sourceHtmlUrl":110},"resources\u002Fdeprecated-detection.md",13968,"https:\u002F\u002Fgithub.com\u002Ftiagoluizpoli\u002Fluna-ai-skills\u002Fblob\u002Fmaster\u002F.agents\u002Fskills\u002Fluna-ai\u002Fcode-review\u002Fresources\u002Fdeprecated-detection.md",{"path":112,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":113,"sourceHtmlUrl":114},"resources\u002Fperformance-review.md",8347,"https:\u002F\u002Fgithub.com\u002Ftiagoluizpoli\u002Fluna-ai-skills\u002Fblob\u002Fmaster\u002F.agents\u002Fskills\u002Fluna-ai\u002Fcode-review\u002Fresources\u002Fperformance-review.md",{"path":116,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":117,"sourceHtmlUrl":118},"resources\u002Fsecurity-review.md",9320,"https:\u002F\u002Fgithub.com\u002Ftiagoluizpoli\u002Fluna-ai-skills\u002Fblob\u002Fmaster\u002F.agents\u002Fskills\u002Fluna-ai\u002Fcode-review\u002Fresources\u002Fsecurity-review.md",{"path":120,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":121,"sourceHtmlUrl":122},"resources\u002Ftest-integrity.md",7111,"https:\u002F\u002Fgithub.com\u002Ftiagoluizpoli\u002Fluna-ai-skills\u002Fblob\u002Fmaster\u002F.agents\u002Fskills\u002Fluna-ai\u002Fcode-review\u002Fresources\u002Ftest-integrity.md",{"path":124,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":125,"sourceHtmlUrl":126},"resources\u002Ftype-safety.md",11466,"https:\u002F\u002Fgithub.com\u002Ftiagoluizpoli\u002Fluna-ai-skills\u002Fblob\u002Fmaster\u002F.agents\u002Fskills\u002Fluna-ai\u002Fcode-review\u002Fresources\u002Ftype-safety.md",{"path":128,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":129,"sourceHtmlUrl":130},"skill-report.json",17316,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fcodingcossack\u002Ftest-driven-development\u002Fskill-report.json",[132,144,154,163,169,176],{"skillNo":133,"name":134,"nameZh":6,"description":6,"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":140,"publishedAt":45},"01M6FKJN13GMG4KY57J3QD8GY5","model-hierarchy-skill","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzscole\u002Fmodel-hierarchy-skill\u002Fmodel-hierarchy-skill\u002FSKILL.md",[137],{"categoryNo":138,"categoryName":139,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[141,142,143],"model","model hierarchy","model hierarchy skill",{"skillNo":145,"name":146,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":150,"publishedAt":45},"01M6FKJJJ6GCAMR4PPPRD12M5X","zoom-mcp","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-mcp\u002FSKILL.md",[149],{"categoryNo":138,"categoryName":139,"taxonomyType":21,"taxonomyTypeDesc":22},[151,152,153],"MCP","zoom","zoom mcp",{"skillNo":155,"name":156,"nameZh":6,"description":6,"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":159,"publishedAt":45},"01M6FKJE3KYT3KPEZMEEHYKA6K","zoom-apps-sdk","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-apps-sdk\u002FSKILL.md",[],[160,161,162,152],"sdk","zoom apps sdk","apps",{"skillNo":164,"name":165,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":45},"01M6FKJ9EDH9Q5VWDF8HAJRSP0","windows","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwindows\u002FSKILL.md",[],[165],{"skillNo":170,"name":171,"nameZh":6,"description":6,"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":175,"publishedAt":45},"01M6FKJ666BEEFC3AE9GJ72Q93","whiteboard","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwhiteboard\u002FSKILL.md",[174],{"categoryNo":138,"categoryName":139,"taxonomyType":21,"taxonomyTypeDesc":22},[171],{"skillNo":177,"name":178,"nameZh":6,"description":6,"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":181,"publishedAt":45},"01M6FKJ21WFCDGTJQ2Q91T9DVW","websockets","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwebsockets\u002FSKILL.md",[],[178]]