[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PFSRTJX8QYCAYAVQM6PVE8":3,"skill-same:01M6PFSRTJX8QYCAYAVQM6PVE8":73},{"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":23,"publishedAt":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":53,"install":54,"resources":66},"01M6PFSRTJX8QYCAYAVQM6PVE8","improve-codebase-architecture",null,"Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.","refo\u002Fclaude-dev-helpers","refo","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1114116?v=4","01M6PFRE5P2JXK3P8VYTERWA33","Refik ÖNAL","01M6PFRE9XZS4SGHG2NQGJ9AB3",2,"MIT","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fengineering\u002Fimprove-codebase-architecture\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"architecture","improve codebase architecture","improve","codebase","deepening","for","true","you","as","present","visual","scan","grill","html","pick","html report","report","2026-11-10 10:12:30",false,"---\nname: improve-codebase-architecture\ndescription: Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.\ndisable-model-invocation: true\n---\n\n# Improve Codebase Architecture\n\nSurface architectural friction and propose **deepening opportunities** — refactors that turn shallow modules into deep ones. The aim is testability and AI-navigability.\n\nThis command is _informed_ by the project's domain model and built on a shared design vocabulary:\n\n- Run the `\u002Fcodebase-design` skill for the architecture vocabulary (**module**, **interface**, **depth**, **seam**, **adapter**, **leverage**, **locality**) and its principles (the deletion test, \"the interface is the test surface\", \"one adapter = hypothetical seam, two = real\"). Use these terms exactly in every suggestion — don't drift into \"component,\" \"service,\" \"API,\" or \"boundary.\"\n- The domain language in `CONTEXT.md` gives names to good seams; ADRs in `docs\u002Fadr\u002F` record decisions this command should not re-litigate.\n\n## Process\n\n### 1. Explore\n\nRead the project's domain glossary (`CONTEXT.md`) and any ADRs in the area you're touching first.\n\nThen use the Agent tool with `subagent_type=Explore` to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:\n\n- Where does understanding one concept require bouncing between many small modules?\n- Where are modules **shallow** — interface nearly as complex as the implementation?\n- Where have pure functions been extracted just for testability, but the real bugs hide in how they're called (no **locality**)?\n- Where do tightly-coupled modules leak across their seams?\n- Which parts of the codebase are untested, or hard to test through their current interface?\n\nApply the **deletion test** to anything you suspect is shallow: would deleting it concentrate complexity, or just move it? A \"yes, concentrates\" is the signal you want.\n\n### 2. Present candidates as an HTML report\n\nWrite a self-contained HTML file to the OS temp directory so nothing lands in the repo. Resolve the temp dir from `$TMPDIR`, falling back to `\u002Ftmp` (or `%TEMP%` on Windows), and write to `\u003Ctmpdir>\u002Farchitecture-review-\u003Ctimestamp>.html` so each run gets a fresh file. Open it for the user — `xdg-open \u003Cpath>` on Linux, `open \u003Cpath>` on macOS, `start \u003Cpath>` on Windows — and tell them the absolute path.\n\nThe report uses **Tailwind via CDN** for layout and styling, and **Mermaid via CDN** for diagrams where a graph\u002Fflow\u002Fsequence reliably communicates the structure. Mix Mermaid with hand-crafted CSS\u002FSVG visuals — use Mermaid when relationships are graph-shaped (call graphs, dependencies, sequences), and hand-built divs\u002FSVG when you want something more editorial (mass diagrams, cross-sections, collapse animations). Each candidate gets a **before\u002Fafter visualisation**. Be visual.\n\nFor each candidate, render a card with:\n\n- **Files** — which files\u002Fmodules are involved\n- **Problem** — why the current architecture is causing friction\n- **Solution** — plain English description of what would change\n- **Benefits** — explained in terms of locality and leverage, and how tests would improve\n- **Before \u002F After diagram** — side-by-side, custom-drawn, illustrating the shallowness and the deepening\n- **Recommendation strength** — one of `Strong`, `Worth exploring`, `Speculative`, rendered as a badge\n\nEnd the report with a **Top recommendation** section: which candidate you'd tackle first and why.\n\n**Use CONTEXT.md vocabulary for the domain, and the `\u002Fcodebase-design` vocabulary for the architecture.** If `CONTEXT.md` defines \"Order,\" talk about \"the Order intake module\" — not \"the FooBarHandler,\" and not \"the Order service.\"\n\n**ADR conflicts**: if a candidate contradicts an existing ADR, only surface it when the friction is real enough to warrant revisiting the ADR. Mark it clearly in the card (e.g. a warning callout: _\"contradicts ADR-0007 — but worth reopening because…\"_). Don't list every theoretical refactor an ADR forbids.\n\nSee [HTML-REPORT.md](HTML-REPORT.md) for the full HTML scaffold, diagram patterns, and styling guidance.\n\nDo NOT propose interfaces yet. After the file is written, ask the user: \"Which of these would you like to explore?\"\n\n### 3. Grilling loop\n\nOnce the user picks a candidate, run the `\u002Fgrilling` skill to walk the design tree with them — constraints, dependencies, the shape of the deepened module, what sits behind the seam, what tests survive.\n\nSide effects happen inline as decisions crystallize — run the `\u002Fdomain-modeling` skill to keep the domain model current as you go:\n\n- **Naming a deepened module after a concept not in `CONTEXT.md`?** Add the term to `CONTEXT.md`. Create the file lazily if it doesn't exist.\n- **Sharpening a fuzzy term during the conversation?** Update `CONTEXT.md` right there.\n- **User rejects the candidate with a load-bearing reason?** Offer an ADR, framed as: _\"Want me to record this as an ADR so future architecture reviews don't re-suggest it?\"_ Only offer when the reason would actually be needed by a future explorer to avoid re-suggesting the same thing — skip ephemeral reasons (\"not worth it right now\") and self-evident ones.\n- **Want to explore alternative interfaces for the deepened module?** Run the `\u002Fcodebase-design` skill and use its design-it-twice parallel sub-agent pattern.\n","# Improve Codebase Architecture\n\nSurface architectural friction and propose **deepening opportunities** — refactors that turn shallow modules into deep ones. The aim is testability and AI-navigability.\n\nThis command is _informed_ by the project's domain model and built on a shared design vocabulary:\n\n- Run the `\u002Fcodebase-design` skill for the architecture vocabulary (**module**, **interface**, **depth**, **seam**, **adapter**, **leverage**, **locality**) and its principles (the deletion test, \"the interface is the test surface\", \"one adapter = hypothetical seam, two = real\"). Use these terms exactly in every suggestion — don't drift into \"component,\" \"service,\" \"API,\" or \"boundary.\"\n- The domain language in `CONTEXT.md` gives names to good seams; ADRs in `docs\u002Fadr\u002F` record decisions this command should not re-litigate.\n\n## Process\n\n### 1. Explore\n\nRead the project's domain glossary (`CONTEXT.md`) and any ADRs in the area you're touching first.\n\nThen use the Agent tool with `subagent_type=Explore` to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:\n\n- Where does understanding one concept require bouncing between many small modules?\n- Where are modules **shallow** — interface nearly as complex as the implementation?\n- Where have pure functions been extracted just for testability, but the real bugs hide in how they're called (no **locality**)?\n- Where do tightly-coupled modules leak across their seams?\n- Which parts of the codebase are untested, or hard to test through their current interface?\n\nApply the **deletion test** to anything you suspect is shallow: would deleting it concentrate complexity, or just move it? A \"yes, concentrates\" is the signal you want.\n\n### 2. Present candidates as an HTML report\n\nWrite a self-contained HTML file to the OS temp directory so nothing lands in the repo. Resolve the temp dir from `$TMPDIR`, falling back to `\u002Ftmp` (or `%TEMP%` on Windows), and write to `\u003Ctmpdir>\u002Farchitecture-review-\u003Ctimestamp>.html` so each run gets a fresh file. Open it for the user — `xdg-open \u003Cpath>` on Linux, `open \u003Cpath>` on macOS, `start \u003Cpath>` on Windows — and tell them the absolute path.\n\nThe report uses **Tailwind via CDN** for layout and styling, and **Mermaid via CDN** for diagrams where a graph\u002Fflow\u002Fsequence reliably communicates the structure. Mix Mermaid with hand-crafted CSS\u002FSVG visuals — use Mermaid when relationships are graph-shaped (call graphs, dependencies, sequences), and hand-built divs\u002FSVG when you want something more editorial (mass diagrams, cross-sections, collapse animations). Each candidate gets a **before\u002Fafter visualisation**. Be visual.\n\nFor each candidate, render a card with:\n\n- **Files** — which files\u002Fmodules are involved\n- **Problem** — why the current architecture is causing friction\n- **Solution** — plain English description of what would change\n- **Benefits** — explained in terms of locality and leverage, and how tests would improve\n- **Before \u002F After diagram** — side-by-side, custom-drawn, illustrating the shallowness and the deepening\n- **Recommendation strength** — one of `Strong`, `Worth exploring`, `Speculative`, rendered as a badge\n\nEnd the report with a **Top recommendation** section: which candidate you'd tackle first and why.\n\n**Use CONTEXT.md vocabulary for the domain, and the `\u002Fcodebase-design` vocabulary for the architecture.** If `CONTEXT.md` defines \"Order,\" talk about \"the Order intake module\" — not \"the FooBarHandler,\" and not \"the Order service.\"\n\n**ADR conflicts**: if a candidate contradicts an existing ADR, only surface it when the friction is real enough to warrant revisiting the ADR. Mark it clearly in the card (e.g. a warning callout: _\"contradicts ADR-0007 — but worth reopening because…\"_). Don't list every theoretical refactor an ADR forbids.\n\nSee [HTML-REPORT.md](HTML-REPORT.md) for the full HTML scaffold, diagram patterns, and styling guidance.\n\nDo NOT propose interfaces yet. After the file is written, ask the user: \"Which of these would you like to explore?\"\n\n### 3. Grilling loop\n\nOnce the user picks a candidate, run the `\u002Fgrilling` skill to walk the design tree with them — constraints, dependencies, the shape of the deepened module, what sits behind the seam, what tests survive.\n\nSide effects happen inline as decisions crystallize — run the `\u002Fdomain-modeling` skill to keep the domain model current as you go:\n\n- **Naming a deepened module after a concept not in `CONTEXT.md`?** Add the term to `CONTEXT.md`. Create the file lazily if it doesn't exist.\n- **Sharpening a fuzzy term during the conversation?** Update `CONTEXT.md` right there.\n- **User rejects the candidate with a load-bearing reason?** Offer an ADR, framed as: _\"Want me to record this as an ADR so future architecture reviews don't re-suggest it?\"_ Only offer when the reason would actually be needed by a future explorer to avoid re-suggesting the same thing — skip ephemeral reasons (\"not worth it right now\") and self-evident ones.\n- **Want to explore alternative interfaces for the deepened module?** Run the `\u002Fcodebase-design` skill and use its design-it-twice parallel sub-agent pattern.\n",{"name":5,"description":7,"disable-model-invocation":46},true,"main","488e6998e820e577029147aceabcbc69961c43df","plugins\u002Fmp\u002Fskills\u002Fskills\u002Fengineering\u002Fimprove-codebase-architecture",0,"https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers","https:\u002F\u002Fgithub.com\u002Frefo","2026-07-02 04:43:45",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":46},[56,59,62],{"tool":57,"command":58},"npx","npx skills add refo\u002Fclaude-dev-helpers --skill improve-codebase-architecture",{"tool":60,"command":61},"bunx","bunx skills add refo\u002Fclaude-dev-helpers --skill improve-codebase-architecture",{"tool":63,"command":64},"pnpm","pnpm dlx skills add refo\u002Fclaude-dev-helpers --skill improve-codebase-architecture","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fengineering\u002Fimprove-codebase-architecture\u002FSKILL.md",[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"HTML-REPORT.md","REFERENCE","参考文档",6685,"https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fengineering\u002Fimprove-codebase-architecture\u002FHTML-REPORT.md",[74,96,112,125,141,151],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":88,"publishedAt":41},"01M6PFW0KDMWH5HGR1GA8K39ZN","writing-great-skills","Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fproductivity\u002Fwriting-great-skills\u002FSKILL.md",[80,83],{"categoryNo":81,"categoryName":82,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[89,90,91,92,93,94,95,30,29],"writing great skills","writing","editing","reference","vocabulary","make","principles",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":105,"publishedAt":41},"01M6PFVXQ3PVRQ9035VZE9RBBX","teach","Teach the user a new skill or concept, within this workspace.","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fproductivity\u002Fteach\u002FSKILL.md",[102],{"categoryNo":103,"categoryName":104,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000039","教师与教育",[98,106,107,108,109,110,31,30,111],"new skill","learn","workspace","user","about","concept",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":41},"01M6PFVVJB7E7297GXB809B4J4","handoff","Compact the current conversation into a handoff document for another agent to pick up.","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fproductivity\u002Fhandoff\u002FSKILL.md",[],[114,119,120,121,122,30,29,123,124,38],"document","conversation","compact","next","up","session",{"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":131,"publishedAt":41},"01M6PFVS5DF6SM2251R15HR9A9","grilling","Interview the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fproductivity\u002Fgrilling\u002FSKILL.md",[],[127,132,133,134,135,136,109,137,138,36,139,140,110],"trigger","design","test","plan","before building","interview","use","stress-test","stress",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"publishedAt":41},"01M6PFVQE56YMR6MXKTYWA2467","grill-me","A relentless interview to sharpen a plan or design.","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fproductivity\u002Fgrill-me\u002FSKILL.md",[],[148,36,149,137,133,135,150,30],"me","grill me","sharpen",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":41},"01M6PFVMPQ6PWHRFRW5YYZ4VZF","obsidian-vault","Search, create, and manage notes in the Obsidian vault with wikilinks and index notes. Use when user wants to find, create, or organize notes in Obsidian.","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fpersonal\u002Fobsidian-vault\u002FSKILL.md",[],[158,159,160,161,162,163,164,165,109,138,166,167,168],"obsidian vault","vault","obsidian","notes","create","index","search","find","manage","organize","with"]