[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PF64047DTYACP2KJFSBX61":3,"skill-same:01M6PF64047DTYACP2KJFSBX61":68},{"skillNo":4,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":26,"linkOnly":27,"markdownContent":28,"markdownBody":29,"frontMatter":30,"refName":31,"commitSha":32,"skillDirectory":33,"forksCount":34,"repositoryHtmlUrl":35,"repositoryHomepageUrl":6,"ownerHtmlUrl":36,"ownerBlogUrl":37,"ownerDescription":38,"updatedAt":39,"install":40,"resources":53},"01M6PF64047DTYACP2KJFSBX61","refactor-guide",null,"openJiuwen-ai\u002Fagent-core-java","openJiuwen-ai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F264091041?v=4","01M6PF3SW90T9MK2B9PHFDAE9C","openJiuwen","01M6PF3T0P2A1EYWG3JACQS3MQ",49,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FopenJiuwen-ai\u002Fagent-core-java\u002Fblob\u002Fdevelop\u002F.claude\u002Fskills\u002Frefactor-guide\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",[23,24,25],"refactor","guide","refactor guide","2026-11-10 10:12:30",false,"---\nname: refactor-guide\ndescription: Project refactoring standards and process governance. Automatically applied when users want to refactor code, split classes, extract methods, add tests, change signatures, or change architecture, ensuring refactoring is safe and verifiable. Related keywords: refactoring, refactor, extract method, split class, add tests, characterization test, Strangler Fig, L1-L4 refactoring granularity, safe refactoring. Not applicable to: coding style issues (use coding-standard), JVM troubleshooting (use jvm-troubleshoot), new feature development (not refactoring).\n---\n\n# Project Refactoring Standards and Process Governance\n\nThis skill addresses the core pain points of refactoring: **refactoring without tests, no verification after changes, interruptions mid-refactoring, introducing new bugs**. The principle is \"add tests first, then verify; take small steps.\"\n\n## Pre-Refactoring Checklist (Stop If Not Satisfied)\n\nAll of the following must be met before refactoring. No exceptions:\n\n- [ ] **Sufficient test coverage**: Core logic coverage > 70%. No tests -> add \"characterization tests\" first (record current behavior, even if it has bugs), then refactor\n- [ ] **Tests are currently green**: `mvn test` passes, establishing a \"it was working before refactoring\" baseline\n- [ ] **Clear refactoring goal**: Can state in one sentence \"what problem this refactoring solves\", not \"just tidying up while I'm at it\"\n- [ ] **Rollback plan**: Work on a separate git branch, or have a backup\n- [ ] **Refactoring scope is defined**: List the files to be changed; do not change code outside the scope just because it \"looks bad\"\n\n**How to write characterization tests** (emergency when there are no tests):\n```java\n\u002F\u002F Record current behavior, do not judge right or wrong\n@Test\nvoid characterize_currentBehavior_ofCalc() {\n    assertEquals(42, calc.compute(1, 2, 3));  \u002F\u002F Even if 42 is a bug, record it first\n    assertEquals(0, calc.compute(0, 0, 0));\n    assertNull(calc.compute(null, null, null));  \u002F\u002F Record current NPE too\n}\n```\n\n## Refactoring Granularity Levels\n\n4 levels by risk and impact scope, each with different process requirements:\n\n| Level | Scope | Example | Process Requirements |\n|---|---|---|---|\n| **L1 Surface Refactoring** | Single file, no signature change | Rename variable, extract constant, format adjustment | Run unit tests after changes |\n| **L2 Structural Refactoring** | Single file, change internal structure | Extract method, inline method, move function | Run unit tests + integration tests after changes |\n| **L3 Interface Refactoring** | Multiple files, change signature | Change method signature, split class, merge classes | Change tests first, then implementation, run full test suite |\n| **L4 Architecture Refactoring** | Cross-module, change dependencies | Switch framework, split microservices, change data flow | Phased approach, each phase independently testable and rollbackable |\n\n**How to determine level**: If changes affect callers -> at least L3; if cross-module -> L4.\n\n## Standard Refactoring Process (5 Steps, Small Steps)\n\n1. **Green baseline**: `mvn test` passes. If it fails, fix bugs first. Do not refactor on broken code.\n2. **Add tests**: Add tests for the code to be changed. If coverage is insufficient, add more cases. Focus on **the parts being changed** and **affected callers**.\n3. **Small-step refactoring**: Only one atomic action per step (extract one method \u002F rename one variable \u002F move one function). Run tests immediately after each change.\n4. **Commit checkpoint**: `git commit` after each atomic refactoring. Write clear commit messages describing what was done. This enables `git bisect` for locating issues and `git revert` for rollback.\n5. **Verify**: Run full test suite + integration tests + manual verification of critical paths. L3\u002FL4 also requires performance baseline comparison.\n\n**Key principle**: Do not make 10 changes then run tests. When something breaks, you cannot pinpoint which step introduced the problem.\n\n## Refactoring Action List\n\nStandard approaches for common refactoring scenarios:\n\n| Scenario | Refactoring Action | Notes |\n|---|---|---|\n| Method too long | Extract Method | After extraction, method name should express intent; if too many parameters, encapsulate into an object |\n| Duplicate code | Extract common method \u002F Template Method | Do not over-abstract; extract only after **3 repetitions** (rule of three) |\n| Class too large | Split class \u002F Extract responsibility | First ask \"how many responsibilities does this class have\"; only split when Single Responsibility is violated |\n| Deep nesting | Extract method \u002F Early return \u002F Guard clause | Reduce nesting levels; prefer guard clauses for early return |\n| Magic numbers | Extract constant | Constant name should express business meaning, not `NUM_42` |\n| Too many parameters | Encapsulate parameter object | Do not create a \"parameter bag\" anti-pattern (one class holding all parameters) |\n| Switch branches | Replace with polymorphism \u002F Strategy pattern | Use switch for fixed branches; use Strategy pattern for extensible branches |\n| Global variables | Dependency injection | Reduce static; use constructor injection or method injection |\n| Complex conditions | Extract judgment method \u002F Strategy pattern | `if (a && b || c)` -> `if (shouldExecute(a, b, c))` |\n\n## Safe Refactoring Techniques\n\n4 patterns to avoid \"code breaks mid-refactoring\":\n\n### 1. Strangler Fig Pattern\n\nNew code gradually replaces old code; old code is kept until verification is complete, then deleted:\n\n```\n\u002F\u002F Phase 1: New implementation coexists\npublic Result process(Input in) {\n    if (featureFlag.useNew()) {\n        return newProcess(in);   \u002F\u002F New implementation\n    }\n    return oldProcess(in);       \u002F\u002F Old implementation kept\n}\n\n\u002F\u002F Phase 2: After canary verification, traffic switches to new implementation\n\u002F\u002F Phase 3: Delete old implementation\n```\n\nApplicable to: L4 architecture refactoring, replacing entire modules.\n\n### 2. Parallel Implementation + Toggle Switch\n\nNew and old implementations coexist, configuration toggle switches between them; instant rollback if problems occur:\n\n```java\nif (config.getBoolean(\"use.new.parser\")) {\n    return newParser.parse(input);\n} else {\n    return oldParser.parse(input);\n}\n```\n\nApplicable to: Switching frameworks, algorithms, or data sources.\n\n### 3. Shadow Traffic\n\nNew and old implementations run simultaneously, results are compared, without affecting production:\n\n```java\nResult official = oldProcess(input);          \u002F\u002F Production uses this\nResult shadow = newProcess(input);             \u002F\u002F Shadow run, does not affect return\nlogCompare(official, shadow);                  \u002F\u002F Compare, alert on inconsistency\nreturn official;\n```\n\nApplicable to: Core path refactoring where direct switchover is not possible.\n\n### 4. Commit Checkpoints\n\n`git commit` after each atomic refactoring, enabling rollback and bisect:\n\n```bash\ngit commit -m \"refactor: extract computeTax method from calculate\"\n# Run tests, green\ngit commit -m \"refactor: rename price -> unitPrice\"\n# Run tests, red -> git revert HEAD, go back to previous step\n```\n\nApplicable to: All levels of refactoring, **mandatory**.\n\n## Anti-Patterns (Do Not Refactor This Way)\n\n| Anti-Pattern | Problem | Correct Approach |\n|---|---|---|\n| **Big Bang refactoring** | Change for a week before running tests; cannot locate issues when something breaks | Small steps, commit + test at each step |\n| **Opportunistic refactoring** | Tidying up unrelated code while fixing a bug, expanding the change scope | Refactoring and bug fixes in separate commits, separate PRs |\n| **Refactoring without tests** | Changing code based on \"I understand this code\" | Add characterization tests first, then refactor |\n| **Refactoring + logic change** | Mixing refactoring with behavior changes, impossible to distinguish | Refactoring does not change behavior; logic changes in separate commits |\n| **Cross-branch refactoring** | Multiple branches refactoring simultaneously, merge conflict hell | Complete refactoring in one branch, then cherry-pick |\n\n## Phased Strategy for L3\u002FL4 Refactoring\n\nL3 (interface refactoring) and L4 (architecture refactoring) must be phased, with each phase independently testable and rollbackable:\n\n### L3 Interface Refactoring Example (Change Method Signature)\n\n```\nPhase 1: New signature + old signature coexist (old signature delegates to new signature)\nPhase 2: All callers migrate to new signature\nPhase 3: Delete old signature\n```\n\nOne commit per phase, run full test suite after each phase.\n\n### L4 Architecture Refactoring Example (Split Microservices)\n\n```\nPhase 1: Set up new service, no traffic (independently testable)\nPhase 2: Strangler Fig connects to new service, shadow traffic comparison\nPhase 3: Canary traffic shift to new service\nPhase 4: Decommission old service\n```\n\nPhases may be weeks apart; each phase must have a rollback plan.\n\n## Refactoring Completion Acceptance Criteria\n\nWhen refactoring is done, check:\n\n- [ ] Full test suite passes (including integration tests)\n- [ ] No new test failures introduced\n- [ ] Behavior unchanged (L1\u002FL2\u002FL3) or behavior changes verified (L4)\n- [ ] Code is clearer (readability improved, not more complex)\n- [ ] No new code smells introduced\n- [ ] No performance regression (L3\u002FL4 run performance baseline comparison)\n- [ ] Dead code removed (old implementations, unused imports)\n\n## Usage\n\n1. **Pre-check**: Go through the 5 \"pre-refactoring checklist\" items before refactoring; if tests are missing, add characterization tests first.\n2. **Determine level**: Use the \"granularity levels\" table to determine L1-L4, and select corresponding process requirements.\n3. **Execute process**: Follow the 5 \"standard refactoring process\" steps; take small steps, commit + test at each step.\n4. **Select action**: Use the \"refactoring action list\" to find the standard approach for the scenario; for code examples, Read `references\u002Frefactor-guide\u002Freferences\u002Frefactoring_patterns.md`.\n5. **Legacy code**: For old code without tests, Read `refactor-guide\u002Freferences\u002Flegacy_code_patterns.md`, use seam points + characterization tests + dependency breaking.\n6. **Real cases**: For end-to-end reference, Read `refactor-guide\u002Freferences\u002Frefactoring_cases.md` (4 cases: Service splitting \u002F static to injection \u002F microservice splitting \u002F add tests then refactor).\n7. **Safety strategies**: For L3\u002FL4, use Strangler Fig \u002F parallel implementation \u002F commit checkpoints; avoid big bang.\n8. **Acceptance**: Check against \"acceptance criteria\" to verify refactoring is truly complete.\n9. **Do not fabricate when uncertain**: Refactoring techniques are based on \"Refactoring\" and \"Working Effectively with Legacy Code\"; this skill does not replace formal methodologies.\n\n## Reference Entries\n\n- **Refactoring Techniques in Detail**: `references\u002Frefactoring_patterns.md` (9 techniques, with before\u002Fafter code comparison)\n- **Legacy Code Refactoring**: `references\u002Flegacy_code_patterns.md` (seam points, characterization tests, 6 dependency-breaking techniques)\n- **Real Refactoring Cases**: `references\u002Frefactoring_cases.md` (4 end-to-end cases)\n- \"Refactoring: Improving the Design of Existing Code\" (Martin Fowler)\n- \"Working Effectively with Legacy Code\" (Michael Feathers) -- covers legacy code refactoring, characterization tests\n- Project coding standards: `resources\u002Fskills\u002Fcoding-standard\u002FSKILL.md`\n- Project JVM troubleshooting: `resources\u002Fskills\u002Fjvm-troubleshoot\u002FSKILL.md`\n","# Project Refactoring Standards and Process Governance\n\nThis skill addresses the core pain points of refactoring: **refactoring without tests, no verification after changes, interruptions mid-refactoring, introducing new bugs**. The principle is \"add tests first, then verify; take small steps.\"\n\n## Pre-Refactoring Checklist (Stop If Not Satisfied)\n\nAll of the following must be met before refactoring. No exceptions:\n\n- [ ] **Sufficient test coverage**: Core logic coverage > 70%. No tests -> add \"characterization tests\" first (record current behavior, even if it has bugs), then refactor\n- [ ] **Tests are currently green**: `mvn test` passes, establishing a \"it was working before refactoring\" baseline\n- [ ] **Clear refactoring goal**: Can state in one sentence \"what problem this refactoring solves\", not \"just tidying up while I'm at it\"\n- [ ] **Rollback plan**: Work on a separate git branch, or have a backup\n- [ ] **Refactoring scope is defined**: List the files to be changed; do not change code outside the scope just because it \"looks bad\"\n\n**How to write characterization tests** (emergency when there are no tests):\n```java\n\u002F\u002F Record current behavior, do not judge right or wrong\n@Test\nvoid characterize_currentBehavior_ofCalc() {\n    assertEquals(42, calc.compute(1, 2, 3));  \u002F\u002F Even if 42 is a bug, record it first\n    assertEquals(0, calc.compute(0, 0, 0));\n    assertNull(calc.compute(null, null, null));  \u002F\u002F Record current NPE too\n}\n```\n\n## Refactoring Granularity Levels\n\n4 levels by risk and impact scope, each with different process requirements:\n\n| Level | Scope | Example | Process Requirements |\n|---|---|---|---|\n| **L1 Surface Refactoring** | Single file, no signature change | Rename variable, extract constant, format adjustment | Run unit tests after changes |\n| **L2 Structural Refactoring** | Single file, change internal structure | Extract method, inline method, move function | Run unit tests + integration tests after changes |\n| **L3 Interface Refactoring** | Multiple files, change signature | Change method signature, split class, merge classes | Change tests first, then implementation, run full test suite |\n| **L4 Architecture Refactoring** | Cross-module, change dependencies | Switch framework, split microservices, change data flow | Phased approach, each phase independently testable and rollbackable |\n\n**How to determine level**: If changes affect callers -> at least L3; if cross-module -> L4.\n\n## Standard Refactoring Process (5 Steps, Small Steps)\n\n1. **Green baseline**: `mvn test` passes. If it fails, fix bugs first. Do not refactor on broken code.\n2. **Add tests**: Add tests for the code to be changed. If coverage is insufficient, add more cases. Focus on **the parts being changed** and **affected callers**.\n3. **Small-step refactoring**: Only one atomic action per step (extract one method \u002F rename one variable \u002F move one function). Run tests immediately after each change.\n4. **Commit checkpoint**: `git commit` after each atomic refactoring. Write clear commit messages describing what was done. This enables `git bisect` for locating issues and `git revert` for rollback.\n5. **Verify**: Run full test suite + integration tests + manual verification of critical paths. L3\u002FL4 also requires performance baseline comparison.\n\n**Key principle**: Do not make 10 changes then run tests. When something breaks, you cannot pinpoint which step introduced the problem.\n\n## Refactoring Action List\n\nStandard approaches for common refactoring scenarios:\n\n| Scenario | Refactoring Action | Notes |\n|---|---|---|\n| Method too long | Extract Method | After extraction, method name should express intent; if too many parameters, encapsulate into an object |\n| Duplicate code | Extract common method \u002F Template Method | Do not over-abstract; extract only after **3 repetitions** (rule of three) |\n| Class too large | Split class \u002F Extract responsibility | First ask \"how many responsibilities does this class have\"; only split when Single Responsibility is violated |\n| Deep nesting | Extract method \u002F Early return \u002F Guard clause | Reduce nesting levels; prefer guard clauses for early return |\n| Magic numbers | Extract constant | Constant name should express business meaning, not `NUM_42` |\n| Too many parameters | Encapsulate parameter object | Do not create a \"parameter bag\" anti-pattern (one class holding all parameters) |\n| Switch branches | Replace with polymorphism \u002F Strategy pattern | Use switch for fixed branches; use Strategy pattern for extensible branches |\n| Global variables | Dependency injection | Reduce static; use constructor injection or method injection |\n| Complex conditions | Extract judgment method \u002F Strategy pattern | `if (a && b || c)` -> `if (shouldExecute(a, b, c))` |\n\n## Safe Refactoring Techniques\n\n4 patterns to avoid \"code breaks mid-refactoring\":\n\n### 1. Strangler Fig Pattern\n\nNew code gradually replaces old code; old code is kept until verification is complete, then deleted:\n\n```\n\u002F\u002F Phase 1: New implementation coexists\npublic Result process(Input in) {\n    if (featureFlag.useNew()) {\n        return newProcess(in);   \u002F\u002F New implementation\n    }\n    return oldProcess(in);       \u002F\u002F Old implementation kept\n}\n\n\u002F\u002F Phase 2: After canary verification, traffic switches to new implementation\n\u002F\u002F Phase 3: Delete old implementation\n```\n\nApplicable to: L4 architecture refactoring, replacing entire modules.\n\n### 2. Parallel Implementation + Toggle Switch\n\nNew and old implementations coexist, configuration toggle switches between them; instant rollback if problems occur:\n\n```java\nif (config.getBoolean(\"use.new.parser\")) {\n    return newParser.parse(input);\n} else {\n    return oldParser.parse(input);\n}\n```\n\nApplicable to: Switching frameworks, algorithms, or data sources.\n\n### 3. Shadow Traffic\n\nNew and old implementations run simultaneously, results are compared, without affecting production:\n\n```java\nResult official = oldProcess(input);          \u002F\u002F Production uses this\nResult shadow = newProcess(input);             \u002F\u002F Shadow run, does not affect return\nlogCompare(official, shadow);                  \u002F\u002F Compare, alert on inconsistency\nreturn official;\n```\n\nApplicable to: Core path refactoring where direct switchover is not possible.\n\n### 4. Commit Checkpoints\n\n`git commit` after each atomic refactoring, enabling rollback and bisect:\n\n```bash\ngit commit -m \"refactor: extract computeTax method from calculate\"\n# Run tests, green\ngit commit -m \"refactor: rename price -> unitPrice\"\n# Run tests, red -> git revert HEAD, go back to previous step\n```\n\nApplicable to: All levels of refactoring, **mandatory**.\n\n## Anti-Patterns (Do Not Refactor This Way)\n\n| Anti-Pattern | Problem | Correct Approach |\n|---|---|---|\n| **Big Bang refactoring** | Change for a week before running tests; cannot locate issues when something breaks | Small steps, commit + test at each step |\n| **Opportunistic refactoring** | Tidying up unrelated code while fixing a bug, expanding the change scope | Refactoring and bug fixes in separate commits, separate PRs |\n| **Refactoring without tests** | Changing code based on \"I understand this code\" | Add characterization tests first, then refactor |\n| **Refactoring + logic change** | Mixing refactoring with behavior changes, impossible to distinguish | Refactoring does not change behavior; logic changes in separate commits |\n| **Cross-branch refactoring** | Multiple branches refactoring simultaneously, merge conflict hell | Complete refactoring in one branch, then cherry-pick |\n\n## Phased Strategy for L3\u002FL4 Refactoring\n\nL3 (interface refactoring) and L4 (architecture refactoring) must be phased, with each phase independently testable and rollbackable:\n\n### L3 Interface Refactoring Example (Change Method Signature)\n\n```\nPhase 1: New signature + old signature coexist (old signature delegates to new signature)\nPhase 2: All callers migrate to new signature\nPhase 3: Delete old signature\n```\n\nOne commit per phase, run full test suite after each phase.\n\n### L4 Architecture Refactoring Example (Split Microservices)\n\n```\nPhase 1: Set up new service, no traffic (independently testable)\nPhase 2: Strangler Fig connects to new service, shadow traffic comparison\nPhase 3: Canary traffic shift to new service\nPhase 4: Decommission old service\n```\n\nPhases may be weeks apart; each phase must have a rollback plan.\n\n## Refactoring Completion Acceptance Criteria\n\nWhen refactoring is done, check:\n\n- [ ] Full test suite passes (including integration tests)\n- [ ] No new test failures introduced\n- [ ] Behavior unchanged (L1\u002FL2\u002FL3) or behavior changes verified (L4)\n- [ ] Code is clearer (readability improved, not more complex)\n- [ ] No new code smells introduced\n- [ ] No performance regression (L3\u002FL4 run performance baseline comparison)\n- [ ] Dead code removed (old implementations, unused imports)\n\n## Usage\n\n1. **Pre-check**: Go through the 5 \"pre-refactoring checklist\" items before refactoring; if tests are missing, add characterization tests first.\n2. **Determine level**: Use the \"granularity levels\" table to determine L1-L4, and select corresponding process requirements.\n3. **Execute process**: Follow the 5 \"standard refactoring process\" steps; take small steps, commit + test at each step.\n4. **Select action**: Use the \"refactoring action list\" to find the standard approach for the scenario; for code examples, Read `references\u002Frefactor-guide\u002Freferences\u002Frefactoring_patterns.md`.\n5. **Legacy code**: For old code without tests, Read `refactor-guide\u002Freferences\u002Flegacy_code_patterns.md`, use seam points + characterization tests + dependency breaking.\n6. **Real cases**: For end-to-end reference, Read `refactor-guide\u002Freferences\u002Frefactoring_cases.md` (4 cases: Service splitting \u002F static to injection \u002F microservice splitting \u002F add tests then refactor).\n7. **Safety strategies**: For L3\u002FL4, use Strangler Fig \u002F parallel implementation \u002F commit checkpoints; avoid big bang.\n8. **Acceptance**: Check against \"acceptance criteria\" to verify refactoring is truly complete.\n9. **Do not fabricate when uncertain**: Refactoring techniques are based on \"Refactoring\" and \"Working Effectively with Legacy Code\"; this skill does not replace formal methodologies.\n\n## Reference Entries\n\n- **Refactoring Techniques in Detail**: `references\u002Frefactoring_patterns.md` (9 techniques, with before\u002Fafter code comparison)\n- **Legacy Code Refactoring**: `references\u002Flegacy_code_patterns.md` (seam points, characterization tests, 6 dependency-breaking techniques)\n- **Real Refactoring Cases**: `references\u002Frefactoring_cases.md` (4 end-to-end cases)\n- \"Refactoring: Improving the Design of Existing Code\" (Martin Fowler)\n- \"Working Effectively with Legacy Code\" (Michael Feathers) -- covers legacy code refactoring, characterization tests\n- Project coding standards: `resources\u002Fskills\u002Fcoding-standard\u002FSKILL.md`\n- Project JVM troubleshooting: `resources\u002Fskills\u002Fjvm-troubleshoot\u002FSKILL.md`\n",{},"develop","dfece20d51f9b476b87c7fc08dbba71857e1fe17",".claude\u002Fskills\u002Frefactor-guide",10,"https:\u002F\u002Fgithub.com\u002FopenJiuwen-ai\u002Fagent-core-java","https:\u002F\u002Fgithub.com\u002FopenJiuwen-ai","https:\u002F\u002Fwww.openjiuwen.com","openJiuwen is an open-source community dedicated to building a production-ready AI Agent platform.","2026-11-10 17:30:15",{"source":7,"skillName":5,"commands":41,"prompt":51,"zipAvailable":52},[42,45,48],{"tool":43,"command":44},"npx","npx skills add openJiuwen-ai\u002Fagent-core-java --skill refactor-guide",{"tool":46,"command":47},"bunx","bunx skills add openJiuwen-ai\u002Fagent-core-java --skill refactor-guide",{"tool":49,"command":50},"pnpm","pnpm dlx skills add openJiuwen-ai\u002Fagent-core-java --skill refactor-guide","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FopenJiuwen-ai\u002Fagent-core-java\u002Fblob\u002Fdevelop\u002F.claude\u002Fskills\u002Frefactor-guide\u002FSKILL.md",true,[54,60,64],{"path":55,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":58,"sourceHtmlUrl":59},"references\u002Flegacy_code_patterns.md","REFERENCE","参考文档",8777,"https:\u002F\u002Fgithub.com\u002FopenJiuwen-ai\u002Fagent-core-java\u002Fblob\u002Fdevelop\u002F.claude\u002Fskills\u002Frefactor-guide\u002Freferences\u002Flegacy_code_patterns.md",{"path":61,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":62,"sourceHtmlUrl":63},"references\u002Frefactoring_cases.md",10132,"https:\u002F\u002Fgithub.com\u002FopenJiuwen-ai\u002Fagent-core-java\u002Fblob\u002Fdevelop\u002F.claude\u002Fskills\u002Frefactor-guide\u002Freferences\u002Frefactoring_cases.md",{"path":65,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":66,"sourceHtmlUrl":67},"references\u002Frefactoring_patterns.md",9440,"https:\u002F\u002Fgithub.com\u002FopenJiuwen-ai\u002Fagent-core-java\u002Fblob\u002Fdevelop\u002F.claude\u002Fskills\u002Frefactor-guide\u002Freferences\u002Frefactoring_patterns.md",[69,91,102,113,122,131],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":78,"publishedAt":26},"01M6PFBS67R67YZW9V80AHK266","web_research","Search public information and summarize sources with the search tool.","https:\u002F\u002Fgithub.com\u002FopenJiuwen-ai\u002Fagent-core-java\u002Fblob\u002Fdevelop\u002Fexamples\u002Ftoolgroup\u002Fskills\u002Fweb_research\u002FSKILL.md",[75],{"categoryNo":76,"categoryName":77,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000021","资料检索与研究",[79,80,81,82,83,84,85,86,87,88,89,90],"web research","research","web","with","information","sources","false","public","tool","examples","search","summarize",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":100,"publishedAt":26},"01M6PFBNC6CP2CVQE6QPJBZCT3","skill_a","Modified Skill A","https:\u002F\u002Fgithub.com\u002FopenJiuwen-ai\u002Fagent-core-java\u002Fblob\u002Fdevelop\u002Fexamples\u002Fskill_hot_reload\u002Fskills\u002Fskill_a\u002FSKILL.md",[97],{"categoryNo":98,"categoryName":99,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[101],"skill a",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":109,"publishedAt":26},"01M6PFBHGDK865W5KFD9XC2XPB","skill_30","Skill 30 for hot-reload demo","https:\u002F\u002Fgithub.com\u002FopenJiuwen-ai\u002Fagent-core-java\u002Fblob\u002Fdevelop\u002Fexamples\u002Fskill_hot_reload\u002Fskills\u002Fskill_30\u002FSKILL.md",[108],{"categoryNo":98,"categoryName":99,"taxonomyType":20,"taxonomyTypeDesc":21},[110,111,112],"skill 30","for","demo",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":120,"publishedAt":26},"01M6PFBDBR8BK7Z2N8XR0WV2P2","skill_29","Skill 29 for hot-reload demo","https:\u002F\u002Fgithub.com\u002FopenJiuwen-ai\u002Fagent-core-java\u002Fblob\u002Fdevelop\u002Fexamples\u002Fskill_hot_reload\u002Fskills\u002Fskill_29\u002FSKILL.md",[119],{"categoryNo":98,"categoryName":99,"taxonomyType":20,"taxonomyTypeDesc":21},[121,111,112],"skill 29",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":129,"publishedAt":26},"01M6PFB9H4ND4RVTPBVC32CPZZ","skill_28","Skill 28 for hot-reload demo","https:\u002F\u002Fgithub.com\u002FopenJiuwen-ai\u002Fagent-core-java\u002Fblob\u002Fdevelop\u002Fexamples\u002Fskill_hot_reload\u002Fskills\u002Fskill_28\u002FSKILL.md",[128],{"categoryNo":98,"categoryName":99,"taxonomyType":20,"taxonomyTypeDesc":21},[130,111,112],"skill 28",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":138,"publishedAt":26},"01M6PFB5FR4ACYQ2NCGJ51NSJT","skill_27","Skill 27 for hot-reload demo","https:\u002F\u002Fgithub.com\u002FopenJiuwen-ai\u002Fagent-core-java\u002Fblob\u002Fdevelop\u002Fexamples\u002Fskill_hot_reload\u002Fskills\u002Fskill_27\u002FSKILL.md",[137],{"categoryNo":98,"categoryName":99,"taxonomyType":20,"taxonomyTypeDesc":21},[139,112,111],"skill 27"]