[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6QJ2FXJ3RCZHWQTRK8GVPG2":3,"skill-same:01M6QJ2FXJ3RCZHWQTRK8GVPG2":82},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":13,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":61,"install":62,"resources":75},"01M6QJ2FXJ3RCZHWQTRK8GVPG2","react-component-refactor",null,"Analyzes React component structure, identifies reusable units, and refactors large or messy components into clean, well-organized code. Strictly maintains 1:1 logic equivalence — only structure changes, never behavior. Should be used when the user wants to refactor a React component — splitting a monolith, reorganizing a messy file, or restructuring for better maintainability. Distinguished from react-component-extraction which extracts specific reusable pieces, this skill restructures the entire component.","ImaginerLabs\u002Fskill-manager","ImaginerLabs","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F214277308?v=4","01M6QGGDPNF15RMMT1RCFDH9FN","01M6QGGDTH5BY64DQ123NR8M33",0,"MIT","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fcoding\u002Freact-component-refactor\u002FSKILL.md",[17,22,25],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"react","react component refactor","react component","refactor","component","file","code","coding","never","only","reusable","clean","units","structure","logic","monolith","which","for","changes","components","2026-11-10 10:12:30",false,"---\nname: react-component-refactor\ndescription: >-\n  Analyzes React component structure, identifies reusable units, and refactors large or messy components into\n  clean, well-organized code. Strictly maintains 1:1 logic equivalence — only structure changes, never behavior.\n  Should be used when the user wants to refactor a React component — splitting a monolith, reorganizing a\n  messy file, or restructuring for better maintainability.\n  Distinguished from react-component-extraction which extracts specific reusable pieces, this skill\n  restructures the entire component.\ncategory: coding\nboundary:\n  vs_react-component-extraction: \"react-component-extraction extracts specific reusable pieces, this skill restructures the entire component\"\n---\n\n# React Component Refactoring\n\n## Core Capability\n\nAnalyze existing code structure, identify reusable logic, and refactor according to React best practices. **Strictly preserve original logic intent** — only optimize and split at the structure level.\n\nThe difference from `react-component-extraction`: extraction pulls out a specific piece for reuse; refactoring restructures the entire component for clarity and maintainability. Think of extraction as surgery, refactoring as renovation.\n\n## Workflow\n\n```\n1. Confirm refactoring scope and output directory\n2. Analyze code structure (identify reusable units)\n3. Design refactoring plan (seek confirmation)\n4. Execute refactoring\n5. Verify logic equivalence\n```\n\n---\n\n## 1. Pre-refactoring Preparation\n\n### Confirm User Input\n\n| Info                  | Description                                                                 |\n| --------------------- | --------------------------------------------------------------------------- |\n| **Refactoring scope** | File path or code snippet specified by user                                 |\n| **Output directory**  | Where refactored files go (do not change without permission)                |\n| **Refactoring goal**  | Expected outcome (e.g., split sub-components, extract Hooks, full refactor) |\n\n### Code Structure Analysis\n\n```\nAnalysis dimensions:\n├── Component scale: total lines, JSX nesting depth\n├── Responsibility identification: what different responsibilities does this component handle\n├── Duplicate logic: similar JSX structures or logic patterns\n├── State distribution: is state distribution reasonable\n├── Side effects: number and clarity of useEffect responsibilities\n└── Reusable units: what can become independent components or Hooks\n```\n\n---\n\n## 2. Reusable Unit Identification Rules\n\n### Identify as independent component when:\n\n| Condition                                                        | Example                                                     |\n| ---------------------------------------------------------------- | ----------------------------------------------------------- |\n| JSX structure exceeds 30 lines with relatively independent logic | Complex form sections, data display cards                   |\n| Same structure appears 2+ times in the same file                 | Similar list items, repeated button groups                  |\n| Has independent interaction state (expand\u002Fcollapse)              | Collapsible panels, dropdown menus, modal triggers          |\n| Can be used independently from current context                   | Generic Loading state, empty state placeholder, error block |\n\n### Identify as custom Hook when:\n\n| Condition                                                  | Example                                           |\n| ---------------------------------------------------------- | ------------------------------------------------- |\n| Contains 2+ related state values + useEffect               | Data fetching logic (loading + data + error)      |\n| Same Hook combination used in multiple places              | Pagination logic, form validation logic           |\n| Side effect logic not directly tied to UI rendering        | Event listeners, timers, WebSocket connections    |\n| High complexity logic affecting main component readability | Complex filter\u002Fsort logic, permission check logic |\n\n### Keep in original component when:\n\n- Logic is simple (\u003C 10 lines), splitting would increase cognitive overhead\n- Highly coupled with parent state, splitting requires excessive props passing\n- Used only once in current component with no reuse value\n\n---\n\n## 3. Refactoring Plan Design\n\n**Present the plan to the user for confirmation before executing:**\n\n```\nRefactoring plan: [original filename]\n\nOriginal file: src\u002Fpages\u002FOrder\u002Findex.tsx (320 lines)\n\nSplit plan:\n├── ? OrderHeader.tsx        → Extract order header info display (original L12-L58)\n├── ? OrderItemList.tsx      → Extract order item list (original L60-L130)\n├── ? useOrderDetail.ts      → Extract order data fetching logic\n└── ? index.tsx              → Refactored main file (keep core orchestration logic)\n\nOutput directory: src\u002Fpages\u002FOrder\u002Fcomponents\u002F\n\nConfirm execution?\n```\n\n---\n\n## 4. Code Generation Standards\n\n### TypeScript Type Standards\n\n- Props interface must be explicitly defined, required\u002Foptional clearly distinguished\n- Enums\u002Funions prefer TypeScript native types\n\n### Component Structure\n\nEach component file organized in this order: `external imports → internal imports → type definitions → component implementation → exports`\n\n### Custom Hook Standards\n\nHook returns use **object** format (when > 2 return values), including standard `data \u002F loading \u002F error \u002F refetch` fields.\n\n---\n\n## 5. 1:1 Logic Preservation Guarantee\n\n### Never change these:\n\n| Prohibited change        | Why                                                               |\n| ------------------------ | ----------------------------------------------------------------- |\n| **Business logic**       | Conditions, calculations, data processing must remain identical   |\n| **Side effect timing**   | useEffect trigger timing and dependencies must not change         |\n| **State initial values** | All state initial values must match original code                 |\n| **Event handling logic** | Event callback execution logic must not be simplified or modified |\n| **Render conditions**    | All conditional rendering logic must remain consistent            |\n| **Props interface**      | Exposed Props signature must not have breaking changes            |\n\n### Logic Equivalence Verification Checklist\n\n- [ ] Conditional rendering: all &&, ternary conditions match original\n- [ ] List rendering: map data source, key values, render content match original\n- [ ] Event binding: all handler trigger conditions and execution logic unchanged\n- [ ] Side effect dependencies: useEffect dependency arrays and trigger timing unchanged\n- [ ] State flow: state update logic completely identical to original\n\n### Difference Annotation\n\nIf original code has **obvious bugs or anti-patterns**, **do not fix them** — annotate and inform the user:\n\n```typescript\n\u002F\u002F ⚠️ Note: original code uses index as key here, consider changing to item.id later\n{items.map((item, index) => \u003CItem key={index} data={item} \u002F>)}\n```\n\n---\n\n## 6. React Best Practices Check\n\n- All components use function components + Hooks\n- Props interface defined in TypeScript\n- Functions passed to child components wrapped in `useCallback`\n- Objects\u002Farrays passed to child components wrapped in `useMemo`\n- Pure display sub-components wrapped in `React.memo`\n- Async operations in useEffect use AbortController for unmount scenarios\n- List rendering uses stable, unique business IDs as keys\n\n---\n\n## Output Format\n\n```markdown\n## React Component Refactoring Report\n\n### Refactoring Overview\n\n- **Original file**: `[original file path]` (X lines)\n- **Output directory**: `[user-specified directory]`\n- **Split file count**: X\n\n### Split Results\n\n| File           | Type                 | Original lines | Description                |\n| -------------- | -------------------- | -------------- | -------------------------- |\n| ComponentA.tsx | Sub-component        | L12~L58        | Responsibility description |\n| useXxx.ts      | Custom Hook          | L60~L90        | Responsibility description |\n| index.tsx      | Refactored main file | —              | Core orchestration logic   |\n\n### Logic Equivalence Verification\n\n- [ ] Conditional rendering: ✅ Matches original\n- [ ] List rendering: ✅ Key values and data source match\n- [ ] Event binding: ✅ Trigger conditions and execution logic unchanged\n- [ ] Side effect dependencies: ✅ useEffect dependency arrays unchanged\n- [ ] State flow: ✅ State update logic completely identical\n\n### Original Code Issues Found (annotated, not fixed)\n\n- If none: ✅ No obvious bugs or anti-patterns found\n```\n","# React Component Refactoring\n\n## Core Capability\n\nAnalyze existing code structure, identify reusable logic, and refactor according to React best practices. **Strictly preserve original logic intent** — only optimize and split at the structure level.\n\nThe difference from `react-component-extraction`: extraction pulls out a specific piece for reuse; refactoring restructures the entire component for clarity and maintainability. Think of extraction as surgery, refactoring as renovation.\n\n## Workflow\n\n```\n1. Confirm refactoring scope and output directory\n2. Analyze code structure (identify reusable units)\n3. Design refactoring plan (seek confirmation)\n4. Execute refactoring\n5. Verify logic equivalence\n```\n\n---\n\n## 1. Pre-refactoring Preparation\n\n### Confirm User Input\n\n| Info                  | Description                                                                 |\n| --------------------- | --------------------------------------------------------------------------- |\n| **Refactoring scope** | File path or code snippet specified by user                                 |\n| **Output directory**  | Where refactored files go (do not change without permission)                |\n| **Refactoring goal**  | Expected outcome (e.g., split sub-components, extract Hooks, full refactor) |\n\n### Code Structure Analysis\n\n```\nAnalysis dimensions:\n├── Component scale: total lines, JSX nesting depth\n├── Responsibility identification: what different responsibilities does this component handle\n├── Duplicate logic: similar JSX structures or logic patterns\n├── State distribution: is state distribution reasonable\n├── Side effects: number and clarity of useEffect responsibilities\n└── Reusable units: what can become independent components or Hooks\n```\n\n---\n\n## 2. Reusable Unit Identification Rules\n\n### Identify as independent component when:\n\n| Condition                                                        | Example                                                     |\n| ---------------------------------------------------------------- | ----------------------------------------------------------- |\n| JSX structure exceeds 30 lines with relatively independent logic | Complex form sections, data display cards                   |\n| Same structure appears 2+ times in the same file                 | Similar list items, repeated button groups                  |\n| Has independent interaction state (expand\u002Fcollapse)              | Collapsible panels, dropdown menus, modal triggers          |\n| Can be used independently from current context                   | Generic Loading state, empty state placeholder, error block |\n\n### Identify as custom Hook when:\n\n| Condition                                                  | Example                                           |\n| ---------------------------------------------------------- | ------------------------------------------------- |\n| Contains 2+ related state values + useEffect               | Data fetching logic (loading + data + error)      |\n| Same Hook combination used in multiple places              | Pagination logic, form validation logic           |\n| Side effect logic not directly tied to UI rendering        | Event listeners, timers, WebSocket connections    |\n| High complexity logic affecting main component readability | Complex filter\u002Fsort logic, permission check logic |\n\n### Keep in original component when:\n\n- Logic is simple (\u003C 10 lines), splitting would increase cognitive overhead\n- Highly coupled with parent state, splitting requires excessive props passing\n- Used only once in current component with no reuse value\n\n---\n\n## 3. Refactoring Plan Design\n\n**Present the plan to the user for confirmation before executing:**\n\n```\nRefactoring plan: [original filename]\n\nOriginal file: src\u002Fpages\u002FOrder\u002Findex.tsx (320 lines)\n\nSplit plan:\n├── ? OrderHeader.tsx        → Extract order header info display (original L12-L58)\n├── ? OrderItemList.tsx      → Extract order item list (original L60-L130)\n├── ? useOrderDetail.ts      → Extract order data fetching logic\n└── ? index.tsx              → Refactored main file (keep core orchestration logic)\n\nOutput directory: src\u002Fpages\u002FOrder\u002Fcomponents\u002F\n\nConfirm execution?\n```\n\n---\n\n## 4. Code Generation Standards\n\n### TypeScript Type Standards\n\n- Props interface must be explicitly defined, required\u002Foptional clearly distinguished\n- Enums\u002Funions prefer TypeScript native types\n\n### Component Structure\n\nEach component file organized in this order: `external imports → internal imports → type definitions → component implementation → exports`\n\n### Custom Hook Standards\n\nHook returns use **object** format (when > 2 return values), including standard `data \u002F loading \u002F error \u002F refetch` fields.\n\n---\n\n## 5. 1:1 Logic Preservation Guarantee\n\n### Never change these:\n\n| Prohibited change        | Why                                                               |\n| ------------------------ | ----------------------------------------------------------------- |\n| **Business logic**       | Conditions, calculations, data processing must remain identical   |\n| **Side effect timing**   | useEffect trigger timing and dependencies must not change         |\n| **State initial values** | All state initial values must match original code                 |\n| **Event handling logic** | Event callback execution logic must not be simplified or modified |\n| **Render conditions**    | All conditional rendering logic must remain consistent            |\n| **Props interface**      | Exposed Props signature must not have breaking changes            |\n\n### Logic Equivalence Verification Checklist\n\n- [ ] Conditional rendering: all &&, ternary conditions match original\n- [ ] List rendering: map data source, key values, render content match original\n- [ ] Event binding: all handler trigger conditions and execution logic unchanged\n- [ ] Side effect dependencies: useEffect dependency arrays and trigger timing unchanged\n- [ ] State flow: state update logic completely identical to original\n\n### Difference Annotation\n\nIf original code has **obvious bugs or anti-patterns**, **do not fix them** — annotate and inform the user:\n\n```typescript\n\u002F\u002F ⚠️ Note: original code uses index as key here, consider changing to item.id later\n{items.map((item, index) => \u003CItem key={index} data={item} \u002F>)}\n```\n\n---\n\n## 6. React Best Practices Check\n\n- All components use function components + Hooks\n- Props interface defined in TypeScript\n- Functions passed to child components wrapped in `useCallback`\n- Objects\u002Farrays passed to child components wrapped in `useMemo`\n- Pure display sub-components wrapped in `React.memo`\n- Async operations in useEffect use AbortController for unmount scenarios\n- List rendering uses stable, unique business IDs as keys\n\n---\n\n## Output Format\n\n```markdown\n## React Component Refactoring Report\n\n### Refactoring Overview\n\n- **Original file**: `[original file path]` (X lines)\n- **Output directory**: `[user-specified directory]`\n- **Split file count**: X\n\n### Split Results\n\n| File           | Type                 | Original lines | Description                |\n| -------------- | -------------------- | -------------- | -------------------------- |\n| ComponentA.tsx | Sub-component        | L12~L58        | Responsibility description |\n| useXxx.ts      | Custom Hook          | L60~L90        | Responsibility description |\n| index.tsx      | Refactored main file | —              | Core orchestration logic   |\n\n### Logic Equivalence Verification\n\n- [ ] Conditional rendering: ✅ Matches original\n- [ ] List rendering: ✅ Key values and data source match\n- [ ] Event binding: ✅ Trigger conditions and execution logic unchanged\n- [ ] Side effect dependencies: ✅ useEffect dependency arrays unchanged\n- [ ] State flow: ✅ State update logic completely identical\n\n### Original Code Issues Found (annotated, not fixed)\n\n- If none: ✅ No obvious bugs or anti-patterns found\n```\n",{"name":5,"boundary":54,"category":36,"description":7},{"vs_react-component-extraction":55},"react-component-extraction extracts specific reusable pieces, this skill restructures the entire component","main","b9a52d8e27455bdad953d64928696d028223ea1b","skills\u002Fcoding\u002Freact-component-refactor","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager","https:\u002F\u002Fgithub.com\u002FImaginerLabs","2026-04-18 16:27:13",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add ImaginerLabs\u002Fskill-manager --skill react-component-refactor",{"tool":68,"command":69},"bunx","bunx skills add ImaginerLabs\u002Fskill-manager --skill react-component-refactor",{"tool":71,"command":72},"pnpm","pnpm dlx skills add ImaginerLabs\u002Fskill-manager --skill react-component-refactor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fcoding\u002Freact-component-refactor\u002FSKILL.md",true,[76],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fcode-examples.md","REFERENCE","参考文档",3948,"https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fcoding\u002Freact-component-refactor\u002Freferences\u002Fcode-examples.md",[83,113,133,161,194,219],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":95,"publishedAt":49},"01M6QJCB2SD5KHC41ZDQC0GA1T","meeting-minutes","Generate concise, actionable meeting minutes for internal meetings. Includes metadata, attendees, agenda, decisions, action items (owner + due date), and follow-up steps.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fmeeting-minutes\u002FSKILL.md",[89,90],{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":91,"categoryName":92,"taxonomyType":93,"taxonomyTypeDesc":94},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[96,97,98,99,100,101,102,103,104,105,85,56,106,107,108,109,110,111,112,46],"meeting minutes","meeting","minutes","writing","github","copilot","generate","decisions","meetings","up","agenda","actionable","concise","follow-up","tree","true","action",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":49},"01M6QJC71RRGTGNNFEHJG6S20G","documentation-writer","Diátaxis Documentation Expert. An expert technical writer specializing in creating high-quality software documentation, guided by the principles and structure of the Diátaxis technical documentation authoring framework.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdocumentation-writer\u002FSKILL.md",[],[120,121,122,99,100,101,123,124,125,126,127,128,56,42,129,130,131,110,111,132],"documentation","documentation writer","writer","https","quality","technical","technical writer","expert","documentation expert","authoring","software","principles","high",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":146,"publishedAt":49},"01M6QJC0V3C7C4R9768J1AJYWY","doc-coauthoring","Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdoc-coauthoring\u002FSKILL.md",[139,142,143],{"categoryNo":140,"categoryName":141,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":144,"categoryName":145,"taxonomyType":93,"taxonomyTypeDesc":94},"01JBSEEDCAT000000000000036","内容创作者",[147,148,99,149,150,120,151,152,153,154,155,156,56,157,158,129,159,160,110,46],"doc coauthoring","doc","workflow","official","tasks","decision","write","context","proposals","guide","refine","iteration","trigger","co",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":175,"publishedAt":49},"01M6QJBJ0YPVEWGEXZH3PJRRTT","code-review-workflow","Executes comprehensive 4-phase code review: basic review, quality check, bundle analysis, and test coverage. Should be used when the user mentions comprehensive code review, checking code quality, or reviewing staged changes with multi-phase analysis. This is the comprehensive review workflow, distinct from focused skills like frontend-code-review, staged-code-review, or code-change-test-designer.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Ftesting\u002Fcode-review-workflow\u002FSKILL.md",[167,168,171,172],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":169,"categoryName":170,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":173,"categoryName":174,"taxonomyType":93,"taxonomyTypeDesc":94},"01JBSEEDCAT000000000000030","开发工程师",[176,177,149,35,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193],"code review","review","code review workflow","testing","frontend","test","change","code quality","code-review","analysis","check","coverage","quality check","basic","multi","comprehensive code review","with","phase",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":209,"publishedAt":49},"01M6QJB7XNHV3VEEQF4W7FMWF6","code-change-test-designer","Analyzes code changes and designs comprehensive test cases. Reads diffs, summarizes capability changes, and designs test cases covering main flows and edge cases. Should be used when the user mentions test coverage, designing tests for code changes, or analyzing diff\u002Fcommit for testing purposes. Distinguished from code-review-workflow which provides comprehensive review, this skill focuses on test case design for code changes.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Ftesting\u002Fcode-change-test-designer\u002FSKILL.md",[200,201,204,205,206],{"categoryNo":169,"categoryName":170,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":202,"categoryName":203,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":173,"categoryName":174,"taxonomyType":93,"taxonomyTypeDesc":94},{"categoryNo":207,"categoryName":208,"taxonomyType":93,"taxonomyTypeDesc":94},"01JBSEEDCAT000000000000032","设计师",[181,182,35,210,211,179,212,213,149,214,184,215,187,216,56,217,218,45,46,193],"designer","code change test designer","design","diffs","commit","edge","diff","tests","flows",{"skillNo":220,"name":221,"nameZh":6,"description":222,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":223,"categories":224,"keywords":226,"publishedAt":49},"01M6QJB195WD7DCJWDMKWKB29S","skill-creator","Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fmeta-skills\u002Fskill-creator\u002FSKILL.md",[225],{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},[227,228,229,230,150,231,232,233,234,235,185,236,237,238,56,239,240,110,46,221],"skill creator","creator","performance","run evals","variance analysis","create","run","benchmark","Meta","improve","edit","evals","optimize","existing skill"]