[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X6BRFS4AXBYRRGY2HRDTE9":3,"skill-same:01M6X6BRFS4AXBYRRGY2HRDTE9":84},{"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":28,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":60,"ownerHtmlUrl":61,"ownerBlogUrl":60,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M6X6BRFS4AXBYRRGY2HRDTE9","code-refactoring",null,"When the user says 'refactor this', 'rename class', or 'move method'. Safely refactors code in any language — finds all callers, updates downstream dependencies, verifies via quality tools.","event4u-app\u002Fagent-config","event4u-app","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F199339632?v=4","01M6X5TWBNCQCE1VDKT4E9KF7N","event4u.app","01M6X5TWF4HRM266RG2Q5VVH1X",19,"MIT","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-refactoring\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"refactoring","code refactoring","code","base","quality tools","when","high","updates","move","via","dependencies","rename","language","user","quality","Tools","refactor","engineering","2026-11-10 10:12:30",false,"---\nmodel_tier: high\nname: code-refactoring\ndescription: \"When the user says 'refactor this', 'rename class', or 'move method'. Safely refactors code in any language — finds all callers, updates downstream dependencies, verifies via quality tools.\"\ndomain: engineering\nworkspaces:\n  - engineering\npacks:\n  - engineering-base\n---\n\n# refactorer\n\n## When to use\n\nUse this skill when renaming, moving, extracting, or restructuring code — any change that\nmay have downstream effects on callers, interfaces, tests, documentation, or API contracts.\n\n\nDo NOT use when:\n- New feature development (use `feature-planning` skill)\n- Bug fixes that don't involve restructuring (use `bug-analyzer` skill)\n\n## Before refactoring\n\n1. **Read the agent docs** — check `agents\u002Freference\u002Fdocs\u002F` and `agents\u002Fsettings\u002Fcontexts\u002F` for the area you're refactoring.\n   For modules, also read the project's module-docs directory (path varies by stack — Laravel: `app\u002FModules\u002F{Module}\u002Fagents\u002F`; Nx: `apps\u002F{app}\u002Fdocs\u002F`; mono-repo: per-package `docs\u002F`). See the `project-docs` skill for the mapping.\n2. **Understand the scope** — what exactly needs to change and why?\n3. **Find ALL references** — use `code-graph ask` and `view` with `search_query_regex` to find every\n   caller, implementation, test, and configuration that references the code being changed.\n   **If the change is to a closed set** — an enum, union, literal type, state\n   machine, role or permission set — identifier search is not enough: the\n   consumers that break are the ones that never name the type. Search by shape as\n   well (`switch` \u002F `match` \u002F if-chains over it, lookup tables keyed by it,\n   validators, serializers, schemas, fixtures, translation keys) and classify each\n   as exhaustive, deliberate fallback, or missing case. Procedure:\n   [`downstream-changes-mechanics`](..\u002F..\u002F..\u002Fdocs\u002Fguidelines\u002Fagent-infra\u002Fdownstream-changes-mechanics.md).\n4. **Map the impact** — create a list of all files that will need changes.\n5. **Decide the verdict, if the refactor is a de-duplication** — see the\n   safe-abstraction gate below. An extraction with no recorded verdict is a\n   guess about whether two things are the same thing.\n6. **Present the plan** — show the user what will be affected before starting.\n\n### Safe-abstraction gate — before merging two things into one\n\nThis skill performs extractions; it is therefore the place that decides\nwhether one should happen. A wrong abstraction costs more than the\nduplication it replaced, because the duplication is visible and the wrong\nabstraction grows caller flags until nobody can remove it. Ask, before\nmoving any code:\n\n1. Is this the same knowledge, or two facts that currently look alike?\n2. Would both copies change for the same reason?\n3. Is there one honest domain name that fits **every** call site?\n4. Can the common core stay free of caller-specific flags and modes?\n5. Are public contracts preserved, and do tests prove behavioural equivalence?\n6. **If the two copies diverged tomorrow, would that be a defect or\n   legitimate evolution?**\n\nA \"legitimate evolution\" answer to the last question is decisive: stop, and\nrecord the verdict `keep-duplicated`. That closes the refactor **successfully**\n— so does `de-abstract`, splitting a shared unit that has grown modes back\napart. Neither is a failure to act, and neither needs an apology in the\noutput. Textual similarity is not evidence of shared knowledge: copies that\nread identically can encode different assumptions, and merging them changes\nbehaviour silently.\n\nThe class names and the full verdict list are in\n[`redundancy-taxonomy`](..\u002F..\u002F..\u002Fdocs\u002Fguidelines\u002Fredundancy-taxonomy.md).\n\nWhen the refactor goes the other way and **creates** a new unit, the reuse\nquestion comes first: does an existing class or component already cover this, and\nwhat does composing or extending it cost against a new one? Thresholds per\nartifact class:\n[`component-oriented-and-oop-development`](..\u002F..\u002F..\u002Fdocs\u002Fguidelines\u002Fcomponent-oriented-and-oop-development.md).\n\n## Procedure: Refactor code\n\n### Step 1: Make the core change\n\n- Rename, extract, move, or restructure the target code.\n- Keep the change minimal and focused.\n\n### Step 2: Update all downstream dependencies\n\nFor each affected file (from the impact analysis):\n\n- **Callers**: Update method calls, constructor arguments, imports.\n- **Interfaces \u002F abstract methods**: Update all implementations to match new signatures.\n- **Subclasses**: Update overridden methods.\n- **Type hints \u002F annotations**: Update type references (PHPDoc, TypeScript types, Python type hints, Go generics, Rust generics).\n- **Config \u002F bindings**: Update service container bindings, route references, etc.\n- **Imports**: Add or update import statements (`use` for PHP, `import` for JS\u002FTS\u002FPython, `import` blocks for Go, `use` for Rust).\n\n### Step 3: Update API layer (if request handlers \u002F endpoints are affected)\n\nWhen refactoring touches handlers, route registrations, request validators, or response shapers, walk the stack-appropriate boundary. Use the carve-out skill for the project's framework if one exists; otherwise consult the table below for what to check on each stack.\n\n| Layer | What to check and update |\n|---|---|\n| **Route registration** | Route file \u002F decorator \u002F file-based-router entry — name, URL, HTTP method, parameter binding |\n| **Handler \u002F Controller** | Entry signature, injected dependencies, return type |\n| **Request validator** | Validation rule definitions, allowlisted fields (FormRequest, Zod schema, class-validator DTO, Pydantic model, struct tags) |\n| **Response shaper** | Field mapping in the transformer (API Resource, serializer, DTO mapper, response model) |\n| **API contract** | OpenAPI annotations, generated spec, typed client (regenerate if generated) |\n| **Authorization rule** | Policy \u002F voter \u002F guard \u002F middleware \u002F route dependency that protects the route |\n| **Module routes** | Module-local routing surface (Laravel `app\u002FModules\u002F*\u002FRoutes\u002F`, Nx `apps\u002F*\u002Fsrc\u002Froutes`, mono-repo per-package routes) |\n\nCarve-out routing:\n- Laravel: [`laravel-api-endpoint`](..\u002Flaravel-api-endpoint\u002FSKILL.md)\n- Next.js: [`nextjs-patterns`](..\u002Fnextjs-patterns\u002FSKILL.md)\n- Symfony: [`symfony-workflow`](..\u002Fsymfony-workflow\u002FSKILL.md)\n\n### Step 4: Update tests — with user approval\n\n**Before changing any test**, present a summary to the user:\n\n1. **List all affected tests** — which test files and which test cases need changes.\n2. **Describe what changes** — for each test, explain what assertion\u002Fsetup changes and why.\n3. **Classify the change**:\n   - ✅ **Non-breaking**: Test adapts to internal refactoring (renamed class, moved method) —\n     same behavior, different code path. No API contract change.\n   - ⚠️ **Potentially breaking**: Test expectations change (new field in response, changed\n     validation rule, different error code) — this MAY affect API consumers.\n   - ? **Breaking**: Test removes or changes existing API behavior (removed field, changed\n     endpoint URL, different response structure) — this WILL affect API consumers.\n4. **Ask for confirmation** (numbered options):\n   ```\n   > 1. Yes — apply test changes\n   > 2. No — I'll adjust the tests myself\n   ```\n5. Only proceed after the user confirms.\n\n**Rules for test changes:**\n- Do NOT change test expectations to make failing tests pass unless the refactoring intentionally\n  changes behavior. A failing test after refactoring usually means the refactoring has a bug.\n- Do NOT delete tests — adapt them to the new code structure.\n- Do NOT reduce test coverage — if you split a class, split the test too.\n\n### Step 5: Verify with the project's quality tools\n\nRun the project's type-checker and linter after each significant step — do NOT batch everything to the end. The exact command set depends on the stack; resolve via `quality-tools` skill or the project's `Taskfile.yml` \u002F `package.json scripts` \u002F `composer.json scripts` \u002F `Makefile`.\n\n| Stack | Typical pipeline |\n|---|---|\n| Laravel \u002F PHP | `vendor\u002Fbin\u002Fphpstan analyse` → `vendor\u002Fbin\u002Frector process` → `vendor\u002Fbin\u002Fecs check --fix` → re-run the static analyser |\n| TypeScript | `tsc --noEmit` → `eslint --fix` → `prettier --write` |\n| Python | `mypy` (or `pyright`) → `ruff check --fix` → `ruff format` |\n| Go | `go vet .\u002F...` → `golangci-lint run --fix` → `gofmt -w` |\n| Rust | `cargo check` → `cargo clippy --fix` → `cargo fmt` |\n\nIf auto-fixers can rewrite types (Rector for PHP, `eslint --fix` for TS), re-run the type-checker after them — auto-fixers can introduce new errors.\n\n### Step 6: Run tests\n\n- Run tests related to the changed code first (`php artisan test --filter=...`, `pnpm test -- \u003Cpattern>`, `pytest -k \u003Cpattern>`, `go test .\u002F{path}\u002F...`, `cargo test {pattern}`).\n- Then run the full test suite (`php artisan test`, `pnpm test`, `pytest`, `go test .\u002F...`, `cargo test`).\n- All tests must pass before the refactoring is considered complete.\n\n### Step 7: Update documentation\n\nAfter the code changes are verified, update all affected documentation:\n\n| Documentation layer | When to update | Location |\n|---|---|---|\n| **Project docs** | When conventions, patterns, or key files change | `agents\u002Freference\u002Fdocs\u002F*.md` |\n| **Project contexts** | When architecture or high-level flow changes | `agents\u002Fsettings\u002Fcontexts\u002F*.md` |\n| **Module agent docs** | When module-specific behavior changes | `{module_root}\u002F*\u002F{agent_folder}\u002F` (per `modules.root_paths` + `modules.agent_folder`) |\n| **Module Docs\u002F** | When module internals change | `{module_root}\u002F*\u002FDocs\u002F` |\n| **AGENTS.md** | When project-wide conventions change | `AGENTS.md` |\n| **Roadmaps** | When a roadmap step is completed | `agents\u002Froadmaps\u002F*.md` |\n\n**Rules for doc updates:**\n- If you rename a class\u002Fmethod referenced in docs → update the reference.\n- If you move files → update all path references.\n- If you change a pattern → update the pattern description.\n- If you add a new convention → document it.\n- Do NOT create new docs unless the refactoring introduces a genuinely new concept.\n\n## Common refactoring patterns\n\n### Rename (method, class, property)\n1. Find all usages → update all usages → update docs → run the static analyser → run tests.\n\n### Extract method \u002F class\n0. Run the safe-abstraction gate above — a `keep-duplicated` verdict ends it here.\n1. Create the new method\u002Fclass → move logic → update caller → update docs → run the static analyser → run tests.\n\n### Move class to different namespace\n1. Move file → update namespace → find all `use` statements → update imports → update docs → run the static analyser.\n\n### Change method signature\n1. Update the method → find all callers → update each caller → present test changes → update docs → run the static analyser.\n\n### Change API endpoint\n1. Update controller + request + resource + OpenAPI schemas + route → present test changes →\n   update docs (`agents\u002Freference\u002Fdocs\u002Fcontroller.md`, `agents\u002Freference\u002Fdocs\u002Fapi-resources.md`) → run the static analyser → run tests.\n\n### Replace implementation (e.g. switch service)\n1. Create new implementation → update binding → find all direct references → update → present test\n   changes → update docs → run the static analyser → run tests → remove old implementation.\n\n### Move\u002Frestructure module\n1. Move files → update namespaces → update `ModuleServiceProvider` if needed → update module routes →\n   update module agent docs → update project contexts → run the static analyser → run tests.\n\n## Safety rules\n\n- **Never skip the caller search** — missing a caller is the #1 cause of broken refactorings.\n- **Never remove old code before verifying** the new code works everywhere.\n- **Never change test expectations without user approval** — explain what changes and why first.\n- **Run the static analyser after every step** (PHPStan, `tsc --noEmit`, mypy — whichever the project runs), not just at the end.\n- **Run tests after every step**, not just at the end.\n- **Update docs after code changes** — stale docs are worse than no docs.\n- **Do NOT commit or push** — only apply local changes.\n- **Do NOT refactor code outside the requested scope** — no drive-by cleanups.\n- If the refactoring reveals more work than expected, **stop and discuss with the user**.\n\n## Cross-References\n\n| Skill | Relationship |\n|---|---|\n| `project-docs` | Which docs to read before refactoring a specific area |\n| `agent-docs-writing` | When to create\u002Fupdate agent documentation |\n| `api-endpoint` | Full API endpoint structure (controller + request + resource + schema) |\n| `php-coder` | PHP coding conventions to follow in refactored code |\n| `pest-testing` | Test conventions when adapting tests |\n| `openapi` | OpenAPI schema attribute patterns |\n\n\n## Output format\n\n1. Refactored code with clear separation of changes\n2. Before\u002Fafter comparison for key changes\n3. Test verification confirming no behavior change\n\n## Gotcha\n\n- Always find ALL callers before renaming — the model frequently misses usages in tests and config files.\n- Don't refactor and add features in the same commit — separate concerns for reviewability.\n- The model tends to \"improve\" code it's refactoring — stay scope-focused, refactor means same behavior.\n- Run the full test suite after every refactoring step — don't batch multiple refactors.\n\n## Do NOT\n\n- Do NOT refactor without running tests before and after.\n- Do NOT change test expectations without explicit user approval.\n- Do NOT refactor across module boundaries without checking downstream.\n\n## Auto-trigger keywords\n\n- refactoring\n- rename\n- move class\n- change signature\n","# refactorer\n\n## When to use\n\nUse this skill when renaming, moving, extracting, or restructuring code — any change that\nmay have downstream effects on callers, interfaces, tests, documentation, or API contracts.\n\n\nDo NOT use when:\n- New feature development (use `feature-planning` skill)\n- Bug fixes that don't involve restructuring (use `bug-analyzer` skill)\n\n## Before refactoring\n\n1. **Read the agent docs** — check `agents\u002Freference\u002Fdocs\u002F` and `agents\u002Fsettings\u002Fcontexts\u002F` for the area you're refactoring.\n   For modules, also read the project's module-docs directory (path varies by stack — Laravel: `app\u002FModules\u002F{Module}\u002Fagents\u002F`; Nx: `apps\u002F{app}\u002Fdocs\u002F`; mono-repo: per-package `docs\u002F`). See the `project-docs` skill for the mapping.\n2. **Understand the scope** — what exactly needs to change and why?\n3. **Find ALL references** — use `code-graph ask` and `view` with `search_query_regex` to find every\n   caller, implementation, test, and configuration that references the code being changed.\n   **If the change is to a closed set** — an enum, union, literal type, state\n   machine, role or permission set — identifier search is not enough: the\n   consumers that break are the ones that never name the type. Search by shape as\n   well (`switch` \u002F `match` \u002F if-chains over it, lookup tables keyed by it,\n   validators, serializers, schemas, fixtures, translation keys) and classify each\n   as exhaustive, deliberate fallback, or missing case. Procedure:\n   [`downstream-changes-mechanics`](..\u002F..\u002F..\u002Fdocs\u002Fguidelines\u002Fagent-infra\u002Fdownstream-changes-mechanics.md).\n4. **Map the impact** — create a list of all files that will need changes.\n5. **Decide the verdict, if the refactor is a de-duplication** — see the\n   safe-abstraction gate below. An extraction with no recorded verdict is a\n   guess about whether two things are the same thing.\n6. **Present the plan** — show the user what will be affected before starting.\n\n### Safe-abstraction gate — before merging two things into one\n\nThis skill performs extractions; it is therefore the place that decides\nwhether one should happen. A wrong abstraction costs more than the\nduplication it replaced, because the duplication is visible and the wrong\nabstraction grows caller flags until nobody can remove it. Ask, before\nmoving any code:\n\n1. Is this the same knowledge, or two facts that currently look alike?\n2. Would both copies change for the same reason?\n3. Is there one honest domain name that fits **every** call site?\n4. Can the common core stay free of caller-specific flags and modes?\n5. Are public contracts preserved, and do tests prove behavioural equivalence?\n6. **If the two copies diverged tomorrow, would that be a defect or\n   legitimate evolution?**\n\nA \"legitimate evolution\" answer to the last question is decisive: stop, and\nrecord the verdict `keep-duplicated`. That closes the refactor **successfully**\n— so does `de-abstract`, splitting a shared unit that has grown modes back\napart. Neither is a failure to act, and neither needs an apology in the\noutput. Textual similarity is not evidence of shared knowledge: copies that\nread identically can encode different assumptions, and merging them changes\nbehaviour silently.\n\nThe class names and the full verdict list are in\n[`redundancy-taxonomy`](..\u002F..\u002F..\u002Fdocs\u002Fguidelines\u002Fredundancy-taxonomy.md).\n\nWhen the refactor goes the other way and **creates** a new unit, the reuse\nquestion comes first: does an existing class or component already cover this, and\nwhat does composing or extending it cost against a new one? Thresholds per\nartifact class:\n[`component-oriented-and-oop-development`](..\u002F..\u002F..\u002Fdocs\u002Fguidelines\u002Fcomponent-oriented-and-oop-development.md).\n\n## Procedure: Refactor code\n\n### Step 1: Make the core change\n\n- Rename, extract, move, or restructure the target code.\n- Keep the change minimal and focused.\n\n### Step 2: Update all downstream dependencies\n\nFor each affected file (from the impact analysis):\n\n- **Callers**: Update method calls, constructor arguments, imports.\n- **Interfaces \u002F abstract methods**: Update all implementations to match new signatures.\n- **Subclasses**: Update overridden methods.\n- **Type hints \u002F annotations**: Update type references (PHPDoc, TypeScript types, Python type hints, Go generics, Rust generics).\n- **Config \u002F bindings**: Update service container bindings, route references, etc.\n- **Imports**: Add or update import statements (`use` for PHP, `import` for JS\u002FTS\u002FPython, `import` blocks for Go, `use` for Rust).\n\n### Step 3: Update API layer (if request handlers \u002F endpoints are affected)\n\nWhen refactoring touches handlers, route registrations, request validators, or response shapers, walk the stack-appropriate boundary. Use the carve-out skill for the project's framework if one exists; otherwise consult the table below for what to check on each stack.\n\n| Layer | What to check and update |\n|---|---|\n| **Route registration** | Route file \u002F decorator \u002F file-based-router entry — name, URL, HTTP method, parameter binding |\n| **Handler \u002F Controller** | Entry signature, injected dependencies, return type |\n| **Request validator** | Validation rule definitions, allowlisted fields (FormRequest, Zod schema, class-validator DTO, Pydantic model, struct tags) |\n| **Response shaper** | Field mapping in the transformer (API Resource, serializer, DTO mapper, response model) |\n| **API contract** | OpenAPI annotations, generated spec, typed client (regenerate if generated) |\n| **Authorization rule** | Policy \u002F voter \u002F guard \u002F middleware \u002F route dependency that protects the route |\n| **Module routes** | Module-local routing surface (Laravel `app\u002FModules\u002F*\u002FRoutes\u002F`, Nx `apps\u002F*\u002Fsrc\u002Froutes`, mono-repo per-package routes) |\n\nCarve-out routing:\n- Laravel: [`laravel-api-endpoint`](..\u002Flaravel-api-endpoint\u002FSKILL.md)\n- Next.js: [`nextjs-patterns`](..\u002Fnextjs-patterns\u002FSKILL.md)\n- Symfony: [`symfony-workflow`](..\u002Fsymfony-workflow\u002FSKILL.md)\n\n### Step 4: Update tests — with user approval\n\n**Before changing any test**, present a summary to the user:\n\n1. **List all affected tests** — which test files and which test cases need changes.\n2. **Describe what changes** — for each test, explain what assertion\u002Fsetup changes and why.\n3. **Classify the change**:\n   - ✅ **Non-breaking**: Test adapts to internal refactoring (renamed class, moved method) —\n     same behavior, different code path. No API contract change.\n   - ⚠️ **Potentially breaking**: Test expectations change (new field in response, changed\n     validation rule, different error code) — this MAY affect API consumers.\n   - ? **Breaking**: Test removes or changes existing API behavior (removed field, changed\n     endpoint URL, different response structure) — this WILL affect API consumers.\n4. **Ask for confirmation** (numbered options):\n   ```\n   > 1. Yes — apply test changes\n   > 2. No — I'll adjust the tests myself\n   ```\n5. Only proceed after the user confirms.\n\n**Rules for test changes:**\n- Do NOT change test expectations to make failing tests pass unless the refactoring intentionally\n  changes behavior. A failing test after refactoring usually means the refactoring has a bug.\n- Do NOT delete tests — adapt them to the new code structure.\n- Do NOT reduce test coverage — if you split a class, split the test too.\n\n### Step 5: Verify with the project's quality tools\n\nRun the project's type-checker and linter after each significant step — do NOT batch everything to the end. The exact command set depends on the stack; resolve via `quality-tools` skill or the project's `Taskfile.yml` \u002F `package.json scripts` \u002F `composer.json scripts` \u002F `Makefile`.\n\n| Stack | Typical pipeline |\n|---|---|\n| Laravel \u002F PHP | `vendor\u002Fbin\u002Fphpstan analyse` → `vendor\u002Fbin\u002Frector process` → `vendor\u002Fbin\u002Fecs check --fix` → re-run the static analyser |\n| TypeScript | `tsc --noEmit` → `eslint --fix` → `prettier --write` |\n| Python | `mypy` (or `pyright`) → `ruff check --fix` → `ruff format` |\n| Go | `go vet .\u002F...` → `golangci-lint run --fix` → `gofmt -w` |\n| Rust | `cargo check` → `cargo clippy --fix` → `cargo fmt` |\n\nIf auto-fixers can rewrite types (Rector for PHP, `eslint --fix` for TS), re-run the type-checker after them — auto-fixers can introduce new errors.\n\n### Step 6: Run tests\n\n- Run tests related to the changed code first (`php artisan test --filter=...`, `pnpm test -- \u003Cpattern>`, `pytest -k \u003Cpattern>`, `go test .\u002F{path}\u002F...`, `cargo test {pattern}`).\n- Then run the full test suite (`php artisan test`, `pnpm test`, `pytest`, `go test .\u002F...`, `cargo test`).\n- All tests must pass before the refactoring is considered complete.\n\n### Step 7: Update documentation\n\nAfter the code changes are verified, update all affected documentation:\n\n| Documentation layer | When to update | Location |\n|---|---|---|\n| **Project docs** | When conventions, patterns, or key files change | `agents\u002Freference\u002Fdocs\u002F*.md` |\n| **Project contexts** | When architecture or high-level flow changes | `agents\u002Fsettings\u002Fcontexts\u002F*.md` |\n| **Module agent docs** | When module-specific behavior changes | `{module_root}\u002F*\u002F{agent_folder}\u002F` (per `modules.root_paths` + `modules.agent_folder`) |\n| **Module Docs\u002F** | When module internals change | `{module_root}\u002F*\u002FDocs\u002F` |\n| **AGENTS.md** | When project-wide conventions change | `AGENTS.md` |\n| **Roadmaps** | When a roadmap step is completed | `agents\u002Froadmaps\u002F*.md` |\n\n**Rules for doc updates:**\n- If you rename a class\u002Fmethod referenced in docs → update the reference.\n- If you move files → update all path references.\n- If you change a pattern → update the pattern description.\n- If you add a new convention → document it.\n- Do NOT create new docs unless the refactoring introduces a genuinely new concept.\n\n## Common refactoring patterns\n\n### Rename (method, class, property)\n1. Find all usages → update all usages → update docs → run the static analyser → run tests.\n\n### Extract method \u002F class\n0. Run the safe-abstraction gate above — a `keep-duplicated` verdict ends it here.\n1. Create the new method\u002Fclass → move logic → update caller → update docs → run the static analyser → run tests.\n\n### Move class to different namespace\n1. Move file → update namespace → find all `use` statements → update imports → update docs → run the static analyser.\n\n### Change method signature\n1. Update the method → find all callers → update each caller → present test changes → update docs → run the static analyser.\n\n### Change API endpoint\n1. Update controller + request + resource + OpenAPI schemas + route → present test changes →\n   update docs (`agents\u002Freference\u002Fdocs\u002Fcontroller.md`, `agents\u002Freference\u002Fdocs\u002Fapi-resources.md`) → run the static analyser → run tests.\n\n### Replace implementation (e.g. switch service)\n1. Create new implementation → update binding → find all direct references → update → present test\n   changes → update docs → run the static analyser → run tests → remove old implementation.\n\n### Move\u002Frestructure module\n1. Move files → update namespaces → update `ModuleServiceProvider` if needed → update module routes →\n   update module agent docs → update project contexts → run the static analyser → run tests.\n\n## Safety rules\n\n- **Never skip the caller search** — missing a caller is the #1 cause of broken refactorings.\n- **Never remove old code before verifying** the new code works everywhere.\n- **Never change test expectations without user approval** — explain what changes and why first.\n- **Run the static analyser after every step** (PHPStan, `tsc --noEmit`, mypy — whichever the project runs), not just at the end.\n- **Run tests after every step**, not just at the end.\n- **Update docs after code changes** — stale docs are worse than no docs.\n- **Do NOT commit or push** — only apply local changes.\n- **Do NOT refactor code outside the requested scope** — no drive-by cleanups.\n- If the refactoring reveals more work than expected, **stop and discuss with the user**.\n\n## Cross-References\n\n| Skill | Relationship |\n|---|---|\n| `project-docs` | Which docs to read before refactoring a specific area |\n| `agent-docs-writing` | When to create\u002Fupdate agent documentation |\n| `api-endpoint` | Full API endpoint structure (controller + request + resource + schema) |\n| `php-coder` | PHP coding conventions to follow in refactored code |\n| `pest-testing` | Test conventions when adapting tests |\n| `openapi` | OpenAPI schema attribute patterns |\n\n\n## Output format\n\n1. Refactored code with clear separation of changes\n2. Before\u002Fafter comparison for key changes\n3. Test verification confirming no behavior change\n\n## Gotcha\n\n- Always find ALL callers before renaming — the model frequently misses usages in tests and config files.\n- Don't refactor and add features in the same commit — separate concerns for reviewability.\n- The model tends to \"improve\" code it's refactoring — stay scope-focused, refactor means same behavior.\n- Run the full test suite after every refactoring step — don't batch multiple refactors.\n\n## Do NOT\n\n- Do NOT refactor without running tests before and after.\n- Do NOT change test expectations without explicit user approval.\n- Do NOT refactor across module boundaries without checking downstream.\n\n## Auto-trigger keywords\n\n- refactoring\n- rename\n- move class\n- change signature\n",{"name":5,"packs":52,"domain":46,"model_tier":35,"workspaces":54,"description":7},[53],"engineering-base",[46],"main","12bd765ce1d800501d45dfb8232102793af01290","src\u002Fskills\u002Fcode-refactoring",1,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config","https:\u002F\u002Fevent4u.app","https:\u002F\u002Fgithub.com\u002Fevent4u-app","Your events in your hand","2026-11-14 02:29:41",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add event4u-app\u002Fagent-config --skill code-refactoring",{"tool":70,"command":71},"bunx","bunx skills add event4u-app\u002Fagent-config --skill code-refactoring",{"tool":73,"command":74},"pnpm","pnpm dlx skills add event4u-app\u002Fagent-config --skill code-refactoring","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-refactoring\u002FSKILL.md",true,[78],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"evals\u002Ftriggers.json","REFERENCE","参考文档",875,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fcode-refactoring\u002Fevals\u002Ftriggers.json",[85,101,114,125,137,146],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":94,"publishedAt":47},"01M6X84PK96XBPENXH66JCTSD1","unknown-key-fixture","Declares a key the schema does not know.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Fbody-portable\u002Funknown-key\u002FSKILL.md",[91],{"categoryNo":92,"categoryName":93,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[95,96,97,98,99,100],"unknown key fixture","Unknown key","fixture","unknown","schema","package",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":108,"publishedAt":47},"01M6X84HW7NAHZ7GZMQ9RXK1XJ","portable-fixture","Declares only semantics the MCP-lite carrier transports whole.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Fbody-portable\u002Fportable\u002FSKILL.md",[107],{"categoryNo":92,"categoryName":93,"taxonomyType":21,"taxonomyTypeDesc":22},[97,109,110,111,112,100,113],"portable","portable fixture","engineer","only","MCP",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":121,"publishedAt":47},"01M6X84F29FE0RGGZ1ZTFGZTX2","non-portable-fixture","Declares a runtime semantic the carrier drops.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Fbody-portable\u002Fnon-portable\u002FSKILL.md",[120],{"categoryNo":92,"categoryName":93,"taxonomyType":21,"taxonomyTypeDesc":22},[110,122,109,97,123,35,124,100],"non portable fixture","semantic","runtime",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":132,"publishedAt":47},"01M6X848F706PT9MDCX75JKJ6B","candidate-zero-width","A candidate whose prose carries an invisible joiner.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskill-scout-candidates\u002Fzero-width-injection\u002FSKILL.md",[131],{"categoryNo":92,"categoryName":93,"taxonomyType":21,"taxonomyTypeDesc":22},[133,134,135,136],"candidate zero width","candidate","ZeRO","prose",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":144,"publishedAt":47},"01M6X841SSC2T31VDF41SA6DG1","candidate-disclosure-suppression","A candidate whose prose tells the agent to withhold from the user.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskill-scout-candidates\u002Fdisclosure-suppression\u002FSKILL.md",[143],{"categoryNo":92,"categoryName":93,"taxonomyType":21,"taxonomyTypeDesc":22},[145,134,136,42],"candidate disclosure suppression",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":153,"publishedAt":47},"01M6X83TFS5AGPBPVTQNWP0BB3","candidate-dangerous-frontmatter","A candidate claiming an unscoped tool grant and a permission bypass.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskill-scout-candidates\u002Fdangerous-frontmatter\u002FSKILL.md",[152],{"categoryNo":92,"categoryName":93,"taxonomyType":21,"taxonomyTypeDesc":22},[154,134,155,156,157,158],"candidate dangerous frontmatter","frontmatter","shell","permission","tool"]