[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C4P5VWQ69Q32DA0634GDJY":3,"skill-same:01M6C4P5VWQ69Q32DA0634GDJY":64},{"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":23,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":47,"ownerDescription":48,"updatedAt":49,"install":50,"resources":63},"01M6C4P5VWQ69Q32DA0634GDJY","refactoring",null,"WHEN you need a plan to refactor, restructure, or clean up working code and the test result is known, either green or a recorded failing set; NOT for new feature delivery or any behavior change; reversible-baseline safety with prioritized improvements.","mintuz\u002Fskills","mintuz","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F447031?v=4","01M6BVWJYSVR4XQC9AQCEMWQRG","Adam Bulmer","01M6C4DCXKNYZB281YB3PZDJJG",35,"MIT","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Frefactoring\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35],"test","change","feature delivery","code","SET","refactor","Safety","baseline","plan","behavior","new feature","up","2026-11-10 10:12:30",false,"---\nname: refactoring\ndescription: WHEN you need a plan to refactor, restructure, or clean up working code and the test result is known, either green or a recorded failing set; NOT for new feature delivery or any behavior change; reversible-baseline safety with prioritized improvements.\n---\n\n# Refactoring\n\nRefactoring is the third step of TDD: after GREEN, assess whether refactoring\nadds value. A refactor improves the structure of working code; it never changes\nobservable behaviour.\n\n## When to Refactor\n\n- Assess after every GREEN: once per behaviour, not once after a batch\n- Refactor only if it improves the code; if the code is already clean, move on\n- **Establish a reversible baseline with a known test result before refactoring** (`principle-capture-the-baseline`)\n- **Pin the behaviour the refactor must preserve with a passing test first**\n- Refactor only code that green tests already cover; characterize anything else\n  first or leave it alone, however trivial it looks\n- Refactor in small reversible steps; never refactor code you cannot restore\n- Keep external APIs unchanged and keep every test result unchanged\n\n### Reversible Baseline\n\nA baseline is a state you can return to, so a broken slice costs one restore\ninstead of a debugging session. A commit is one way to record it, not a\nrequirement; refactoring uncommitted code is safe when the baseline is recorded\nanother way.\n\nStay inside the user's authorised boundary:\n\n- Commit the baseline only when the user asked for a baseline commit and the\n  owned changes are the only changes present. A separate commit also keeps git\n  history readable.\n- Inside a TDD cycle where the user allows commits and the owned changes are\n  the only changes present, commit the green code as the baseline; that\n  permission is the explicit request this skill requires.\n- A request for one commit is a request for the refactor commit. Add no extra\n  checkpoint commit for it.\n- Otherwise, record enough to restore the owned paths: their current content or\n  diff, or a clean-tree restore point that already holds that content. Also\n  record the test commands you ran and their results. A list of path names\n  alone restores nothing. Preserve unrelated worktree changes\n  (`principle-preserve-unrelated-work`).\n- Do not commit, stage, stash, or reset without an explicit request\n  (`principle-update-the-base-deliberately`).\n- If the suite is not fully green, record the exact set of failing tests in the\n  baseline; that set must be unchanged after the refactor. Restore green first\n  when you can, as a separate change, never inside the refactor.\n\n**Workflow:**\n\n1. GREEN: The suite passes, or the failing set is known and reproducible\n2. BASELINE: Save the authorised reversible state and that test result\n3. CHARACTERIZE: Pin any unpinned behaviour the refactor must preserve\n4. REFACTOR: Apply one structural slice\n5. VERIFY: Run the named characterization and focused behaviour tests, then the\n   relevant regression suite; on failure, restore only that slice\n   (`principle-sequence-verifiable-units`). When the slice moves or renames\n   files, also check each tool the project uses that finds code by path, for\n   example workspace globs, `tsconfig` paths, test and lint globs, build\n   contexts and route discovery. A stale path in these tools is part of the\n   move: update it in the same slice. Confirm that the same tests, lint inputs\n   and build inputs are still found: a glob that stops matching drops them, and\n   the suite stays green.\n6. COMMIT: Save the refactor separately when requested\n\n### Characterization Tests\n\nA green suite proves only the behaviours it asserts, not that code is safe to\nmove. Characterize before you move code, and only what matters:\n\n1. Trace the call path the change touches. List what each caller can observe\n   across the boundary you are about to move.\n2. Keep the entries a caller relies on or the task states as required. Discard\n   incidental details no caller can observe; pinning those freezes an\n   implementation instead of a contract (`principle-test-behavior-not-implementation`).\n   Common entries that do cross the boundary: public signatures, error type,\n   error object identity, ordering, cleanup timing, retry count and delay, and\n   fan-out to multiple waiters.\n3. For each kept entry no test asserts, write a test asserting the current\n   observable behaviour: run the code and record the output it actually\n   produces today. Never change production code to satisfy that first\n   expectation.\n4. Run those tests against the unchanged implementation. They must pass before\n   you move any code.\n\nA failing characterization test means you do not yet understand the current\nbehaviour: stop and investigate before refactoring.\n\nCharacterization tests are not speculative work; they record existing behaviour\ncallers already depend on.\n\nWhen a required behaviour cannot be characterized, stop before the refactor and\nreport which behaviour you could not pin. Leave uncharacterized code alone,\nwhether or not it looks trivial.\n\n## Priority Classification\n\n| Priority | Action | Examples |\n|----------|--------|----------|\n| Critical | Fix now | Mutations, knowledge duplication, >3 levels nesting |\n| High | This session | Magic numbers, unclear names, >30 line functions |\n| Nice | Later | Minor naming, single-use helpers |\n| Skip | Don't change | Already clean code |\n\n## DRY = Knowledge, Not Code\n\n**Abstract when**:\n\n- Same business concept (semantic meaning)\n- Would change together if requirements change\n- Obvious why grouped together\n\n**Keep separate when**:\n\n- Different concepts that look similar (structural)\n- Would evolve independently\n- Coupling would be confusing\n\nBefore extracting, state the evidence: the rule, policy, or specification the\ncopies share, and whether they have changed together in the past. Duplicates\nthat cite the same rule and have always changed together are one piece of\nknowledge with one owner (`principle-derive-from-one-owner`). Duplicates that\nonly look alike are not; leave them separate.\n\n## Example Assessment\n\n```typescript\n\u002F\u002F After GREEN:\nconst processOrder = (order: Order): ProcessedOrder => {\n  const itemsTotal = order.items.reduce((sum, item) => sum + item.price, 0);\n  const shipping = itemsTotal > 50 ? 0 : 5.99;\n  return { ...order, total: itemsTotal + shipping, shippingCost: shipping };\n};\n\n\u002F\u002F ASSESSMENT:\n\u002F\u002F ⚠️ High: Magic numbers 50, 5.99 → extract constants\n\u002F\u002F ✅ Skip: Structure is clear enough\n\u002F\u002F DECISION: Extract constants only\n```\n\n## Speculative Code is a TDD Violation\n\nEvery new production behaviour must have a failing test that demanded it; if no\ntest drives it, do not write it. The rule governs new production behaviour only,\nnot a structural refactor of working code and not a characterization test.\n\n❌ **Speculative code examples:**\n\n- \"Just in case\" logic\n- Features not yet needed\n- Code written \"for future flexibility\"\n\n**What to do**: Delete speculative code. Add behaviour tests instead.\n\n**Untested is not the same as speculative.** Code that runs in production and\nthat a caller depends on is live behaviour, whatever its coverage. Characterize\nit and keep it. Delete it only as a separate agreed behaviour change with its\nown test, never inside a refactor.\n\n---\n\n## When NOT to Refactor\n\nDon't refactor when:\n\n- ❌ The structure is already clear (no improvement to make)\n- ❌ The change only satisfies a style preference\n- ❌ It would change behaviour (that's a feature, not refactoring)\n- ❌ Premature optimization\n- ❌ Code is \"good enough\" for current phase\n\nWhen a request changes observable behaviour, say so and deliver it test-first\nas a feature. Do not label or plan it as a refactor, and do not give it a\nrefactoring priority; the Priority Classification table applies to refactorings\nonly.\n\n---\n\n## Commit Messages for Refactoring\n\n```\nrefactor: extract scenario validation logic\nrefactor: simplify error handling flow\nrefactor: rename ambiguous parameter names\n```\n\n**Format**: `refactor: \u003Cwhat was changed>`. Never mix refactoring commits with\nfeature commits. When you cannot commit, keep the refactor a separate\nreviewable step from any behaviour change.\n\n---\n\n## Refactoring Checklist\n\n- [ ] The focused behaviour tests and the relevant regression suite give the\n  same result after the refactor as the recorded baseline, including any\n  recorded pre-existing failure\n- [ ] No test was edited, skipped, or deleted to hide a difference\n  (`principle-never-weaken-a-check`)\n- [ ] Every observable behaviour the change could break has a passing\n  characterization test\n- [ ] External APIs unchanged; no new public APIs added\n- [ ] Code more readable than before\n- [ ] Baseline and rollback preserve unrelated worktree changes\n- [ ] Failed verification restores only the owned structural slice\n- [ ] Committed separately from features when requested\n- [ ] No speculative code added\n- [ ] Behaviour unchanged, as far as the characterization and regression tests\n  can show\n","# Refactoring\n\nRefactoring is the third step of TDD: after GREEN, assess whether refactoring\nadds value. A refactor improves the structure of working code; it never changes\nobservable behaviour.\n\n## When to Refactor\n\n- Assess after every GREEN: once per behaviour, not once after a batch\n- Refactor only if it improves the code; if the code is already clean, move on\n- **Establish a reversible baseline with a known test result before refactoring** (`principle-capture-the-baseline`)\n- **Pin the behaviour the refactor must preserve with a passing test first**\n- Refactor only code that green tests already cover; characterize anything else\n  first or leave it alone, however trivial it looks\n- Refactor in small reversible steps; never refactor code you cannot restore\n- Keep external APIs unchanged and keep every test result unchanged\n\n### Reversible Baseline\n\nA baseline is a state you can return to, so a broken slice costs one restore\ninstead of a debugging session. A commit is one way to record it, not a\nrequirement; refactoring uncommitted code is safe when the baseline is recorded\nanother way.\n\nStay inside the user's authorised boundary:\n\n- Commit the baseline only when the user asked for a baseline commit and the\n  owned changes are the only changes present. A separate commit also keeps git\n  history readable.\n- Inside a TDD cycle where the user allows commits and the owned changes are\n  the only changes present, commit the green code as the baseline; that\n  permission is the explicit request this skill requires.\n- A request for one commit is a request for the refactor commit. Add no extra\n  checkpoint commit for it.\n- Otherwise, record enough to restore the owned paths: their current content or\n  diff, or a clean-tree restore point that already holds that content. Also\n  record the test commands you ran and their results. A list of path names\n  alone restores nothing. Preserve unrelated worktree changes\n  (`principle-preserve-unrelated-work`).\n- Do not commit, stage, stash, or reset without an explicit request\n  (`principle-update-the-base-deliberately`).\n- If the suite is not fully green, record the exact set of failing tests in the\n  baseline; that set must be unchanged after the refactor. Restore green first\n  when you can, as a separate change, never inside the refactor.\n\n**Workflow:**\n\n1. GREEN: The suite passes, or the failing set is known and reproducible\n2. BASELINE: Save the authorised reversible state and that test result\n3. CHARACTERIZE: Pin any unpinned behaviour the refactor must preserve\n4. REFACTOR: Apply one structural slice\n5. VERIFY: Run the named characterization and focused behaviour tests, then the\n   relevant regression suite; on failure, restore only that slice\n   (`principle-sequence-verifiable-units`). When the slice moves or renames\n   files, also check each tool the project uses that finds code by path, for\n   example workspace globs, `tsconfig` paths, test and lint globs, build\n   contexts and route discovery. A stale path in these tools is part of the\n   move: update it in the same slice. Confirm that the same tests, lint inputs\n   and build inputs are still found: a glob that stops matching drops them, and\n   the suite stays green.\n6. COMMIT: Save the refactor separately when requested\n\n### Characterization Tests\n\nA green suite proves only the behaviours it asserts, not that code is safe to\nmove. Characterize before you move code, and only what matters:\n\n1. Trace the call path the change touches. List what each caller can observe\n   across the boundary you are about to move.\n2. Keep the entries a caller relies on or the task states as required. Discard\n   incidental details no caller can observe; pinning those freezes an\n   implementation instead of a contract (`principle-test-behavior-not-implementation`).\n   Common entries that do cross the boundary: public signatures, error type,\n   error object identity, ordering, cleanup timing, retry count and delay, and\n   fan-out to multiple waiters.\n3. For each kept entry no test asserts, write a test asserting the current\n   observable behaviour: run the code and record the output it actually\n   produces today. Never change production code to satisfy that first\n   expectation.\n4. Run those tests against the unchanged implementation. They must pass before\n   you move any code.\n\nA failing characterization test means you do not yet understand the current\nbehaviour: stop and investigate before refactoring.\n\nCharacterization tests are not speculative work; they record existing behaviour\ncallers already depend on.\n\nWhen a required behaviour cannot be characterized, stop before the refactor and\nreport which behaviour you could not pin. Leave uncharacterized code alone,\nwhether or not it looks trivial.\n\n## Priority Classification\n\n| Priority | Action | Examples |\n|----------|--------|----------|\n| Critical | Fix now | Mutations, knowledge duplication, >3 levels nesting |\n| High | This session | Magic numbers, unclear names, >30 line functions |\n| Nice | Later | Minor naming, single-use helpers |\n| Skip | Don't change | Already clean code |\n\n## DRY = Knowledge, Not Code\n\n**Abstract when**:\n\n- Same business concept (semantic meaning)\n- Would change together if requirements change\n- Obvious why grouped together\n\n**Keep separate when**:\n\n- Different concepts that look similar (structural)\n- Would evolve independently\n- Coupling would be confusing\n\nBefore extracting, state the evidence: the rule, policy, or specification the\ncopies share, and whether they have changed together in the past. Duplicates\nthat cite the same rule and have always changed together are one piece of\nknowledge with one owner (`principle-derive-from-one-owner`). Duplicates that\nonly look alike are not; leave them separate.\n\n## Example Assessment\n\n```typescript\n\u002F\u002F After GREEN:\nconst processOrder = (order: Order): ProcessedOrder => {\n  const itemsTotal = order.items.reduce((sum, item) => sum + item.price, 0);\n  const shipping = itemsTotal > 50 ? 0 : 5.99;\n  return { ...order, total: itemsTotal + shipping, shippingCost: shipping };\n};\n\n\u002F\u002F ASSESSMENT:\n\u002F\u002F ⚠️ High: Magic numbers 50, 5.99 → extract constants\n\u002F\u002F ✅ Skip: Structure is clear enough\n\u002F\u002F DECISION: Extract constants only\n```\n\n## Speculative Code is a TDD Violation\n\nEvery new production behaviour must have a failing test that demanded it; if no\ntest drives it, do not write it. The rule governs new production behaviour only,\nnot a structural refactor of working code and not a characterization test.\n\n❌ **Speculative code examples:**\n\n- \"Just in case\" logic\n- Features not yet needed\n- Code written \"for future flexibility\"\n\n**What to do**: Delete speculative code. Add behaviour tests instead.\n\n**Untested is not the same as speculative.** Code that runs in production and\nthat a caller depends on is live behaviour, whatever its coverage. Characterize\nit and keep it. Delete it only as a separate agreed behaviour change with its\nown test, never inside a refactor.\n\n---\n\n## When NOT to Refactor\n\nDon't refactor when:\n\n- ❌ The structure is already clear (no improvement to make)\n- ❌ The change only satisfies a style preference\n- ❌ It would change behaviour (that's a feature, not refactoring)\n- ❌ Premature optimization\n- ❌ Code is \"good enough\" for current phase\n\nWhen a request changes observable behaviour, say so and deliver it test-first\nas a feature. Do not label or plan it as a refactor, and do not give it a\nrefactoring priority; the Priority Classification table applies to refactorings\nonly.\n\n---\n\n## Commit Messages for Refactoring\n\n```\nrefactor: extract scenario validation logic\nrefactor: simplify error handling flow\nrefactor: rename ambiguous parameter names\n```\n\n**Format**: `refactor: \u003Cwhat was changed>`. Never mix refactoring commits with\nfeature commits. When you cannot commit, keep the refactor a separate\nreviewable step from any behaviour change.\n\n---\n\n## Refactoring Checklist\n\n- [ ] The focused behaviour tests and the relevant regression suite give the\n  same result after the refactor as the recorded baseline, including any\n  recorded pre-existing failure\n- [ ] No test was edited, skipped, or deleted to hide a difference\n  (`principle-never-weaken-a-check`)\n- [ ] Every observable behaviour the change could break has a passing\n  characterization test\n- [ ] External APIs unchanged; no new public APIs added\n- [ ] Code more readable than before\n- [ ] Baseline and rollback preserve unrelated worktree changes\n- [ ] Failed verification restores only the owned structural slice\n- [ ] Committed separately from features when requested\n- [ ] No speculative code added\n- [ ] Behaviour unchanged, as far as the characterization and regression tests\n  can show\n",{"name":5,"description":7},"main","4e0a12b5048eac78a3ace4feee657873cdd530ef","src\u002Fweb\u002Fskills\u002Frefactoring",7,"https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills","https:\u002F\u002Fgithub.com\u002Fmintuz","http:\u002F\u002Fwww.mintuz.com","Working at @monzo, Previously worked at Moonpig, @booking and @bbc","2026-11-13 19:21:11",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add mintuz\u002Fskills --skill refactoring",{"tool":56,"command":57},"bunx","bunx skills add mintuz\u002Fskills --skill refactoring",{"tool":59,"command":60},"pnpm","pnpm dlx skills add mintuz\u002Fskills --skill refactoring","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Frefactoring\u002FSKILL.md",true,[],[65,86,108,121,138,154],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":77,"publishedAt":36},"01M6C4PDGB6ZZWBS35N3DF7PZZ","xstate","WHEN React state changes in response to an external answer — async submit, in-flight or loading flags, retries, cancellation, polling, optimistic updates, stale responses — or to an interaction with an interruptible middle, such as a drag or a gesture; or WHEN building, reviewing, testing, or visualising XState 5 actors and @xstate\u002Freact integrations; NOT for a value one event sets completely, such as a text draft, a focus flag, or a plain open and closed toggle; models typed lifecycles and renders legal Mermaid stateDiagram-v2 charts.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Fxstate\u002FSKILL.md",[71,74],{"categoryNo":72,"categoryName":73,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":75,"categoryName":76,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[67,78,79,80,81,82,83,84,85],"react","text","state","integrations","Charts","mermaid","testing","open",{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":100,"publishedAt":36},"01M6C4PB6VVC2X19B63B7YNH0T","web-design","WHEN refining UI layout, typography, color, or polish; NOT code implementation; provides concise principles for intentional, legible design.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Fweb-design\u002FSKILL.md",[92,97],{"categoryNo":93,"categoryName":94,"taxonomyType":95,"taxonomyTypeDesc":96},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[101,102,103,104,105,106,107,27],"design","web design","web","code implementation","polish","ui","typography",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":115,"publishedAt":36},"01M6C4P8D92GJDA49V7X1CZXEV","tailwind","USE WHEN writing, fixing or reviewing styling in a project that uses Tailwind CSS, even a one-class change or a request that does not name Tailwind: colours, focus rings, spacing, class names chosen by a prop, map or CVA variants, theme tokens and dark mode in the Tailwind stylesheet or tailwind.config, setup or upgrades (if unsure whether the project uses Tailwind, check package.json or the main stylesheet first); NOT WHEN writing plain CSS or Sass in a project without Tailwind; produces class names Tailwind can find, syntax for the installed major version, visible focus indicators, and no unrequested dependency or invented brand value.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Ftailwind\u002FSKILL.md",[114],{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},[116,117,118,119,101,120],"Tailwind","libraries","component","css","design systems",{"skillNo":122,"name":78,"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":128,"publishedAt":36},"01M6C4P345APEFEX00J8T7QMXQ","USE WHEN changing the logic, data, props, state, Effects or rendered text of a React component, hook or page, even a one-line change; NOT WHEN the request is styling only (class names, Tailwind, CSS, dark mode, spacing, shadows) or tests only, or when it models submit, in-flight, loading, retry or failure states, even for a named React form (xstate covers that, including its React wiring); applies React 19 composition, state, Effect, structure, API and performance rules with only the project's installed libraries.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Freact\u002FSKILL.md",[126,127],{"categoryNo":72,"categoryName":73,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":75,"categoryName":76,"taxonomyType":21,"taxonomyTypeDesc":22},[78,129,24,130,131,80,119,116,132,84,133,27,134,135,136,137],"management","styling","state management","performance","hooks","components","architecture","api","react components",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":146,"publishedAt":36},"01M6C4P0DK385QBG3B3S86TQV2","react-testing","USE WHEN writing, fixing or reviewing a React Testing Library test for a component, hook or context provider, even one small test, or when asked for an end-to-end journey inside a Vitest or React Testing Library suite; NOT WHEN changing the component itself (react), testing XState actors or @xstate\u002Freact (xstate), or writing a Playwright or Cypress test; covers renderHook, providers, async results, forms and false-pass anti-patterns, and declines end-to-end journeys with the testable slices.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Freact-testing\u002FSKILL.md",[144,145],{"categoryNo":72,"categoryName":73,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":75,"categoryName":76,"taxonomyType":21,"taxonomyTypeDesc":22},[147,78,84,148,149,133,150,151,152,134,153,137],"react testing","Providers","anti-patterns","e2e","library","testing library","context",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":162,"publishedAt":36},"01M6C4NY0FTYGTS7THKRAC20T3","frontend-testing","USE WHEN testing non-React UI (vanilla JavaScript or TypeScript DOM code, a web component, or a Vue, Svelte or Angular component) with DOM Testing Library in Vitest or Jest with jsdom: writing, fixing or reviewing a test, or a request to add an end-to-end journey or a layout check to that suite; NOT WHEN the code or project uses React or React Testing Library (use web:react-testing), for XState actors (web:xstate), or for Playwright, Cypress or screenshot-comparison work in a real browser; covers queries, accessible names, userEvent, async results, network stubs and assertions that pass for the wrong reason, and declines what jsdom cannot prove while offering the part that fits.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Ffrontend-testing\u002FSKILL.md",[160,161],{"categoryNo":72,"categoryName":73,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":75,"categoryName":76,"taxonomyType":21,"taxonomyTypeDesc":22},[84,163,164,165,166,167,33,151,152,106],"frontend testing","frontend","browser","first","regression"]