[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6QJ3TKM1QYFTPCZ1XDY92TM":3,"skill-same:01M6QJ3TKM1QYFTPCZ1XDY92TM":86},{"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":30,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":66,"commitSha":67,"skillDirectory":68,"forksCount":13,"repositoryHtmlUrl":69,"repositoryHomepageUrl":6,"ownerHtmlUrl":70,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":71,"install":72,"resources":85},"01M6QJ3TKM1QYFTPCZ1XDY92TM","safe-refactor",null,"Chain-combined skill that ensures refactoring is done safely by combining refactor judgment, test coverage verification, and pre-commit review. Encapsulates the decision of WHEN to refactor, HOW to ensure safety, and WHAT verification is needed. Use when user mentions refactoring, code restructuring, improving code quality, or when they want to refactor without breaking behavior. Triggers especially when user says \"should I refactor this?\", \"is it safe to refactor?\", \"how do I refactor without breaking things?\", or \"refactor my code\".","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\u002Fsafe-refactor\u002FSKILL.md",[17,22,25],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":26,"categoryName":27,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"safe","safe refactor","refactor","combined","review","my","how to","chain","judgment","done","test coverage","coverage","decision","refactoring","how","Safety","doublecheck","verification","code","commit","2026-11-10 10:12:30",false,"---\nname: safe-refactor\ndescription: >-\n  Chain-combined skill that ensures refactoring is done safely by combining refactor judgment, test coverage verification, and pre-commit review. Encapsulates the decision of WHEN to refactor, HOW to ensure safety, and WHAT verification is needed. Use when user mentions refactoring, code restructuring, improving code quality, or when they want to refactor without breaking behavior. Triggers especially when user says \"should I refactor this?\", \"is it safe to refactor?\", \"how do I refactor without breaking things?\", or \"refactor my code\".\ncategory: coding\npriority: P0\ntrigger_patterns:\n  - \"safe refactor\"\n  - \"refactor without breaking\"\n  - \"should I refactor\"\n  - \"refactor checklist\"\n  - \"refactor safety\"\n  - \"code restructuring\"\ncombines:\n  - refactor\n  - doublecheck\n  - test-think\n---\n\n# Safe Refactor — Behavioral Specification for Secure Code Restructuring\n\n## Overview\n\nSafe-refactor is a **chain-combined behavioral specification skill** that merges:\n\n- `refactor` — When and how to refactor judgment\n- `doublecheck` — Verification and safety checks\n- `test-think` — Test coverage decisions\n\nThe core judgment it encapsulates: **\"How do I refactor this code while ensuring I don't change its behavior?\"**\n\nThis skill embodies the mindset of an experienced developer who knows that refactoring without tests is gambling.\n\n## Core Philosophy\n\n### The Refactoring Contract\n\n> \"Refactoring changes the structure of code, not its behavior.\"\n\nThis is the fundamental contract. If behavior changes, it's not refactoring — it's a feature change or bug fix, and needs appropriate process.\n\n### The Safety Equation\n\n```\n┌─────────────────────────────────────────────────────┐\n│                    SAFE REFACTOR                     │\n│                                                     │\n│    Existing Tests ─────┐                            │\n│                        ├──► SAFE TO REFACTOR        │\n│    Coverage Good? ─────┘                            │\n│                                                     │\n│    Existing Tests ─────┐                            │\n│                        ├──► ADD TESTS FIRST         │\n│    Coverage Poor? ─────┘                            │\n└─────────────────────────────────────────────────────┘\n```\n\n## Behavioral Specification\n\n### Phase 1: Refactor Readiness Assessment\n\nBefore touching any code, answer these questions:\n\n#### 1.1 Why Are You Refactoring?\n\n| Reason | Proceed? | Notes |\n|--------|----------|-------|\n| \"Code is messy\" | ? Maybe | Define success criteria first |\n| \"Hard to add feature\" | ✅ Yes | Ensure tests cover feature path |\n| \"Performance\" | ✅ Yes | Benchmark before\u002Fafter |\n| \"Learning the code\" | ✅ Yes | But don't merge until understood |\n| \"Just feels old\" | ❌ No | YAGNI applies to structure too |\n\n#### 1.2 What Will Change?\n\nMap out the scope:\n\n```markdown\n## Refactoring Scope\n\n### High-Risk Changes (Require Extra Care)\n- [ ] Changing function signatures\n- [ ] Moving code between modules\n- [ ] Changing data structures\n- [ ] Modifying shared utilities\n\n### Medium-Risk Changes\n- [ ] Extracting functions\n- [ ] Renaming variables\n- [ ] Reordering code\n\n### Low-Risk Changes\n- [ ] Formatting\n- [ ] Comment improvements\n- [ ] Renaming (non-shared)\n```\n\n#### 1.3 What's the Blast Radius?\n\n```bash\n# Find all usages\ngrep -r \"functionName\" --include=\"*.ts\" src\u002F\n\n# Check if it's a shared utility\n# Check how many files depend on it\n```\n\n### Phase 2: Test Coverage Verification\n\n#### 2.1 Test Coverage Check\n\n```markdown\n## Current Test Coverage Analysis\n\n| Module | Coverage | Tests | Action |\n|--------|----------|-------|--------|\n| utils.ts | 45% | 2 | Add tests before refactor |\n| auth.ts | 89% | 12 | Safe to refactor |\n| payment.ts | 0% | 0 | MUST add tests first |\n```\n\n#### 2.2 Critical Path Identification\n\nBefore refactoring, identify what's MOST important to keep working:\n\n```\n┌────────────────────────────────────────────────────────────┐\n│                    CRITICAL PATH MAP                       │\n│                                                             │\n│    User ──► Login ──► Dashboard ──► Action ──► Result     │\n│                    │              │                        │\n│                    │              └──► Analytics           │\n│                    │                                     │\n│                    └──► Notifications                     │\n│                                                             │\n│    Must keep working: Auth, Core business logic            │\n└────────────────────────────────────────────────────────────┘\n```\n\n#### 2.3 Test-Then-Refactor Protocol\n\nFor modules with poor coverage:\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│  UNSAFE → SAFE REFACTORING                                  │\n│                                                             │\n│  1. BEFORE: Write tests for current behavior                │\n│     - Don't change behavior, just document it               │\n│     - Tests should FAIL if behavior changes                 │\n│                                                             │\n│  2. REFACTOR: Make structural changes                       │\n│     - Keep behavior identical                              │\n│     - Tests should STILL PASS                              │\n│                                                             │\n│  3. AFTER: Verify all tests pass                           │\n│     - If tests fail, behavior changed                      │\n│     - Fix the refactor, not the tests                       │\n└─────────────────────────────────────────────────────────────┘\n```\n\n### Phase 3: Refactoring Execution\n\n#### 3.1 Small Steps Protocol\n\n**Rule: Commit after each logical step.**\n\n```bash\n# Step 1: Extract function\ngit commit -m \"refactor: extract validateEmail from processUser\"\n\n# Step 2: Move to new module\ngit commit -m \"refactor: move validateEmail to utils\u002Fvalidation\"\n\n# Step 3: Update imports\ngit commit -m \"refactor: update imports to use utils\u002Fvalidation\"\n\n# Step 4: Clean up\ngit commit -m \"refactor: remove duplicate validation\"\n```\n\n**Never do multiple refactorings in one commit.**\n\n#### 3.2 The Boy Scout Rule\n\n> \"Leave the code cleaner than you found it.\"\n\nBut only clean what you came to clean. Don't get distracted by other issues.\n\n### Phase 4: Verification\n\n#### 4.1 Pre-Commit Checklist\n\n```\nSAFE REFACTOR CHECKLIST\n=======================\n\nPRE-REFACTOR\n□ Understand why you're refactoring\n□ Identify blast radius\n□ Ensure tests exist for critical paths\n□ Coverage is acceptable (or tests added)\n□ Define success criteria\n\nDURING REFACTOR\n□ Behavior unchanged (tests pass throughout)\n□ Small steps, one logical change at a time\n□ Tests still pass after each step\n□ No shortcuts or workarounds added\n\nPOST-REFACTOR\n□ All tests pass\n□ Coverage maintained or improved\n□ No new code smells introduced\n□ Documentation updated (if needed)\n□ Peer review (if high-risk)\n```\n\n#### 4.2 Behavior Verification\n\nRun these to confirm behavior is preserved:\n\n```bash\n# Unit tests\nnpm test\n\n# E2E tests (if available)\nnpm run test:e2e\n\n# Manual smoke tests\n- Login flow works\n- Core feature works\n- Error handling works\n```\n\n## Risk-Based Refactoring Strategy\n\n### Low Risk (Self-Refactor)\n\n| Characteristics | Examples |\n|------------------|----------|\n| Small scope | 1-2 files |\n| No shared code | Internal to module |\n| Good tests | >80% coverage |\n| Well-understood | Already worked with |\n\n**Strategy:** Refactor with care, verify with tests.\n\n### Medium Risk (Peer Review)\n\n| Characteristics | Examples |\n|------------------|----------|\n| Medium scope | 3-10 files |\n| Some shared code | 2-3 consumers |\n| Good tests | 60-80% coverage |\n| Partially understood | Some uncertainty |\n\n**Strategy:** Self-refactor + quick peer review before merge.\n\n### High Risk (Must Have Review)\n\n| Characteristics | Examples |\n|------------------|----------|\n| Large scope | 10+ files |\n| Highly shared | 10+ consumers |\n| Poor tests | \u003C60% coverage |\n| Unfamiliar code | Legacy\u002Ftouch |\n| Security sensitive | Auth\u002Fdata |\n\n**Strategy:** Pair programming or detailed review required.\n\n## Common Scenarios\n\n### Scenario 1: \"I want to rename this function\"\n\n```markdown\nAnalysis:\n- Function used in 15 files\n- Medium risk\n\nSteps:\n1. [ ] Find all usages (grep)\n2. [ ] Write test that calls the function (if none exists)\n3. [ ] Rename the function\n4. [ ] Update all references\n5. [ ] Run tests\n6. [ ] Commit\n```\n\n### Scenario 2: \"This component is too large, I want to split it\"\n\n```markdown\nAnalysis:\n- Single component, 500 lines\n- Hooks state management\n- High risk\n\nSteps:\n1. [ ] Identify logical sections (useEffect, handlers, render)\n2. [ ] Write tests for the component\n3. [ ] Extract one logical piece at a time\n4. [ ] Create child component\n5. [ ] Move related state\u002Flogic to child\n6. [ ] Verify parent still works\n7. [ ] Repeat until done\n```\n\n### Scenario 3: \"I want to change this shared utility\"\n\n```markdown\nAnalysis:\n- Shared by 20+ files\n- Low test coverage (30%)\n- HIGH RISK\n\nSteps:\n1. [ ] MUST increase test coverage first\n2. [ ] Write tests for all known use cases\n3. [ ] Consider if change is truly necessary\n4. [ ] If yes, make smallest possible change\n5. [ ] Update all consumers\n6. [ ] Run full test suite\n7. [ ] Mandatory peer review\n```\n\n## Key Principles\n\n### 1. Tests Are the Contract\n\nIf you don't have tests, you can't refactor safely. Tests prove behavior is preserved.\n\n### 2. Small Commits, Small Risk\n\nThe smaller the change, the easier to verify. Large refactors are just many small ones queued up.\n\n### 3. If It's Hard to Test, It's Hard to Refactor\n\nDifficult-to-test code usually has design problems. Fix the design, then refactor.\n\n### 4. Don't Mix Refactoring with Feature Work\n\nSeparate commits for refactoring and feature changes. This makes rollback easier and review clearer.\n\n### 5. When in Doubt, Add More Tests\n\nThe cost of tests is low. The cost of breaking production is high.\n\n## Relationship to Other Skills\n\n- `refactor` — The refactoring judgment this builds upon\n- `doublecheck` — Verification patterns\n- `test-think` — Test coverage decisions\n- `pre-commit-review` — Pre-commit verification\n- `debug-session` — If something goes wrong during refactor\n","# Safe Refactor — Behavioral Specification for Secure Code Restructuring\n\n## Overview\n\nSafe-refactor is a **chain-combined behavioral specification skill** that merges:\n\n- `refactor` — When and how to refactor judgment\n- `doublecheck` — Verification and safety checks\n- `test-think` — Test coverage decisions\n\nThe core judgment it encapsulates: **\"How do I refactor this code while ensuring I don't change its behavior?\"**\n\nThis skill embodies the mindset of an experienced developer who knows that refactoring without tests is gambling.\n\n## Core Philosophy\n\n### The Refactoring Contract\n\n> \"Refactoring changes the structure of code, not its behavior.\"\n\nThis is the fundamental contract. If behavior changes, it's not refactoring — it's a feature change or bug fix, and needs appropriate process.\n\n### The Safety Equation\n\n```\n┌─────────────────────────────────────────────────────┐\n│                    SAFE REFACTOR                     │\n│                                                     │\n│    Existing Tests ─────┐                            │\n│                        ├──► SAFE TO REFACTOR        │\n│    Coverage Good? ─────┘                            │\n│                                                     │\n│    Existing Tests ─────┐                            │\n│                        ├──► ADD TESTS FIRST         │\n│    Coverage Poor? ─────┘                            │\n└─────────────────────────────────────────────────────┘\n```\n\n## Behavioral Specification\n\n### Phase 1: Refactor Readiness Assessment\n\nBefore touching any code, answer these questions:\n\n#### 1.1 Why Are You Refactoring?\n\n| Reason | Proceed? | Notes |\n|--------|----------|-------|\n| \"Code is messy\" | ? Maybe | Define success criteria first |\n| \"Hard to add feature\" | ✅ Yes | Ensure tests cover feature path |\n| \"Performance\" | ✅ Yes | Benchmark before\u002Fafter |\n| \"Learning the code\" | ✅ Yes | But don't merge until understood |\n| \"Just feels old\" | ❌ No | YAGNI applies to structure too |\n\n#### 1.2 What Will Change?\n\nMap out the scope:\n\n```markdown\n## Refactoring Scope\n\n### High-Risk Changes (Require Extra Care)\n- [ ] Changing function signatures\n- [ ] Moving code between modules\n- [ ] Changing data structures\n- [ ] Modifying shared utilities\n\n### Medium-Risk Changes\n- [ ] Extracting functions\n- [ ] Renaming variables\n- [ ] Reordering code\n\n### Low-Risk Changes\n- [ ] Formatting\n- [ ] Comment improvements\n- [ ] Renaming (non-shared)\n```\n\n#### 1.3 What's the Blast Radius?\n\n```bash\n# Find all usages\ngrep -r \"functionName\" --include=\"*.ts\" src\u002F\n\n# Check if it's a shared utility\n# Check how many files depend on it\n```\n\n### Phase 2: Test Coverage Verification\n\n#### 2.1 Test Coverage Check\n\n```markdown\n## Current Test Coverage Analysis\n\n| Module | Coverage | Tests | Action |\n|--------|----------|-------|--------|\n| utils.ts | 45% | 2 | Add tests before refactor |\n| auth.ts | 89% | 12 | Safe to refactor |\n| payment.ts | 0% | 0 | MUST add tests first |\n```\n\n#### 2.2 Critical Path Identification\n\nBefore refactoring, identify what's MOST important to keep working:\n\n```\n┌────────────────────────────────────────────────────────────┐\n│                    CRITICAL PATH MAP                       │\n│                                                             │\n│    User ──► Login ──► Dashboard ──► Action ──► Result     │\n│                    │              │                        │\n│                    │              └──► Analytics           │\n│                    │                                     │\n│                    └──► Notifications                     │\n│                                                             │\n│    Must keep working: Auth, Core business logic            │\n└────────────────────────────────────────────────────────────┘\n```\n\n#### 2.3 Test-Then-Refactor Protocol\n\nFor modules with poor coverage:\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│  UNSAFE → SAFE REFACTORING                                  │\n│                                                             │\n│  1. BEFORE: Write tests for current behavior                │\n│     - Don't change behavior, just document it               │\n│     - Tests should FAIL if behavior changes                 │\n│                                                             │\n│  2. REFACTOR: Make structural changes                       │\n│     - Keep behavior identical                              │\n│     - Tests should STILL PASS                              │\n│                                                             │\n│  3. AFTER: Verify all tests pass                           │\n│     - If tests fail, behavior changed                      │\n│     - Fix the refactor, not the tests                       │\n└─────────────────────────────────────────────────────────────┘\n```\n\n### Phase 3: Refactoring Execution\n\n#### 3.1 Small Steps Protocol\n\n**Rule: Commit after each logical step.**\n\n```bash\n# Step 1: Extract function\ngit commit -m \"refactor: extract validateEmail from processUser\"\n\n# Step 2: Move to new module\ngit commit -m \"refactor: move validateEmail to utils\u002Fvalidation\"\n\n# Step 3: Update imports\ngit commit -m \"refactor: update imports to use utils\u002Fvalidation\"\n\n# Step 4: Clean up\ngit commit -m \"refactor: remove duplicate validation\"\n```\n\n**Never do multiple refactorings in one commit.**\n\n#### 3.2 The Boy Scout Rule\n\n> \"Leave the code cleaner than you found it.\"\n\nBut only clean what you came to clean. Don't get distracted by other issues.\n\n### Phase 4: Verification\n\n#### 4.1 Pre-Commit Checklist\n\n```\nSAFE REFACTOR CHECKLIST\n=======================\n\nPRE-REFACTOR\n□ Understand why you're refactoring\n□ Identify blast radius\n□ Ensure tests exist for critical paths\n□ Coverage is acceptable (or tests added)\n□ Define success criteria\n\nDURING REFACTOR\n□ Behavior unchanged (tests pass throughout)\n□ Small steps, one logical change at a time\n□ Tests still pass after each step\n□ No shortcuts or workarounds added\n\nPOST-REFACTOR\n□ All tests pass\n□ Coverage maintained or improved\n□ No new code smells introduced\n□ Documentation updated (if needed)\n□ Peer review (if high-risk)\n```\n\n#### 4.2 Behavior Verification\n\nRun these to confirm behavior is preserved:\n\n```bash\n# Unit tests\nnpm test\n\n# E2E tests (if available)\nnpm run test:e2e\n\n# Manual smoke tests\n- Login flow works\n- Core feature works\n- Error handling works\n```\n\n## Risk-Based Refactoring Strategy\n\n### Low Risk (Self-Refactor)\n\n| Characteristics | Examples |\n|------------------|----------|\n| Small scope | 1-2 files |\n| No shared code | Internal to module |\n| Good tests | >80% coverage |\n| Well-understood | Already worked with |\n\n**Strategy:** Refactor with care, verify with tests.\n\n### Medium Risk (Peer Review)\n\n| Characteristics | Examples |\n|------------------|----------|\n| Medium scope | 3-10 files |\n| Some shared code | 2-3 consumers |\n| Good tests | 60-80% coverage |\n| Partially understood | Some uncertainty |\n\n**Strategy:** Self-refactor + quick peer review before merge.\n\n### High Risk (Must Have Review)\n\n| Characteristics | Examples |\n|------------------|----------|\n| Large scope | 10+ files |\n| Highly shared | 10+ consumers |\n| Poor tests | \u003C60% coverage |\n| Unfamiliar code | Legacy\u002Ftouch |\n| Security sensitive | Auth\u002Fdata |\n\n**Strategy:** Pair programming or detailed review required.\n\n## Common Scenarios\n\n### Scenario 1: \"I want to rename this function\"\n\n```markdown\nAnalysis:\n- Function used in 15 files\n- Medium risk\n\nSteps:\n1. [ ] Find all usages (grep)\n2. [ ] Write test that calls the function (if none exists)\n3. [ ] Rename the function\n4. [ ] Update all references\n5. [ ] Run tests\n6. [ ] Commit\n```\n\n### Scenario 2: \"This component is too large, I want to split it\"\n\n```markdown\nAnalysis:\n- Single component, 500 lines\n- Hooks state management\n- High risk\n\nSteps:\n1. [ ] Identify logical sections (useEffect, handlers, render)\n2. [ ] Write tests for the component\n3. [ ] Extract one logical piece at a time\n4. [ ] Create child component\n5. [ ] Move related state\u002Flogic to child\n6. [ ] Verify parent still works\n7. [ ] Repeat until done\n```\n\n### Scenario 3: \"I want to change this shared utility\"\n\n```markdown\nAnalysis:\n- Shared by 20+ files\n- Low test coverage (30%)\n- HIGH RISK\n\nSteps:\n1. [ ] MUST increase test coverage first\n2. [ ] Write tests for all known use cases\n3. [ ] Consider if change is truly necessary\n4. [ ] If yes, make smallest possible change\n5. [ ] Update all consumers\n6. [ ] Run full test suite\n7. [ ] Mandatory peer review\n```\n\n## Key Principles\n\n### 1. Tests Are the Contract\n\nIf you don't have tests, you can't refactor safely. Tests prove behavior is preserved.\n\n### 2. Small Commits, Small Risk\n\nThe smaller the change, the easier to verify. Large refactors are just many small ones queued up.\n\n### 3. If It's Hard to Test, It's Hard to Refactor\n\nDifficult-to-test code usually has design problems. Fix the design, then refactor.\n\n### 4. Don't Mix Refactoring with Feature Work\n\nSeparate commits for refactoring and feature changes. This makes rollback easier and review clearer.\n\n### 5. When in Doubt, Add More Tests\n\nThe cost of tests is low. The cost of breaking production is high.\n\n## Relationship to Other Skills\n\n- `refactor` — The refactoring judgment this builds upon\n- `doublecheck` — Verification patterns\n- `test-think` — Test coverage decisions\n- `pre-commit-review` — Pre-commit verification\n- `debug-session` — If something goes wrong during refactor\n",{"name":5,"category":56,"combines":57,"priority":59,"description":7,"trigger_patterns":60},"coding",[33,47,58],"test-think","P0",[32,61,62,63,64,65],"refactor without breaking","should I refactor","refactor checklist","refactor safety","code restructuring","main","b9a52d8e27455bdad953d64928696d028223ea1b","skills\u002Fcoding\u002Fsafe-refactor","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager","https:\u002F\u002Fgithub.com\u002FImaginerLabs","2026-04-18 16:27:13",{"source":8,"skillName":5,"commands":73,"prompt":83,"zipAvailable":84},[74,77,80],{"tool":75,"command":76},"npx","npx skills add ImaginerLabs\u002Fskill-manager --skill safe-refactor",{"tool":78,"command":79},"bunx","bunx skills add ImaginerLabs\u002Fskill-manager --skill safe-refactor",{"tool":81,"command":82},"pnpm","pnpm dlx skills add ImaginerLabs\u002Fskill-manager --skill safe-refactor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fcoding\u002Fsafe-refactor\u002FSKILL.md",true,[],[87,118,139,166,193,218],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":99,"publishedAt":51},"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",[93,96],{"categoryNo":94,"categoryName":95,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":97,"categoryName":98,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000034","行政与办公人员",[100,101,102,103,104,105,106,107,108,109,89,66,110,111,112,113,114,115,116,117],"meeting minutes","meeting","minutes","writing","github","copilot","generate","decisions","meetings","up","agenda","actionable","concise","follow-up","tree","true","action","for",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"publishedAt":51},"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",[],[125,126,127,103,104,105,128,129,130,131,132,133,66,134,135,136,137,114,115,138],"documentation","documentation writer","writer","https","quality","technical","technical writer","expert","documentation expert","structure","authoring","software","principles","high",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":152,"publishedAt":51},"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",[145,148,149],{"categoryNo":146,"categoryName":147,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":94,"categoryName":95,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":150,"categoryName":151,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000036","内容创作者",[153,154,103,155,156,125,157,43,158,159,160,161,66,162,163,135,164,165,114,117],"doc coauthoring","doc","workflow","official","tasks","write","context","proposals","guide","refine","iteration","trigger","co",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":176,"publishedAt":51},"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",[172,173,174,175],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":94,"categoryName":95,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":26,"categoryName":27,"taxonomyType":28,"taxonomyTypeDesc":29},[177,35,155,49,178,179,180,181,182,183,184,185,186,42,187,188,189,190,191,192],"code review","code review workflow","testing","frontend","test","change","code quality","code-review","analysis","check","quality check","basic","multi","comprehensive code review","with","phase",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":208,"publishedAt":51},"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",[199,200,203,204,205],{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":201,"categoryName":202,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":94,"categoryName":95,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":26,"categoryName":27,"taxonomyType":28,"taxonomyTypeDesc":29},{"categoryNo":206,"categoryName":207,"taxonomyType":28,"taxonomyTypeDesc":29},"01JBSEEDCAT000000000000032","设计师",[181,182,49,209,210,179,211,212,155,50,184,213,42,214,66,215,216,217,117,192],"designer","code change test designer","design","diffs","edge","diff","tests","flows","which",{"skillNo":219,"name":220,"nameZh":6,"description":221,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":222,"categories":223,"keywords":225,"publishedAt":51},"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",[224],{"categoryNo":94,"categoryName":95,"taxonomyType":20,"taxonomyTypeDesc":21},[226,227,228,229,156,230,231,232,233,234,185,235,236,237,66,238,239,114,117,220],"skill creator","creator","performance","run evals","variance analysis","create","run","benchmark","Meta","improve","edit","evals","optimize","existing skill"]