[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C4GWMZRT8H106EB0DRQN0C":3,"skill-same:01M6C4GWMZRT8H106EB0DRQN0C":67},{"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":29,"linkOnly":30,"markdownContent":31,"markdownBody":32,"frontMatter":33,"refName":34,"commitSha":35,"skillDirectory":36,"forksCount":37,"repositoryHtmlUrl":38,"repositoryHomepageUrl":6,"ownerHtmlUrl":39,"ownerBlogUrl":40,"ownerDescription":41,"updatedAt":42,"install":43,"resources":56},"01M6C4GWMZRT8H106EB0DRQN0C","reducer",null,"WHEN reducing whole-system complexity—branches, state, dependencies, layers, or moving parts—in an existing system or feature; NOT for functionality cuts or unproven rewrites; derives the minimum mechanism from first principles and proves behavior and guarantees are conserved.","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\u002Fcore\u002Fskills\u002Freducer\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[5,24,25,26,27,28],"state","first","system","behavior","complexity","2026-11-10 10:12:30",false,"---\nname: reducer\ndescription: WHEN reducing whole-system complexity—branches, state, dependencies, layers, or moving parts—in an existing system or feature; NOT for functionality cuts or unproven rewrites; derives the minimum mechanism from first principles and proves behavior and guarantees are conserved.\n---\n\n# Reducer\n\nConserve behaviour. Minimise mechanism.\n\n## Conservation law\n\n- Preserve every supported behaviour and non-functional guarantee in scope: outputs, side effects, errors, ordering, persistence, integrations, authorisation, security, privacy, reliability, resource budgets, and compatibility (`principle-preserve-unrelated-work`).\n- Treat a proposal to remove supported behaviour as a scope change, not a reduction. Delete supported behaviour only after a recorded owner decision withdraws it. Report the withdrawal separately from mechanism reduction (`principle-stay-in-scope`).\n- Derive the target from domain truths and external constraints, not the current implementation (`principle-redesign-from-first-principles`).\n- Measure the whole system. Moving a branch, dependency, state transition, or failure mode across a boundary is not a reduction (`principle-subtract-before-you-add`).\n- Keep essential complexity visible. Optimise complete change, request, and failure paths for maintainers and operators (`principle-minimize-reader-load`).\n- Prefer subtraction and collapse. Treat cyclomatic complexity and line count as signals, not objectives.\n\n## 1. Contract\n\nState the scope, outcome, and mode. Diagnosis produces a design without edits; implementation changes the system in reversible slices.\n\nInventory entry points, callers, tests, state, integrations, configuration, operations, and relevant decisions. Create a behaviour ledger:\n\n| Behaviour or guarantee | Trigger | Outcome and side effects | Boundary | Oracle or gap |\n|-----------------------|---------|--------------------------|----------|---------------|\n\nInclude errors, edge cases, ordering, concurrency, retries, migration, compatibility, and applicable non-functional guarantees. Diagnosis records missing oracles as proof obligations. Before product edits, implementation captures affected gaps with characterisation tests or stable pre-change evidence such as fixtures, snapshots, traces, or recorded input\u002Foutput pairs (`principle-capture-the-baseline`).\n\n**Complete when:** every in-scope behaviour and boundary has preservation evidence or an explicit proof gap, and the allowed change surface is clear.\n\n## 2. Baseline the whole mechanism\n\nTrace every behaviour end to end:\n\n| Mechanism | Behaviour served | Owner | Complexity cost | Essential constraint | Evidence | Disposition |\n|-----------|-----------------|-------|-----------------|----------------------|----------|-------------|\n\nCount applicable dimensions with the same scope and method before and after:\n\n- **Control:** aggregate and maximum cyclomatic complexity, conditions, error, retry, fallback, and ordering paths.\n- **State and time:** states, transitions, mutable owners, caches, queues, tasks, callbacks, locks, synchronisation points, lifecycle phases. Count a state space by the combinations its representation admits across all its fields, not by the number of fields. Separate the admitted combinations from the valid and reachable ones. Name the invariant that excludes the rest.\n- **Structure:** modules, types, layers, hops, internal and external dependencies, cycles, adapters, representations.\n- **Variability and operations:** flags, modes, configuration, extension points, deployables, jobs, migrations, monitors, failure and recovery paths.\n\nRecord a dimension the evidence shows is absent as 0, not as a proof gap; mark `N\u002FA` only dimensions irrelevant to the change. Include tests and operational machinery when they impose ongoing cost; exclude generated artifacts unless their source or runtime mechanism changes. A smaller function or diff is not evidence unless the complete mechanism shrinks.\n\n**Complete when:** every mechanism on an in-scope behaviour path is accounted for, every listed dimension is counted with the same scope and method or marked `N\u002FA`, and the baseline shows where complexity is created, transferred, and paid.\n\n## 3. Derive the minimum\n\nIgnore the current decomposition and answer from first principles:\n\n1. Which outcomes and guarantees must exist?\n2. Which domain facts and decisions are irreducible?\n3. Which external boundaries are fixed, and who must own state?\n4. What is the shortest coherent path from trigger to outcome?\n\nSketch the minimum mechanism. Name the constraint that requires each remaining part, then compare it with the baseline. Seek leverage in this order:\n\n1. Delete unsupported paths, options, flags, configuration, fallbacks, and speculative machinery (`principle-foundational-thinking`).\n2. Unify duplicated policy, representation, state, and ownership (`principle-derive-from-one-owner`).\n3. Shrink decision and state spaces; prefer complete declarative rules or straight-line operations (`principle-model-the-domain`, `principle-narrow-state-lifetime`).\n4. Flatten pass-through layers, translation chains, coordination, and temporal hops (`principle-minimize-reader-load`).\n5. Replace custom machinery with a stable primitive only when total ownership and operational cost fall (`principle-reuse-before-building`).\n\nReject changes that merely rename, split, wrap, relocate, or conceal complexity, and local simplifications that increase coupling, coordination, comprehension cost, change cost, or failure modes elsewhere. Moving a policy or a decision out of its single owner is redistribution, not deletion. Before you delete a bound, limit, timeout, or back-pressure control, prove that another control still enforces the guarantee it serves. Without that proof, treat the guarantee as withdrawn. Name the exposed failure path in concrete terms, such as resource exhaustion or silent loss. Record it and any replacement control alongside the counts.\n\n**Complete when:** every target mechanism has a named behavioural or external reason and the expected whole-system reduction is explicit.\n\n## 4. Select a slice\n\nRank candidates by `mechanism removed × confidence ÷ blast radius`; use the smaller blast radius to break ties. Choose the smallest reversible slice that removes one complete mechanism. Record:\n\n- the mechanism and affected behaviours;\n- their passing oracles and affected callers, data, integrations, and operations;\n- the expected before\u002Fafter delta, stated for each stage when the slice lands in stages;\n- migration, rollback, and verification needs.\n\nApply the gap rule: diagnosis may carry proof gaps; implementation remains diagnosis until every behaviour and guarantee the slice can affect has a passing preservation oracle. Keep a compatibility shim only for a live boundary. Assign the migration that closes the shim to the caller or integration owner, assign the shim's deletion to the component owner, and record one measurable removal condition (`principle-migrate-callers-then-delete-legacy-apis`).\n\nDiagnosis now reports the proposal. Implementation continues to Step 5.\n\n**Complete when:** the slice is reversible, satisfies the gap rule, has executable proof obligations, and removes rather than redistributes mechanism.\n\n## 5. Reduce and prove\n\nFor each authorised implementation slice:\n\n1. Record the exact pre-slice state and confirm every affected oracle passes (`principle-capture-the-baseline`).\n2. Make the smallest coherent change.\n3. Preserve behaviour-facing tests; change only assertions tied to discarded implementation structure, without weakening behavioural coverage (`principle-never-weaken-a-check`).\n4. Run focused checks immediately, then the broader relevant suite.\n5. Re-read the complete path, then remove superseded code, adapters, flags, states, dependencies, configuration, and tests or documentation for removed internals.\n6. Apply the **behaviour gate**: re-run affected oracles and the relevant full test, type, build, lint, integration, and operational checks; compare outcomes, side effects, errors, ordering, boundaries, and constraints; exercise boundary conditions implied by every removed decision or state.\n7. Apply the **mechanism gate**: recount the baseline dimensions, map every new mechanism to the old one it replaces, and inspect callers and downstream owners for exported decisions, state, coordination, change cost, or failure handling.\n\nIf evidence fails or another affected behaviour appears, stop. Derive its oracle only from the recorded pre-slice state or independent pre-change evidence; restore only this slice's edits when necessary. Never characterise modified behaviour as the baseline.\n\nApply both gates at every stage of a staged slice, including after you remove a shim. A slice passes only when both gates pass and total in-scope mechanism falls. Treat a net-neutral or displaced result as unfinished. Repeat only after the current slice passes (`principle-sequence-verifiable-units`).\n\n**Complete when:** all behaviour-ledger entries are preserved, the old mechanism is gone, the before\u002Fafter ledger proves a net reduction, and every temporary bridge has an owner and removal condition.\n\n## Report\n\nFor implementation, lead with the conserved behaviour and removed mechanism:\n\n| Dimension | Before | After | Evidence |\n|-----------|--------|-------|----------|\n\nList every baseline dimension, including explicit `N\u002FA` rows, and state whether the target adds any owner or representation. List verification results and essential complexity retained. Report proof gaps, compatibility shims, and follow-up slices with owners and closure or removal conditions (`principle-gaps-are-not-passes`). For diagnosis, report ranked slices, proof obligations, and blockers; claim neither realised reduction nor equivalence (`principle-label-the-evidence`). Give every slice you name, including a rejected proposal's replacement and a slice deferred behind missing oracles, its expected whole-system before\u002Fafter mechanism delta and its slice-local rollback boundary. State each delta as before and after counts per dimension; never defer the count to later work. Report a behaviour withdrawal only as a prerequisite decision; never design or schedule it.\n","# Reducer\n\nConserve behaviour. Minimise mechanism.\n\n## Conservation law\n\n- Preserve every supported behaviour and non-functional guarantee in scope: outputs, side effects, errors, ordering, persistence, integrations, authorisation, security, privacy, reliability, resource budgets, and compatibility (`principle-preserve-unrelated-work`).\n- Treat a proposal to remove supported behaviour as a scope change, not a reduction. Delete supported behaviour only after a recorded owner decision withdraws it. Report the withdrawal separately from mechanism reduction (`principle-stay-in-scope`).\n- Derive the target from domain truths and external constraints, not the current implementation (`principle-redesign-from-first-principles`).\n- Measure the whole system. Moving a branch, dependency, state transition, or failure mode across a boundary is not a reduction (`principle-subtract-before-you-add`).\n- Keep essential complexity visible. Optimise complete change, request, and failure paths for maintainers and operators (`principle-minimize-reader-load`).\n- Prefer subtraction and collapse. Treat cyclomatic complexity and line count as signals, not objectives.\n\n## 1. Contract\n\nState the scope, outcome, and mode. Diagnosis produces a design without edits; implementation changes the system in reversible slices.\n\nInventory entry points, callers, tests, state, integrations, configuration, operations, and relevant decisions. Create a behaviour ledger:\n\n| Behaviour or guarantee | Trigger | Outcome and side effects | Boundary | Oracle or gap |\n|-----------------------|---------|--------------------------|----------|---------------|\n\nInclude errors, edge cases, ordering, concurrency, retries, migration, compatibility, and applicable non-functional guarantees. Diagnosis records missing oracles as proof obligations. Before product edits, implementation captures affected gaps with characterisation tests or stable pre-change evidence such as fixtures, snapshots, traces, or recorded input\u002Foutput pairs (`principle-capture-the-baseline`).\n\n**Complete when:** every in-scope behaviour and boundary has preservation evidence or an explicit proof gap, and the allowed change surface is clear.\n\n## 2. Baseline the whole mechanism\n\nTrace every behaviour end to end:\n\n| Mechanism | Behaviour served | Owner | Complexity cost | Essential constraint | Evidence | Disposition |\n|-----------|-----------------|-------|-----------------|----------------------|----------|-------------|\n\nCount applicable dimensions with the same scope and method before and after:\n\n- **Control:** aggregate and maximum cyclomatic complexity, conditions, error, retry, fallback, and ordering paths.\n- **State and time:** states, transitions, mutable owners, caches, queues, tasks, callbacks, locks, synchronisation points, lifecycle phases. Count a state space by the combinations its representation admits across all its fields, not by the number of fields. Separate the admitted combinations from the valid and reachable ones. Name the invariant that excludes the rest.\n- **Structure:** modules, types, layers, hops, internal and external dependencies, cycles, adapters, representations.\n- **Variability and operations:** flags, modes, configuration, extension points, deployables, jobs, migrations, monitors, failure and recovery paths.\n\nRecord a dimension the evidence shows is absent as 0, not as a proof gap; mark `N\u002FA` only dimensions irrelevant to the change. Include tests and operational machinery when they impose ongoing cost; exclude generated artifacts unless their source or runtime mechanism changes. A smaller function or diff is not evidence unless the complete mechanism shrinks.\n\n**Complete when:** every mechanism on an in-scope behaviour path is accounted for, every listed dimension is counted with the same scope and method or marked `N\u002FA`, and the baseline shows where complexity is created, transferred, and paid.\n\n## 3. Derive the minimum\n\nIgnore the current decomposition and answer from first principles:\n\n1. Which outcomes and guarantees must exist?\n2. Which domain facts and decisions are irreducible?\n3. Which external boundaries are fixed, and who must own state?\n4. What is the shortest coherent path from trigger to outcome?\n\nSketch the minimum mechanism. Name the constraint that requires each remaining part, then compare it with the baseline. Seek leverage in this order:\n\n1. Delete unsupported paths, options, flags, configuration, fallbacks, and speculative machinery (`principle-foundational-thinking`).\n2. Unify duplicated policy, representation, state, and ownership (`principle-derive-from-one-owner`).\n3. Shrink decision and state spaces; prefer complete declarative rules or straight-line operations (`principle-model-the-domain`, `principle-narrow-state-lifetime`).\n4. Flatten pass-through layers, translation chains, coordination, and temporal hops (`principle-minimize-reader-load`).\n5. Replace custom machinery with a stable primitive only when total ownership and operational cost fall (`principle-reuse-before-building`).\n\nReject changes that merely rename, split, wrap, relocate, or conceal complexity, and local simplifications that increase coupling, coordination, comprehension cost, change cost, or failure modes elsewhere. Moving a policy or a decision out of its single owner is redistribution, not deletion. Before you delete a bound, limit, timeout, or back-pressure control, prove that another control still enforces the guarantee it serves. Without that proof, treat the guarantee as withdrawn. Name the exposed failure path in concrete terms, such as resource exhaustion or silent loss. Record it and any replacement control alongside the counts.\n\n**Complete when:** every target mechanism has a named behavioural or external reason and the expected whole-system reduction is explicit.\n\n## 4. Select a slice\n\nRank candidates by `mechanism removed × confidence ÷ blast radius`; use the smaller blast radius to break ties. Choose the smallest reversible slice that removes one complete mechanism. Record:\n\n- the mechanism and affected behaviours;\n- their passing oracles and affected callers, data, integrations, and operations;\n- the expected before\u002Fafter delta, stated for each stage when the slice lands in stages;\n- migration, rollback, and verification needs.\n\nApply the gap rule: diagnosis may carry proof gaps; implementation remains diagnosis until every behaviour and guarantee the slice can affect has a passing preservation oracle. Keep a compatibility shim only for a live boundary. Assign the migration that closes the shim to the caller or integration owner, assign the shim's deletion to the component owner, and record one measurable removal condition (`principle-migrate-callers-then-delete-legacy-apis`).\n\nDiagnosis now reports the proposal. Implementation continues to Step 5.\n\n**Complete when:** the slice is reversible, satisfies the gap rule, has executable proof obligations, and removes rather than redistributes mechanism.\n\n## 5. Reduce and prove\n\nFor each authorised implementation slice:\n\n1. Record the exact pre-slice state and confirm every affected oracle passes (`principle-capture-the-baseline`).\n2. Make the smallest coherent change.\n3. Preserve behaviour-facing tests; change only assertions tied to discarded implementation structure, without weakening behavioural coverage (`principle-never-weaken-a-check`).\n4. Run focused checks immediately, then the broader relevant suite.\n5. Re-read the complete path, then remove superseded code, adapters, flags, states, dependencies, configuration, and tests or documentation for removed internals.\n6. Apply the **behaviour gate**: re-run affected oracles and the relevant full test, type, build, lint, integration, and operational checks; compare outcomes, side effects, errors, ordering, boundaries, and constraints; exercise boundary conditions implied by every removed decision or state.\n7. Apply the **mechanism gate**: recount the baseline dimensions, map every new mechanism to the old one it replaces, and inspect callers and downstream owners for exported decisions, state, coordination, change cost, or failure handling.\n\nIf evidence fails or another affected behaviour appears, stop. Derive its oracle only from the recorded pre-slice state or independent pre-change evidence; restore only this slice's edits when necessary. Never characterise modified behaviour as the baseline.\n\nApply both gates at every stage of a staged slice, including after you remove a shim. A slice passes only when both gates pass and total in-scope mechanism falls. Treat a net-neutral or displaced result as unfinished. Repeat only after the current slice passes (`principle-sequence-verifiable-units`).\n\n**Complete when:** all behaviour-ledger entries are preserved, the old mechanism is gone, the before\u002Fafter ledger proves a net reduction, and every temporary bridge has an owner and removal condition.\n\n## Report\n\nFor implementation, lead with the conserved behaviour and removed mechanism:\n\n| Dimension | Before | After | Evidence |\n|-----------|--------|-------|----------|\n\nList every baseline dimension, including explicit `N\u002FA` rows, and state whether the target adds any owner or representation. List verification results and essential complexity retained. Report proof gaps, compatibility shims, and follow-up slices with owners and closure or removal conditions (`principle-gaps-are-not-passes`). For diagnosis, report ranked slices, proof obligations, and blockers; claim neither realised reduction nor equivalence (`principle-label-the-evidence`). Give every slice you name, including a rejected proposal's replacement and a slice deferred behind missing oracles, its expected whole-system before\u002Fafter mechanism delta and its slice-local rollback boundary. State each delta as before and after counts per dimension; never defer the count to later work. Report a behaviour withdrawal only as a prerequisite decision; never design or schedule it.\n",{"name":5,"description":7},"main","4e0a12b5048eac78a3ace4feee657873cdd530ef","src\u002Fcore\u002Fskills\u002Freducer",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-11 15:50:19",{"source":8,"skillName":5,"commands":44,"prompt":54,"zipAvailable":55},[45,48,51],{"tool":46,"command":47},"npx","npx skills add mintuz\u002Fskills --skill reducer",{"tool":49,"command":50},"bunx","bunx skills add mintuz\u002Fskills --skill reducer",{"tool":52,"command":53},"pnpm","pnpm dlx skills add mintuz\u002Fskills --skill reducer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fcore\u002Fskills\u002Freducer\u002FSKILL.md",true,[57,63],{"path":58,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":61,"sourceHtmlUrl":62},"agents\u002Fopenai.yaml","REFERENCE","参考文档",248,"https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fcore\u002Fskills\u002Freducer\u002Fagents\u002Fopenai.yaml",{"path":64,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":65,"sourceHtmlUrl":66},"README.md",465,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-performance-optimizer\u002FREADME.md",[68,90,111,124,144,161],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":82,"publishedAt":29},"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",[74,79],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":80,"categoryName":81,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000009","前端开发",[70,83,84,85,86,87,24,88,89],"integrations","react","text","open","Charts","mermaid","testing",{"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":102,"publishedAt":29},"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",[96,99],{"categoryNo":97,"categoryName":98,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":100,"categoryName":101,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师",[103,104,105,106,107,108,109,110],"design","web","web design","code","code implementation","ui","polish","typography",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":118,"publishedAt":29},"01M6C4P8D92GJDA49V7X1CZXEV","tailwind","WHEN building design systems or component libraries with Tailwind CSS; covers design tokens, CVA patterns and dark mode.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Ftailwind\u002FSKILL.md",[117],{"categoryNo":97,"categoryName":98,"taxonomyType":77,"taxonomyTypeDesc":78},[119,103,120,121,122,123],"Tailwind","css","component","libraries","design systems",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":133,"publishedAt":29},"01M6C4P5VWQ69Q32DA0634GDJY","refactoring","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.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Frefactoring\u002FSKILL.md",[130],{"categoryNo":131,"categoryName":132,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000007","代码审查",[126,134,135,136,27,137,138,139,140,141,142,106,143],"baseline","SET","plan","new feature","up","Safety","test","change","feature delivery","refactor",{"skillNo":145,"name":84,"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":151,"publishedAt":29},"01M6C4P345APEFEX00J8T7QMXQ","WHEN building or changing React components, pages, hooks, effects, or apps, including edits to existing components; NOT for test code (react-testing) or styling (css, tailwind); enforces scalable architecture, state management, API layer, performance patterns.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Freact\u002FSKILL.md",[149,150],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},{"categoryNo":80,"categoryName":81,"taxonomyType":77,"taxonomyTypeDesc":78},[84,152,89,120,153,140,154,155,156,106,24,157,119,158,159,160],"react components","performance","components","architecture","state management","api","management","hooks","styling",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":169,"publishedAt":29},"01M6C4P0DK385QBG3B3S86TQV2","react-testing","WHEN testing React components\u002Fhooks\u002Fcontext with React Testing Library; NOT e2e; covers renderHook, providers, forms, and anti-patterns.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Freact-testing\u002FSKILL.md",[167,168],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},{"categoryNo":80,"categoryName":81,"taxonomyType":77,"taxonomyTypeDesc":78},[89,170,84,154,152,171,172,173,174,175,176,159],"react testing","testing library","library","Providers","e2e","context","anti-patterns"]