[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7ABMMV2EVBY4K6NBC9M9WCS":3,"skill-same:01M7ABMMV2EVBY4K6NBC9M9WCS":46},{"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":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":14,"repositoryHtmlUrl":27,"repositoryHomepageUrl":28,"ownerHtmlUrl":29,"ownerBlogUrl":30,"ownerDescription":6,"updatedAt":31,"install":32,"resources":45},"01M7ABMMV2EVBY4K6NBC9M9WCS","refactor",null,"Refactor without changing behavior. Use when asked to restructure, extract, move, or split code, or when a review hands over a structural fix. Not for readability (clean-code) or adding behavior (write-plan, tdd).","j0hanz\u002Fj0hanz-marketplace","j0hanz","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F159924955?v=4","01M7ABFK415CKHXYV9GZRJ16T7","Linus Johansson","01M7ABFK52FCPP2PNBH1YR7ZPA",0,"MIT","https:\u002F\u002Fgithub.com\u002Fj0hanz\u002Fj0hanz-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fworkbench\u002Fskills\u002Frefactor\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: refactor\ndescription: Refactor without changing behavior. Use when asked to restructure, extract, move, or split code, or when a review hands over a structural fix. Not for readability (clean-code) or adding behavior (write-plan, tdd).\n---\n\n# Refactor\n\nMove **structure** with **behavior locked**. The net is a test green before the move and green after — never a judgment that \"this looks the same.\"\n\nBehavior is settled here, and that is what lets you touch structure without a spec or a plan. You enter at a behavior-preserving structure change, asked for directly or handed over by [qc](..\u002Fqc\u002FSKILL.md), [architecture-audit](..\u002Farchitecture-audit\u002FSKILL.md), [clean-code](..\u002Fclean-code\u002FSKILL.md), or [tdd](..\u002Ftdd\u002FSKILL.md)'s post-green pass. You bypass [write-specs](..\u002Fwrite-specs\u002FSKILL.md) and [write-plan](..\u002Fwrite-plan\u002FSKILL.md) — there is no new behavior to specify or route.\n\nA refactor that changes observable behavior is a bug wearing a refactor's clothes. The test net is what catches it.\n\n## Steps\n\n### 1. Pin the behavior\n\nBefore any structure changes, establish a **green net** that captures the behavior under the move.\n\n- A passing test already covers the behavior → use it.\n- No test covers it → write a **characterization test** that captures the behavior as it is today, not as it should be, and run it green. This is not red-green: the test encodes current behavior, bugs and all, because the move must not change it.\n- No runnable check exists at all — no test runner, no script, no REPL command that exercises the target → wire the runner the language ships with or the repo already depends on, then write the characterization test above. Adding a new dependency is the user's call: ask first, and if they decline, state the absence and stop. You do not move structure blind.\n- The target has no observable behavior — nothing calls it, or every call is itself dead → flag it dead and hand to [write-plan](..\u002Fwrite-plan\u002FSKILL.md) for deletion. There is nothing to characterize.\n\nEach pinning test, reused or new, asserts a value rather than a shape, per [Writing the test](..\u002Ftdd\u002FSKILL.md#writing-the-test). For a characterization test, the known-good literal is today's output, captured by running the code once. Before the first move, prove each pinning test can fail: change its expected literal, run it **red**, restore the literal, run it green. A test that stays green with its literal changed is no net; rewrite its assertion until it goes red.\n\n**Done when** a green test pins every behavior the move touches and each one has gone **red** with its expected literal changed, or the target is flagged dead, or the user declined a runner.\n\n### 2. Move the structure\n\nExecute the move: a **rename**, an **extraction**, or a **reorder** — the vocabulary [clean-code](..\u002Fclean-code\u002FSKILL.md) uses, at the scale [qc](..\u002Fqc\u002FSKILL.md) would recommend. One move at a time; run the net after each. Green stays green between moves.\n\nA move that cannot finish with the net green stops here — it is not behavior-preserving, and you are at step 3's decline.\n\n**Done when** the structural move is complete and the net is green after every move in it.\n\n### 3. Gate behavior\n\nRun the full net — the characterization tests plus every pre-existing test in scope. The behavior captured in step 1 must reproduce exactly.\n\n- Green → the move held behavior. Proceed.\n- Red → the move changed behavior. **Revert that move.** Do not adjust the test to make it pass: a test edited to match new behavior is the net disabled, and the red is the net doing its job.\n\nA move that needs new or changed behavior to make sense — a new branch, a different return on some input, behavior that was not there before — is **declined**, not forced. That is not a refactor; it is new behavior, and it enters the chain at [write-plan](..\u002Fwrite-plan\u002FSKILL.md), worked as [tdd](..\u002Ftdd\u002FSKILL.md). Hand it over with the structural goal named; the plan can carry both.\n\n**Done when** the net is green end to end and no move in this pass introduced behavior, or the behavior-changing move has been declined and handed to write-plan.\n\n### 4. Hand to qc\n\nStructure moved, behavior held, net green: hand the change to [qc](..\u002Fqc\u002FSKILL.md) to review the **new structure** — the move may be behavior-preserving and still be ugly, mislayered, or indirected past readability. qc is the axis for that; refactor is not.\n\n**Done when** the change is handed to qc with the move named and the net result recorded.\n\n## Referencing\n\nWhere an effort directory exists for the change, the refactor records its net and result there as `\u003Cname>.refactor.md`, under the [referencing convention](..\u002Fwrite-specs\u002FSKILL.md#referencing). Where none exists, the result goes to chat and the net is the repo's tests; refactor bypasses write-specs and write-plan, so it never creates one.\n\n```markdown\npinned behavior [`db.test.ts:12`](..\u002F..\u002F..\u002Fsrc\u002Fdb.test.ts#L12)\nhanded to qc [`qc`](..\u002Fqc\u002FSKILL.md)\n```\n","# Refactor\n\nMove **structure** with **behavior locked**. The net is a test green before the move and green after — never a judgment that \"this looks the same.\"\n\nBehavior is settled here, and that is what lets you touch structure without a spec or a plan. You enter at a behavior-preserving structure change, asked for directly or handed over by [qc](..\u002Fqc\u002FSKILL.md), [architecture-audit](..\u002Farchitecture-audit\u002FSKILL.md), [clean-code](..\u002Fclean-code\u002FSKILL.md), or [tdd](..\u002Ftdd\u002FSKILL.md)'s post-green pass. You bypass [write-specs](..\u002Fwrite-specs\u002FSKILL.md) and [write-plan](..\u002Fwrite-plan\u002FSKILL.md) — there is no new behavior to specify or route.\n\nA refactor that changes observable behavior is a bug wearing a refactor's clothes. The test net is what catches it.\n\n## Steps\n\n### 1. Pin the behavior\n\nBefore any structure changes, establish a **green net** that captures the behavior under the move.\n\n- A passing test already covers the behavior → use it.\n- No test covers it → write a **characterization test** that captures the behavior as it is today, not as it should be, and run it green. This is not red-green: the test encodes current behavior, bugs and all, because the move must not change it.\n- No runnable check exists at all — no test runner, no script, no REPL command that exercises the target → wire the runner the language ships with or the repo already depends on, then write the characterization test above. Adding a new dependency is the user's call: ask first, and if they decline, state the absence and stop. You do not move structure blind.\n- The target has no observable behavior — nothing calls it, or every call is itself dead → flag it dead and hand to [write-plan](..\u002Fwrite-plan\u002FSKILL.md) for deletion. There is nothing to characterize.\n\nEach pinning test, reused or new, asserts a value rather than a shape, per [Writing the test](..\u002Ftdd\u002FSKILL.md#writing-the-test). For a characterization test, the known-good literal is today's output, captured by running the code once. Before the first move, prove each pinning test can fail: change its expected literal, run it **red**, restore the literal, run it green. A test that stays green with its literal changed is no net; rewrite its assertion until it goes red.\n\n**Done when** a green test pins every behavior the move touches and each one has gone **red** with its expected literal changed, or the target is flagged dead, or the user declined a runner.\n\n### 2. Move the structure\n\nExecute the move: a **rename**, an **extraction**, or a **reorder** — the vocabulary [clean-code](..\u002Fclean-code\u002FSKILL.md) uses, at the scale [qc](..\u002Fqc\u002FSKILL.md) would recommend. One move at a time; run the net after each. Green stays green between moves.\n\nA move that cannot finish with the net green stops here — it is not behavior-preserving, and you are at step 3's decline.\n\n**Done when** the structural move is complete and the net is green after every move in it.\n\n### 3. Gate behavior\n\nRun the full net — the characterization tests plus every pre-existing test in scope. The behavior captured in step 1 must reproduce exactly.\n\n- Green → the move held behavior. Proceed.\n- Red → the move changed behavior. **Revert that move.** Do not adjust the test to make it pass: a test edited to match new behavior is the net disabled, and the red is the net doing its job.\n\nA move that needs new or changed behavior to make sense — a new branch, a different return on some input, behavior that was not there before — is **declined**, not forced. That is not a refactor; it is new behavior, and it enters the chain at [write-plan](..\u002Fwrite-plan\u002FSKILL.md), worked as [tdd](..\u002Ftdd\u002FSKILL.md). Hand it over with the structural goal named; the plan can carry both.\n\n**Done when** the net is green end to end and no move in this pass introduced behavior, or the behavior-changing move has been declined and handed to write-plan.\n\n### 4. Hand to qc\n\nStructure moved, behavior held, net green: hand the change to [qc](..\u002Fqc\u002FSKILL.md) to review the **new structure** — the move may be behavior-preserving and still be ugly, mislayered, or indirected past readability. qc is the axis for that; refactor is not.\n\n**Done when** the change is handed to qc with the move named and the net result recorded.\n\n## Referencing\n\nWhere an effort directory exists for the change, the refactor records its net and result there as `\u003Cname>.refactor.md`, under the [referencing convention](..\u002Fwrite-specs\u002FSKILL.md#referencing). Where none exists, the result goes to chat and the net is the repo's tests; refactor bypasses write-specs and write-plan, so it never creates one.\n\n```markdown\npinned behavior [`db.test.ts:12`](..\u002F..\u002F..\u002Fsrc\u002Fdb.test.ts#L12)\nhanded to qc [`qc`](..\u002Fqc\u002FSKILL.md)\n```\n",{"name":5,"description":7},"main","534498267dccbe415f22f31fceac9da6771c195f","plugins\u002Fworkbench\u002Fskills\u002Frefactor","https:\u002F\u002Fgithub.com\u002Fj0hanz\u002Fj0hanz-marketplace","https:\u002F\u002Fj0hanz-marketplace.vercel.app","https:\u002F\u002Fgithub.com\u002Fj0hanz","linus-johansson-cv-d308be9b73e1.herokuapp.com","2026-11-15 02:42:07",{"source":8,"skillName":5,"commands":33,"prompt":43,"zipAvailable":44},[34,37,40],{"tool":35,"command":36},"npx","npx skills add j0hanz\u002Fj0hanz-marketplace --skill refactor",{"tool":38,"command":39},"bunx","bunx skills add j0hanz\u002Fj0hanz-marketplace --skill refactor",{"tool":41,"command":42},"pnpm","pnpm dlx skills add j0hanz\u002Fj0hanz-marketplace --skill refactor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fj0hanz\u002Fj0hanz-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fworkbench\u002Fskills\u002Frefactor\u002FSKILL.md",true,[],[47,54,61,68,75,82],{"skillNo":48,"name":49,"nameZh":6,"description":50,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":51,"categories":52,"keywords":53,"publishedAt":19},"01M7ABP78JFYBMCXJ9GMETCYZM","unslop","Use when writing or editing prose a person will read, or when text sounds AI-generated.","https:\u002F\u002Fgithub.com\u002Fj0hanz\u002Fj0hanz-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fwriteup\u002Fskills\u002Funslop\u002FSKILL.md",[],[],{"skillNo":55,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":58,"categories":59,"keywords":60,"publishedAt":19},"01M7ABP52BNV7NRPNBR6PCNZWC","show-me","Use when asked to show, diagram, or walk through how code fits together or what a change does, or before explaining a multi-file flow in prose.","https:\u002F\u002Fgithub.com\u002Fj0hanz\u002Fj0hanz-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fwriteup\u002Fskills\u002Fshow-me\u002FSKILL.md",[],[],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":67,"publishedAt":19},"01M7ABP3EPN4KFB4HPJNMY31NR","pr","Use when writing or updating a pull request description, or before running `gh pr create`.","https:\u002F\u002Fgithub.com\u002Fj0hanz\u002Fj0hanz-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fwriteup\u002Fskills\u002Fpr\u002FSKILL.md",[],[],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":19},"01M7ABP08MXTHPZYTG4HKEP7WQ","commit","Use when writing a commit message, or before running `git commit`.","https:\u002F\u002Fgithub.com\u002Fj0hanz\u002Fj0hanz-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fwriteup\u002Fskills\u002Fcommit\u002FSKILL.md",[],[],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":19},"01M7ABNV9J7DN1AFRBGDBHVBY2","write-specs","Spec a feature's observable behavior. Use when asked for requirements, when a request says what the system should do but not how, or to capture what a built system already guarantees. Not for how to build it (write-plan).","https:\u002F\u002Fgithub.com\u002Fj0hanz\u002Fj0hanz-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fworkbench\u002Fskills\u002Fwrite-specs\u002FSKILL.md",[],[],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":19},"01M7ABNPK2GVG8EB3SSEAMK4FZ","write-skills","Write, fix, or audit a skill's frontmatter, trigger description, and body. Use when a skill is asked for, never fires, or fires at the wrong moment. Not for a hook (write-hooks) or the plugin manifest and catalog.","https:\u002F\u002Fgithub.com\u002Fj0hanz\u002Fj0hanz-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fworkbench\u002Fskills\u002Fwrite-skills\u002FSKILL.md",[],[]]