[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H96990SQG64R77246BF2SW":3,"skill-same:01M6H96990SQG64R77246BF2SW":72},{"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":14,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6H96990SQG64R77246BF2SW","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.","drhazemibclc\u002Fplate","drhazemibclc","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F153584232?v=4","01M6H8X67MYG903V4N92MKWKYK","Hazem Ali Abd Elraouf","01M6H8X6C5TSX21P7HJVZVNFNQ",0,"MIT","https:\u002F\u002Fgithub.com\u002Fdrhazemibclc\u002Fplate\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Ftdd\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[5,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"use","bugs","for","with","fix bugs","red","tests","green","build","red-green-refactor","fix","user","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```typescript\n\u002F\u002F GOOD: Tests observable behavior\ntest(\"user can checkout with valid cart\", async () => {\n  const cart = createCart();\n  cart.add(product);\n  const result = await checkout(cart, paymentMethod);\n  expect(result.status).toBe(\"confirmed\");\n});\n\n\u002F\u002F GOOD: Verifies through interface\ntest(\"createUser makes user retrievable\", async () => {\n  const user = await createUser({ name: \"Alice\" });\n  const retrieved = await getUser(user.id);\n  expect(retrieved.name).toBe(\"Alice\");\n});\n```\n\nCharacteristics of good tests:\n\n- Tests behavior users\u002Fcallers care about\n- Uses public API only\n- Survives internal refactors\n- Describes WHAT, not HOW\n- One logical assertion per test\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.\n\n```typescript\n\u002F\u002F BAD: Tests implementation details\ntest(\"checkout calls paymentService.process\", async () => {\n  const mockPayment = jest.mock(paymentService);\n  await checkout(cart, payment);\n  expect(mockPayment.process).toHaveBeenCalledWith(cart.total);\n});\n\n\u002F\u002F BAD: Bypasses interface to verify\ntest(\"createUser saves to database\", async () => {\n  await createUser({ name: \"Alice\" });\n  const row = await db.query(\"SELECT * FROM users WHERE name = ?\", [\"Alice\"]);\n  expect(row).toBeDefined();\n});\n```\n\nRed flags:\n\n- Mocking internal collaborators\n- Testing private methods\n- Asserting on call counts\u002Forder\n- Test breaks when refactoring without behavior change\n- Test name describes HOW not WHAT\n\nPrefer writing tests before implementation. If you've already written code, consider starting fresh from tests rather than retrofitting — tests written after tend to verify what you built, not what's required.\n\n## Mocking\n\nMock at **system boundaries** only:\n\n- External APIs (payment, email, etc.)\n- Databases (sometimes - prefer test DB)\n- Time\u002Frandomness\n- File system (sometimes)\n\nDon't mock:\n\n- Your own classes\u002Fmodules\n- Internal collaborators\n- Anything you control\n\n**Use dependency injection** — pass external dependencies in rather than creating them internally:\n\n```typescript\n\u002F\u002F Easy to mock\nfunction processPayment(order, paymentClient) {\n  return paymentClient.charge(order.total);\n}\n\n\u002F\u002F Hard to mock\nfunction processPayment(order) {\n  const client = new StripeClient(process.env.STRIPE_KEY);\n  return client.charge(order.total);\n}\n```\n\n**Prefer SDK-style interfaces** — specific functions for each external operation:\n\n```typescript\n\u002F\u002F GOOD: Each function is independently mockable\nconst api = {\n  getUser: (id) => fetch(`\u002Fusers\u002F${id}`),\n  getOrders: (userId) => fetch(`\u002Fusers\u002F${userId}\u002Forders`),\n  createOrder: (data) => fetch(\"\u002Forders\", { method: \"POST\", body: data }),\n};\n\n\u002F\u002F BAD: Mocking requires conditional logic inside the mock\nconst api = {\n  fetch: (endpoint, options) => fetch(endpoint, options),\n};\n```\n\n## Interface Design for Testability\n\n1. **Accept dependencies, don't create them**\n\n   ```typescript\n   \u002F\u002F Testable\n   function processOrder(order, paymentGateway) {}\n\n   \u002F\u002F Hard to test\n   function processOrder(order) {\n     const gateway = new StripeGateway();\n   }\n   ```\n\n2. **Return results, don't produce side effects**\n\n   ```typescript\n   \u002F\u002F Testable\n   function calculateDiscount(cart): Discount {}\n\n   \u002F\u002F Hard to test\n   function applyDiscount(cart): void {\n     cart.total -= discount;\n   }\n   ```\n\n3. **Small surface area** — fewer methods = fewer tests needed, fewer params = simpler test setup\n\n**Deep modules** (from \"A Philosophy of Software Design\"): small interface + lots of implementation. When designing, ask: Can I reduce methods? Simplify params? Hide more complexity inside?\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.\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 (small interface, deep implementation)\n- [ ] Design interfaces for testability\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 → run test → confirm it FAILS correctly\nGREEN: Write minimal code → run test → confirm it PASSES\n```\n\n- Test passes immediately? You're testing existing behavior. Fix the test.\n- Test errors (not assertion failure)? Fix the error first — erroring is not the same as failing.\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 → run test → confirm it FAILS correctly\nGREEN: Write minimal code → run test → confirm it 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:\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\nRefactor candidates: duplication → extract function\u002Fclass, long methods → break into private helpers, shallow modules → combine or deepen, feature envy → move logic to where data lives, primitive obsession → introduce value objects.\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[ ] Watched test fail before writing code\n[ ] Failure was for expected reason (missing feature, not typo)\n[ ] All other tests still pass\n```\n\n## Bug Fix Example\n\nTDD applies to bug fixes — write a test that reproduces the bug first.\n\n```\n# Bug: empty email passes validation\n\nRED:   test(\"rejects empty email\", () => {\n         const result = validateEmail(\"\");\n         expect(result.valid).toBe(false);\n       });\n       → Run test → FAILS (empty string passes validation) ✓\n\nGREEN: Add check: if (!email || !email.includes(\"@\")) return { valid: false }\n       → Run test → PASSES ✓\n\n       Verify all other validation tests still pass.\n```\n\n## Type Testing\n\nCompile-time type assertions. No runtime — just `bun typecheck`. Catches regressions in generics, conditional types, and type constraints that runtime tests can't see.\n\n**When:** generic APIs, utility types, complex inference, mapped\u002Fconditional types, ensuring invalid usage errors. **Not:** trivial stuff like `string` prop accepts `string`.\n\n### Utilities\n\nSearch for a file exporting `Expect` and `Equal`. If none exists, create one:\n\n```typescript\nexport function Expect\u003CT extends true>() {}\nexport type Equal\u003CX, Y> = (\u003CT>() => T extends X ? 1 : 2) extends \u003C\n  T\n>() => T extends Y ? 1 : 2\n  ? true\n  : false;\nexport type Not\u003CT extends boolean> = T extends true ? false : true;\nexport type IsAny\u003CT> = 0 extends 1 & T ? true : false;\nexport type IsNever\u003CT> = [T] extends [never] ? true : false;\n```\n\n- `Expect\u003CT extends true>` — compile error = test failure\n- `Equal\u003CX, Y>` — exact type equality (defeats `any` widening)\n- `Not`, `IsAny`, `IsNever` — edge case guards (`any`\u002F`never` break naive comparisons)\n\n### Positive Assertions\n\n```typescript\nimport { Expect, Equal, Not, IsAny } from \".\u002Futils\";\n\n\u002F\u002F Block scope each test to avoid name collisions\n{\n  type Result = ReturnType\u003Ctypeof myGenericFn\u003CSomeInput>>;\n  Expect\u003CEqual\u003CResult, { id: string; name: string }>>;\n  Expect\u003CNot\u003CIsAny\u003CResult>>>;\n}\n```\n\n### Negative Tests\n\n`@ts-expect-error` **must** be on the line immediately before the error. Always include a reason. Unused directive = failing test (constraint is missing).\n\n```typescript\n\u002F\u002F ✅ directive on line immediately before error\ndoSomething({\n  \u002F\u002F @ts-expect-error - name must be string\n  name: 123,\n});\n\n\u002F\u002F ❌ directive too far from error\ndoSomething({\n  \u002F\u002F @ts-expect-error - name must be string\n  ...defaults,\n  name: 123,\n});\n```\n\n### Tips\n\n- **`declare const`** for mock values without runtime: `declare const ctx: SomeCtx;`\n- **`type _name = Expect\u003C...>`** when you need a type-level-only assertion (no runtime `Expect()` call needed)\n- **`\u002F* biome-ignore-all lint *\u002F`** at file top for type-only files — suppresses unused variable warnings\n\nRun with `bun typecheck`. If it compiles, it passes.\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```typescript\n\u002F\u002F GOOD: Tests observable behavior\ntest(\"user can checkout with valid cart\", async () => {\n  const cart = createCart();\n  cart.add(product);\n  const result = await checkout(cart, paymentMethod);\n  expect(result.status).toBe(\"confirmed\");\n});\n\n\u002F\u002F GOOD: Verifies through interface\ntest(\"createUser makes user retrievable\", async () => {\n  const user = await createUser({ name: \"Alice\" });\n  const retrieved = await getUser(user.id);\n  expect(retrieved.name).toBe(\"Alice\");\n});\n```\n\nCharacteristics of good tests:\n\n- Tests behavior users\u002Fcallers care about\n- Uses public API only\n- Survives internal refactors\n- Describes WHAT, not HOW\n- One logical assertion per test\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.\n\n```typescript\n\u002F\u002F BAD: Tests implementation details\ntest(\"checkout calls paymentService.process\", async () => {\n  const mockPayment = jest.mock(paymentService);\n  await checkout(cart, payment);\n  expect(mockPayment.process).toHaveBeenCalledWith(cart.total);\n});\n\n\u002F\u002F BAD: Bypasses interface to verify\ntest(\"createUser saves to database\", async () => {\n  await createUser({ name: \"Alice\" });\n  const row = await db.query(\"SELECT * FROM users WHERE name = ?\", [\"Alice\"]);\n  expect(row).toBeDefined();\n});\n```\n\nRed flags:\n\n- Mocking internal collaborators\n- Testing private methods\n- Asserting on call counts\u002Forder\n- Test breaks when refactoring without behavior change\n- Test name describes HOW not WHAT\n\nPrefer writing tests before implementation. If you've already written code, consider starting fresh from tests rather than retrofitting — tests written after tend to verify what you built, not what's required.\n\n## Mocking\n\nMock at **system boundaries** only:\n\n- External APIs (payment, email, etc.)\n- Databases (sometimes - prefer test DB)\n- Time\u002Frandomness\n- File system (sometimes)\n\nDon't mock:\n\n- Your own classes\u002Fmodules\n- Internal collaborators\n- Anything you control\n\n**Use dependency injection** — pass external dependencies in rather than creating them internally:\n\n```typescript\n\u002F\u002F Easy to mock\nfunction processPayment(order, paymentClient) {\n  return paymentClient.charge(order.total);\n}\n\n\u002F\u002F Hard to mock\nfunction processPayment(order) {\n  const client = new StripeClient(process.env.STRIPE_KEY);\n  return client.charge(order.total);\n}\n```\n\n**Prefer SDK-style interfaces** — specific functions for each external operation:\n\n```typescript\n\u002F\u002F GOOD: Each function is independently mockable\nconst api = {\n  getUser: (id) => fetch(`\u002Fusers\u002F${id}`),\n  getOrders: (userId) => fetch(`\u002Fusers\u002F${userId}\u002Forders`),\n  createOrder: (data) => fetch(\"\u002Forders\", { method: \"POST\", body: data }),\n};\n\n\u002F\u002F BAD: Mocking requires conditional logic inside the mock\nconst api = {\n  fetch: (endpoint, options) => fetch(endpoint, options),\n};\n```\n\n## Interface Design for Testability\n\n1. **Accept dependencies, don't create them**\n\n   ```typescript\n   \u002F\u002F Testable\n   function processOrder(order, paymentGateway) {}\n\n   \u002F\u002F Hard to test\n   function processOrder(order) {\n     const gateway = new StripeGateway();\n   }\n   ```\n\n2. **Return results, don't produce side effects**\n\n   ```typescript\n   \u002F\u002F Testable\n   function calculateDiscount(cart): Discount {}\n\n   \u002F\u002F Hard to test\n   function applyDiscount(cart): void {\n     cart.total -= discount;\n   }\n   ```\n\n3. **Small surface area** — fewer methods = fewer tests needed, fewer params = simpler test setup\n\n**Deep modules** (from \"A Philosophy of Software Design\"): small interface + lots of implementation. When designing, ask: Can I reduce methods? Simplify params? Hide more complexity inside?\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.\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 (small interface, deep implementation)\n- [ ] Design interfaces for testability\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 → run test → confirm it FAILS correctly\nGREEN: Write minimal code → run test → confirm it PASSES\n```\n\n- Test passes immediately? You're testing existing behavior. Fix the test.\n- Test errors (not assertion failure)? Fix the error first — erroring is not the same as failing.\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 → run test → confirm it FAILS correctly\nGREEN: Write minimal code → run test → confirm it 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:\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\nRefactor candidates: duplication → extract function\u002Fclass, long methods → break into private helpers, shallow modules → combine or deepen, feature envy → move logic to where data lives, primitive obsession → introduce value objects.\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[ ] Watched test fail before writing code\n[ ] Failure was for expected reason (missing feature, not typo)\n[ ] All other tests still pass\n```\n\n## Bug Fix Example\n\nTDD applies to bug fixes — write a test that reproduces the bug first.\n\n```\n# Bug: empty email passes validation\n\nRED:   test(\"rejects empty email\", () => {\n         const result = validateEmail(\"\");\n         expect(result.valid).toBe(false);\n       });\n       → Run test → FAILS (empty string passes validation) ✓\n\nGREEN: Add check: if (!email || !email.includes(\"@\")) return { valid: false }\n       → Run test → PASSES ✓\n\n       Verify all other validation tests still pass.\n```\n\n## Type Testing\n\nCompile-time type assertions. No runtime — just `bun typecheck`. Catches regressions in generics, conditional types, and type constraints that runtime tests can't see.\n\n**When:** generic APIs, utility types, complex inference, mapped\u002Fconditional types, ensuring invalid usage errors. **Not:** trivial stuff like `string` prop accepts `string`.\n\n### Utilities\n\nSearch for a file exporting `Expect` and `Equal`. If none exists, create one:\n\n```typescript\nexport function Expect\u003CT extends true>() {}\nexport type Equal\u003CX, Y> = (\u003CT>() => T extends X ? 1 : 2) extends \u003C\n  T\n>() => T extends Y ? 1 : 2\n  ? true\n  : false;\nexport type Not\u003CT extends boolean> = T extends true ? false : true;\nexport type IsAny\u003CT> = 0 extends 1 & T ? true : false;\nexport type IsNever\u003CT> = [T] extends [never] ? true : false;\n```\n\n- `Expect\u003CT extends true>` — compile error = test failure\n- `Equal\u003CX, Y>` — exact type equality (defeats `any` widening)\n- `Not`, `IsAny`, `IsNever` — edge case guards (`any`\u002F`never` break naive comparisons)\n\n### Positive Assertions\n\n```typescript\nimport { Expect, Equal, Not, IsAny } from \".\u002Futils\";\n\n\u002F\u002F Block scope each test to avoid name collisions\n{\n  type Result = ReturnType\u003Ctypeof myGenericFn\u003CSomeInput>>;\n  Expect\u003CEqual\u003CResult, { id: string; name: string }>>;\n  Expect\u003CNot\u003CIsAny\u003CResult>>>;\n}\n```\n\n### Negative Tests\n\n`@ts-expect-error` **must** be on the line immediately before the error. Always include a reason. Unused directive = failing test (constraint is missing).\n\n```typescript\n\u002F\u002F ✅ directive on line immediately before error\ndoSomething({\n  \u002F\u002F @ts-expect-error - name must be string\n  name: 123,\n});\n\n\u002F\u002F ❌ directive too far from error\ndoSomething({\n  \u002F\u002F @ts-expect-error - name must be string\n  ...defaults,\n  name: 123,\n});\n```\n\n### Tips\n\n- **`declare const`** for mock values without runtime: `declare const ctx: SomeCtx;`\n- **`type _name = Expect\u003C...>`** when you need a type-level-only assertion (no runtime `Expect()` call needed)\n- **`\u002F* biome-ignore-all lint *\u002F`** at file top for type-only files — suppresses unused variable warnings\n\nRun with `bun typecheck`. If it compiles, it passes.\n",{"name":5,"description":7},"main","2af107c35457ccaaa2c99d5478745496095d3cf7",".codex\u002Fskills\u002Ftdd","https:\u002F\u002Fgithub.com\u002Fdrhazemibclc\u002Fplate","https:\u002F\u002Fgithub.com\u002Fdrhazemibclc","Certified Pediatrician and IBCLC","2026-03-22 21:33:09",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add drhazemibclc\u002Fplate --skill tdd",{"tool":64,"command":65},"bunx","bunx skills add drhazemibclc\u002Fplate --skill tdd",{"tool":67,"command":68},"pnpm","pnpm dlx skills add drhazemibclc\u002Fplate --skill tdd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdrhazemibclc\u002Fplate\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Ftdd\u002FSKILL.md",true,[],[73,90,106,120,132,143],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":46},"01M6H97EF29WFNJJJH91670GQ1","workflows-work","[DEPRECATED] Use \u002Fce:work instead — renamed for clarity.","https:\u002F\u002Fgithub.com\u002Fdrhazemibclc\u002Fplate\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fworkflows-work\u002FSKILL.md",[],[80,81,82,83,29,84,85,86,87,27,88,89],"workflows","work","workflows work","file","path","true","todo","specification","clarity","plan",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":46},"01M6H97C6CZMYST83WEJN87CVS","workflows-review","[DEPRECATED] Use \u002Fce:review instead — renamed for clarity.","https:\u002F\u002Fgithub.com\u002Fdrhazemibclc\u002Fplate\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fworkflows-review\u002FSKILL.md",[],[97,98,80,88,99,100,101,29,102,85,103,104,105,27],"workflows review","review","pr","github","branch","latest","number","URL","name",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":46},"01M6H97A2P4ZE58BKMVQBYAK3M","workflows-plan","[DEPRECATED] Use \u002Fce:plan instead — renamed for clarity.","https:\u002F\u002Fgithub.com\u002Fdrhazemibclc\u002Fplate\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fworkflows-plan\u002FSKILL.md",[],[80,113,89,114,115,29,85,116,117,88,118,119,27],"workflows plan","bug","improvement","feature","idea","report","bug report",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":46},"01M6H9780WX39EB980F69WFHEQ","workflows-compound","[DEPRECATED] Use \u002Fce:compound instead — renamed for clarity.","https:\u002F\u002Fgithub.com\u002Fdrhazemibclc\u002Fplate\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fworkflows-compound\u002FSKILL.md",[],[127,128,80,85,129,29,130,27,37,88,131],"workflows compound","compound","context","about","brief",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":46},"01M6H9761C1HS173TW6P4ZMCY2","workflows-brainstorm","[DEPRECATED] Use \u002Fce:brainstorm instead — renamed for clarity.","https:\u002F\u002Fgithub.com\u002Fdrhazemibclc\u002Fplate\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fworkflows-brainstorm\u002FSKILL.md",[],[139,80,140,88,141,27,29,85,142,116,117],"brainstorm","workflows brainstorm","explore","problem",{"skillNo":144,"name":145,"nameZh":6,"description":146,"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":152,"publishedAt":46},"01M6H971R100F94DW8NGC93KQ6","vercel-react-best-practices","React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React\u002FNext.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.","https:\u002F\u002Fgithub.com\u002Fdrhazemibclc\u002Fplate\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fvercel-react-best-practices\u002FSKILL.md",[149],{"categoryNo":150,"categoryName":151,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172],"vercel","react best practices","best practices","vercel react best practices","react","Next.js","data fetching","triggers","pages","next","performance optimization","refactoring","Optimization","code","tasks","guidelines","react components","components","performance","writing"]