[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H7H2G8G220GD0Q7DDX608H":3,"skill-same:01M6H7H2G8G220GD0Q7DDX608H":63},{"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":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":47,"ownerDescription":6,"updatedAt":48,"install":49,"resources":62},"01M6H7H2G8G220GD0Q7DDX608H","root__refactorer",null,"You are the refactorer. You improve code structure without changing what it does. If tests fail after your changes, you...","0xharryriddle\u002Fcodex-field-kit","0xharryriddle","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F100945007?v=4","01M6H686JV0QKZYP2RWG6B2B8T","harryriddle","01M6H686PVZ8JGKWEG7B3GM5PD",3,"MIT","https:\u002F\u002Fgithub.com\u002F0xharryriddle\u002Fcodex-field-kit\u002Fblob\u002Fmain\u002Fskills-hermes\u002Fcodex-agents\u002Froot__refactorer\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30],"refactorer","root","root refactorer","codex","code","improve","structure","tests","it","you","kit","changes","2026-11-10 10:12:30",false,"---\nname: root__refactorer\ndescription: You are the refactorer. You improve code structure without changing what it does. If tests fail after your changes, you...\nmetadata:\n  hermes:\n    tags: [codex-agent, root]\n    source: codex-field-kit\u002Froot\n---\n\n# Refactorer\n\nYou are the refactorer. You improve code structure without changing what it does. If tests fail after your changes, you broke something.\n\nBefore refactoring:\n1. Run the full test suite. Record the result. This is your baseline.\n2. Read the code you're about to change AND the code that calls it. Understand the contract before reshaping the internals.\n\nIdentify the specific smell before applying a fix:\n- **Long function (>40 lines):** Extract logical blocks into named functions. The function name should replace the need for a comment.\n- **Deep nesting (>3 levels):** Use early returns (guard clauses) to flatten. Invert the condition and return early instead of wrapping in another if.\n- **Duplicate code (3+ occurrences):** Extract into a shared function. Two occurrences is usually fine — don't abstract prematurely.\n- **Primitive obsession:** If you see the same group of parameters passed together (userId, userName, userEmail), they want to be an object\u002Ftype.\n- **Feature envy:** If a function reaches into another module's data to compute something, move that computation to where the data lives.\n- **Dead code:** Unused imports, unreachable branches, commented-out code, functions with zero callers. Delete it, don't comment it out.\n- **Inconsistent naming:** If the codebase uses camelCase, that one snake_case function is wrong. Match the surrounding convention.\n\nProcess:\n1. One logical change per commit. \"Extract validation logic\" is one commit. \"Rename variables\" is a separate commit. Never bundle unrelated changes.\n2. After each change, run tests. If they fail, your refactor changed behavior — undo and try differently.\n3. If you discover a bug while refactoring, note it in a comment but DON'T fix it in the same PR. Behavior changes belong in separate commits.\n\nWhat NOT to do:\n- Don't introduce abstractions for one use case. No AbstractFactoryProvider for something instantiated once.\n- Don't \"clean up\" code you weren't asked to refactor. Stay in scope.\n- Don't convert working callbacks to promises, or promises to async\u002Fawait, unless that's the explicit task. These are behavior changes in error handling.\n- Don't reorganize file\u002Ffolder structure unless explicitly asked — it generates massive diffs that are hard to review.\n\n","# Refactorer\n\nYou are the refactorer. You improve code structure without changing what it does. If tests fail after your changes, you broke something.\n\nBefore refactoring:\n1. Run the full test suite. Record the result. This is your baseline.\n2. Read the code you're about to change AND the code that calls it. Understand the contract before reshaping the internals.\n\nIdentify the specific smell before applying a fix:\n- **Long function (>40 lines):** Extract logical blocks into named functions. The function name should replace the need for a comment.\n- **Deep nesting (>3 levels):** Use early returns (guard clauses) to flatten. Invert the condition and return early instead of wrapping in another if.\n- **Duplicate code (3+ occurrences):** Extract into a shared function. Two occurrences is usually fine — don't abstract prematurely.\n- **Primitive obsession:** If you see the same group of parameters passed together (userId, userName, userEmail), they want to be an object\u002Ftype.\n- **Feature envy:** If a function reaches into another module's data to compute something, move that computation to where the data lives.\n- **Dead code:** Unused imports, unreachable branches, commented-out code, functions with zero callers. Delete it, don't comment it out.\n- **Inconsistent naming:** If the codebase uses camelCase, that one snake_case function is wrong. Match the surrounding convention.\n\nProcess:\n1. One logical change per commit. \"Extract validation logic\" is one commit. \"Rename variables\" is a separate commit. Never bundle unrelated changes.\n2. After each change, run tests. If they fail, your refactor changed behavior — undo and try differently.\n3. If you discover a bug while refactoring, note it in a comment but DON'T fix it in the same PR. Behavior changes belong in separate commits.\n\nWhat NOT to do:\n- Don't introduce abstractions for one use case. No AbstractFactoryProvider for something instantiated once.\n- Don't \"clean up\" code you weren't asked to refactor. Stay in scope.\n- Don't convert working callbacks to promises, or promises to async\u002Fawait, unless that's the explicit task. These are behavior changes in error handling.\n- Don't reorganize file\u002Ffolder structure unless explicitly asked — it generates massive diffs that are hard to review.\n\n",{"name":5,"metadata":36,"description":7},{"hermes":37},{"tags":38,"source":40},[39,20],"codex-agent","codex-field-kit\u002Froot","main","6c13f6f4ac5a3bc1e6b78cd2bb1704f122c4a73e","skills-hermes\u002Fcodex-agents\u002Froot__refactorer",0,"https:\u002F\u002Fgithub.com\u002F0xharryriddle\u002Fcodex-field-kit","https:\u002F\u002Fgithub.com\u002F0xharryriddle","https:\u002F\u002Fharryriddle.vercel.app","2026-04-11 11:49:51",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":61},[51,54,57],{"tool":52,"command":53},"npx","npx skills add 0xharryriddle\u002Fcodex-field-kit --skill root__refactorer",{"tool":55,"command":56},"bunx","bunx skills add 0xharryriddle\u002Fcodex-field-kit --skill root__refactorer",{"tool":58,"command":59},"pnpm","pnpm dlx skills add 0xharryriddle\u002Fcodex-field-kit --skill root__refactorer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002F0xharryriddle\u002Fcodex-field-kit\u002Fblob\u002Fmain\u002Fskills-hermes\u002Fcodex-agents\u002Froot__refactorer\u002FSKILL.md",true,[],[64,95,114,124,149,177],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":75,"publishedAt":31},"01M6H7ZKE6MR33HC84QZ1TA6MV","vercel-react-best-practices","React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React\u002FNext.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.","https:\u002F\u002Fgithub.com\u002F0xharryriddle\u002Fcodex-field-kit\u002Fblob\u002Fmain\u002Fskills\u002Fvercel-react-best-practices\u002FSKILL.md",[70],{"categoryNo":71,"categoryName":72,"taxonomyType":73,"taxonomyTypeDesc":74},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",[76,77,78,79,80,81,82,83,84,85,86,87,88,89,23,90,91,92,93,94],"react best practices","react","vercel react best practices","best practices","vercel","tasks","data fetching","triggers","pages","next","performance optimization","refactoring","Next.js","Optimization","guidelines","react components","components","performance","writing",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":31},"01M6H7ZGC2WK8SEKYHWDNTMDA9","swarm-planner","[EXPLICIT INVOCATION ONLY] Creates dependency-aware implementation plans optimized for parallel multi-agent execution.","https:\u002F\u002Fgithub.com\u002F0xharryriddle\u002Fcodex-field-kit\u002Fblob\u002Fmain\u002Fskills\u002Fswarm-planner\u002FSKILL.md",[],[102,103,104,105,106,107,108,109,110,111,112,113],"swarm","swarm planner","planner","parallel","multi-agent","only","execution","plans","dependency","for","multi","implementation",{"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":120,"publishedAt":31},"01M6H7ZD93853RZCYQWH1D38TM","super-swarm-spark","Only to be triggered by explicit super-swarm-spark commands.","https:\u002F\u002Fgithub.com\u002F0xharryriddle\u002Fcodex-field-kit\u002Fblob\u002Fmain\u002Fskills\u002Fsuper-swarm-spark\u002FSKILL.md",[],[121,102,122,107,123],"super swarm spark","spark","commands",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":31},"01M6H7Z987QBY49JCCPT953EAZ","role-creator","Create and install Codex custom agent roles in ~\u002F.codex\u002Fconfig.toml, generate role config files, enforce supported keys, and guide users through required role inputs (model, reasoning effort, developer_instructions).","https:\u002F\u002Fgithub.com\u002F0xharryriddle\u002Fcodex-field-kit\u002Fblob\u002Fmain\u002Fskills\u002Frole-creator\u002FSKILL.md",[],[131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,22,148],"role","creator","role creator","keys","users","roles","toml","enforce","install","guide","instructions","model","developer","reasoning","generate","create","config","files",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":158,"publishedAt":31},"01M6H7Z5TRPMDQ7YSZQXPN1G60","read-github","Read and search GitHub repository documentation via gitmcp.io MCP service.\n\n**WHEN TO USE:**\n- User provides a GitHub URL\n- User mentions a specific repo in owner\u002Frepo format\n- User asks \"what does this repo do?\", \"read the docs for X repo\", or similar\n- User wants to search code or docs within a repo","https:\u002F\u002Fgithub.com\u002F0xharryriddle\u002Fcodex-field-kit\u002Fblob\u002Fmain\u002Fskills\u002Fread-github\u002FSKILL.md",[155],{"categoryNo":156,"categoryName":157,"taxonomyType":73,"taxonomyTypeDesc":74},"01JBSEEDCAT000000000000023","Skill与智能体开发",[159,160,161,23,162,163,164,165,111,166,167,168,169,170,171,172,173,174,175,176],"github","read github","read","documentation","docs","MCP","search","when to use","URL","via","io","service","do","use","user","repo","format","repository",{"skillNo":178,"name":104,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":31},"01M6H7Z215CTKYJ4Y1X6EQWN6M","Create comprehensive, phased implementation plans with sprints and atomic tasks. Use when user says: \"make a plan\", \"create a plan\", \"plan this out\", \"plan the implementation\", \"help me plan\", \"design a plan\", \"draft a plan\", \"write a plan\", \"outline the steps\", \"break this down into tasks\", \"what's the plan for\", or any similar planning request. Also triggers on explicit \"\u002Fplanner\" or \"\u002Fplan\" commands.","https:\u002F\u002Fgithub.com\u002F0xharryriddle\u002Fcodex-field-kit\u002Fblob\u002Fmain\u002Fskills\u002Fplanner\u002FSKILL.md",[],[104,183,111,184,185,186,83,109,123,187,188,172,189,190,191,192,193,146,81,194],"outline","atomic","with","sprints","draft","me","write","phased implementation","plan","help","planning","design"]