[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6RAER0Q716PFNKAPVXX7AVC":3,"skill-same:01M6RAER0Q716PFNKAPVXX7AVC":75},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M6RAER0Q716PFNKAPVXX7AVC","improve-codebase-architecture",null,"Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.","HNUST-Dust\u002FDust_infantry_vision","HNUST-Dust","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F242605597?v=4","01M6RAD8QP9GXRZWD7WEN7KXWZ","01M6RAD8XNF76XNGYHDPX4AV12",5,"MIT","https:\u002F\u002Fgithub.com\u002FHNUST-Dust\u002FDust_infantry_vision\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fimprove-codebase-architecture\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"improve codebase architecture","architecture","improve","codebase","report","html report","pick","html","grill","scan","visual","present","as","you","for","deepening","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.\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\n**Scope before you scan — YAGNI.** Deepening a module pays off by making future changes to it easier, so put extra weight on the parts of the codebase that have recently changed. Decide *where* to look before you look:\n\n- If the user named a direction — a module, a subsystem, a pain point — take it, and skip the inference below.\n- Otherwise, walk back a good stretch of the commit history (`git log --oneline`) to find the codebase's hot spots — the files and areas that keep coming up — and let those paths pull your attention first. If the changes are scattered with no clear hot spot, widen the net.\n\nRead the project's domain glossary (`CONTEXT.md`) and any ADRs in the area you're touching first.\n\nThen spawn a sub-agent 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 decision 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\n**Scope before you scan — YAGNI.** Deepening a module pays off by making future changes to it easier, so put extra weight on the parts of the codebase that have recently changed. Decide *where* to look before you look:\n\n- If the user named a direction — a module, a subsystem, a pain point — take it, and skip the inference below.\n- Otherwise, walk back a good stretch of the commit history (`git log --oneline`) to find the codebase's hot spots — the files and areas that keep coming up — and let those paths pull your attention first. If the changes are scattered with no clear hot spot, widen the net.\n\nRead the project's domain glossary (`CONTEXT.md`) and any ADRs in the area you're touching first.\n\nThen spawn a sub-agent 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 decision 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},"main","1ce4eeca9e26627f8e445d56f5abf69f372eb3dd",".codex\u002Fskills\u002Fimprove-codebase-architecture",1,"https:\u002F\u002Fgithub.com\u002FHNUST-Dust\u002FDust_infantry_vision","https:\u002F\u002Fgithub.com\u002FHNUST-Dust","2026-11-13 20:21:39",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add HNUST-Dust\u002FDust_infantry_vision --skill improve-codebase-architecture",{"tool":57,"command":58},"bunx","bunx skills add HNUST-Dust\u002FDust_infantry_vision --skill improve-codebase-architecture",{"tool":60,"command":61},"pnpm","pnpm dlx skills add HNUST-Dust\u002FDust_infantry_vision --skill improve-codebase-architecture","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FHNUST-Dust\u002FDust_infantry_vision\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fimprove-codebase-architecture\u002FSKILL.md",true,[65,71],{"path":66,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":69,"sourceHtmlUrl":70},"agents\u002Fopenai.yaml","REFERENCE","参考文档",271,"https:\u002F\u002Fgithub.com\u002FHNUST-Dust\u002FDust_infantry_vision\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fimprove-codebase-architecture\u002Fagents\u002Fopenai.yaml",{"path":72,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":73,"sourceHtmlUrl":74},"HTML-REPORT.md",6685,"https:\u002F\u002Fgithub.com\u002FHNUST-Dust\u002FDust_infantry_vision\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fimprove-codebase-architecture\u002FHTML-REPORT.md",[76,102,120,139,156,178],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":39},"01M6RAEVD39W5QTD1BTNMR8XK3","replay-auto-aim","Reproduce and isolate auto-aim detection, tracking, solving, aiming, and planning issues from recorded video in this repository. Use for false positives, missed armors, tracker state changes, aim jitter, fire decisions, or latency regressions.","https:\u002F\u002Fgithub.com\u002FHNUST-Dust\u002FDust_infantry_vision\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Freplay-auto-aim\u002FSKILL.md",[],[83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,37,101],"auto","replay","replay auto aim","planning","state","issues","repository","detection","Video","reproduce","jitter","decisions","tracking","use","tracker","missed","latency","false","changes",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":39},"01M6RAEE88RSKY2HX0WVN67WJN","grill-with-docs","A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.","https:\u002F\u002Fgithub.com\u002FHNUST-Dust\u002FDust_infantry_vision\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fgrill-with-docs\u002FSKILL.md",[],[109,110,31,111,112,113,114,115,116,117,118,35,119],"docs","grill with docs","with","design","go","plan","sharpen","adr","glossary","interview","which",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":39},"01M6RAE7BMHJQJRMP79E5AGTNK","diagnosing-bugs","Diagnosis loop for hard bugs and performance regressions. Use when the user says \"diagnose\"\u002F\"debug this\", or reports something broken\u002Fthrowing\u002Ffailing\u002Fslow.","https:\u002F\u002Fgithub.com\u002FHNUST-Dust\u002FDust_infantry_vision\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fdiagnosing-bugs\u002FSKILL.md",[],[127,128,129,130,131,132,133,134,96,135,136,37,137,138],"diagnosing bugs","bugs","performance","debug","diagnose","loop","broken","user","reports","diagnosis","when","failing",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":39},"01M6RAE1HQRFJ1PQFHK3YX0AKH","diagnose-gimbal-link","Safely diagnose this repository's gimbal serial link, packet framing, CRC, timing, quaternion interpolation, and reconnect behavior. Use for \u002Fdev\u002Fgimbal failures, stale state, CRC errors, dropped packets, or incorrect control data.","https:\u002F\u002Fgithub.com\u002FHNUST-Dust\u002FDust_infantry_vision\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fdiagnose-gimbal-link\u002FSKILL.md",[],[131,146,147,148,87,89,149,150,96,151,152,153,154,37,155],"link","diagnose gimbal link","dev","data","behavior","stale","control","timing","errors","interpolation",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":162,"publishedAt":39},"01M6RADMNKPPTZS63V1W0EJG1S","diagnose-camera-stack","Diagnose HikRobot, MindVision, or USB camera discovery, SDK, streaming, frame, and frame-rate failures in this repository. Use when camera initialization fails, frames are empty, FPS is wrong, or exposure\u002Fgain\u002FVID-PID settings look suspect.","https:\u002F\u002Fgithub.com\u002FHNUST-Dust\u002FDust_infantry_vision\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fdiagnose-camera-stack\u002FSKILL.md",[],[131,163,164,165,166,167,89,168,169,96,170,171,172,173,174,175,176,177,137],"stack","camera","diagnose camera stack","sdk","streaming","discovery","settings","look","empty","PID","usb","initialization","frame","Wrong","rate",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":192,"publishedAt":39},"01M6RADFJ916YTFCPT88J9DDN9","codebase-design","Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.","https:\u002F\u002Fgithub.com\u002FHNUST-Dust\u002FDust_infantry_vision\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fcodebase-design\u002FSKILL.md",[184,187],{"categoryNo":185,"categoryName":186,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":188,"categoryName":189,"taxonomyType":190,"taxonomyTypeDesc":191},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[112,193,26,194,25,195,196,134,96,197,198,199,200,201,202,203,37,38,204,137],"codebase design","code","find","decide","modules","another skill","shared","deep","module","interface","more","seam"]