[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71S9QHT1TJMN2ZXFG7B347G":3,"skill-same:01M71S9QHT1TJMN2ZXFG7B347G":76},{"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":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":54,"updatedAt":55,"install":56,"resources":69},"01M71S9QHT1TJMN2ZXFG7B347G","improve-codebase-architecture",null,"Find architecture-deepening opportunities in a codebase","HigorAlves\u002Forc","HigorAlves","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F11262976?v=4","01M71S79EZEMHZ8PQSV0XQJHYY","Higor Alves","01M71S79FKKTCHCN1EDR8DSTWQ",7,"MIT","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Fcodex\u002Forc\u002Fcontent\u002Fskills\u002Fimprove-codebase-architecture\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"architecture","improve codebase architecture","codebase","improve","user","https","find","github","pin","use","more","make","deepening","audit","consolidate","when","matt pocock","modules","2026-11-10 13:02:02",false,"---\nname: improve-codebase-architecture\ndescription: Find architecture-deepening opportunities in a codebase\nwhen_to_use: Use when the user wants to improve architecture, find refactors, consolidate coupled modules, or make a codebase more testable and AI-navigable.\nlicense: MIT\nmetadata:\n  author: Matt Pocock\n  source: Derived from https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills (audit pin 5beb35b)\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 skill is _informed_ by the project's domain model and built on a shared design vocabulary:\n\n- Use `orc-codebase-design` 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 `GLOSSARY.md` gives names to good seams; ADRs in `docs\u002Fadr\u002F` record decisions this skill does not re-litigate.\n\n## Delegation in an orc session\n\nWhen running inside an orc session, the codebase SCAN phase (step 1 below) is delegated to the **orc-refactor-architect** agent — `$orc-plan` dispatches it when the input is refactor-shaped (refactor, architecture, tech debt, cleanup). This skill remains the interactive walkthrough layer: render the report and grill through the candidates. If the agent has already run, start from its findings instead of re-scanning — treat them as the raw material for step 2.\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 (`GLOSSARY.md`) and any ADRs in the area you're touching first.\n\nThen walk the codebase. If a Graphify code graph is available (see `orc-code-discovery`), start from its god-nodes and community structure — they surface high-fan-in modules and coupling directly, which is exactly the friction this skill hunts for — then read the cited spans. Otherwise use the Agent tool with `subagent_type=Explore`. Either way, 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 — `open \u003Cpath>` on macOS, `xdg-open \u003Cpath>` on Linux, `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 GLOSSARY.md vocabulary for the domain, and the `orc-codebase-design` vocabulary for the architecture.** If `GLOSSARY.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 [references\u002FHTML-REPORT.md](references\u002FHTML-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 `orc-grilling` 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 — use `orc-domain-modeling` to keep the domain model current as you go:\n\n- **Naming a deepened module after a concept not in `GLOSSARY.md`?** Add the term to `GLOSSARY.md` — same discipline as `orc-grill-with-docs` (see [GLOSSARY-FORMAT.md](..\u002Fdomain-modeling\u002Freferences\u002FGLOSSARY-FORMAT.md)). Create the file lazily if it doesn't exist.\n- **Sharpening a fuzzy term during the conversation?** Update `GLOSSARY.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. See the `orc-adr-writing` template (docs\u002Fadr\u002FNNNN-*.md numbering).\n- **Deepening a cluster with real dependencies?** See [DEEPENING.md](..\u002Fcodebase-design\u002Freferences\u002FDEEPENING.md) for dependency categories, seam discipline, and replace-don't-layer testing.\n- **Want to explore alternative interfaces for the deepened module?** Use the design-it-twice parallel sub-agent pattern in [DESIGN-IT-TWICE.md](..\u002Fcodebase-design\u002Freferences\u002FDESIGN-IT-TWICE.md).\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 skill is _informed_ by the project's domain model and built on a shared design vocabulary:\n\n- Use `orc-codebase-design` 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 `GLOSSARY.md` gives names to good seams; ADRs in `docs\u002Fadr\u002F` record decisions this skill does not re-litigate.\n\n## Delegation in an orc session\n\nWhen running inside an orc session, the codebase SCAN phase (step 1 below) is delegated to the **orc-refactor-architect** agent — `$orc-plan` dispatches it when the input is refactor-shaped (refactor, architecture, tech debt, cleanup). This skill remains the interactive walkthrough layer: render the report and grill through the candidates. If the agent has already run, start from its findings instead of re-scanning — treat them as the raw material for step 2.\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 (`GLOSSARY.md`) and any ADRs in the area you're touching first.\n\nThen walk the codebase. If a Graphify code graph is available (see `orc-code-discovery`), start from its god-nodes and community structure — they surface high-fan-in modules and coupling directly, which is exactly the friction this skill hunts for — then read the cited spans. Otherwise use the Agent tool with `subagent_type=Explore`. Either way, 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 — `open \u003Cpath>` on macOS, `xdg-open \u003Cpath>` on Linux, `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 GLOSSARY.md vocabulary for the domain, and the `orc-codebase-design` vocabulary for the architecture.** If `GLOSSARY.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 [references\u002FHTML-REPORT.md](references\u002FHTML-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 `orc-grilling` 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 — use `orc-domain-modeling` to keep the domain model current as you go:\n\n- **Naming a deepened module after a concept not in `GLOSSARY.md`?** Add the term to `GLOSSARY.md` — same discipline as `orc-grill-with-docs` (see [GLOSSARY-FORMAT.md](..\u002Fdomain-modeling\u002Freferences\u002FGLOSSARY-FORMAT.md)). Create the file lazily if it doesn't exist.\n- **Sharpening a fuzzy term during the conversation?** Update `GLOSSARY.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. See the `orc-adr-writing` template (docs\u002Fadr\u002FNNNN-*.md numbering).\n- **Deepening a cluster with real dependencies?** See [DEEPENING.md](..\u002Fcodebase-design\u002Freferences\u002FDEEPENING.md) for dependency categories, seam discipline, and replace-don't-layer testing.\n- **Want to explore alternative interfaces for the deepened module?** Use the design-it-twice parallel sub-agent pattern in [DESIGN-IT-TWICE.md](..\u002Fcodebase-design\u002Freferences\u002FDESIGN-IT-TWICE.md).\n",{"name":5,"license":15,"metadata":42,"description":7,"when_to_use":45},{"author":43,"source":44},"Matt Pocock","Derived from https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills (audit pin 5beb35b)","Use when the user wants to improve architecture, find refactors, consolidate coupled modules, or make a codebase more testable and AI-navigable.","main","7522fd7266944e30052204c2f6df287d8b5516be","codex\u002Forc\u002Fcontent\u002Fskills\u002Fimprove-codebase-architecture",0,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc","https:\u002F\u002Forc.novacstack.com\u002F","https:\u002F\u002Fgithub.com\u002FHigorAlves","higoralves.dev","Software Engineering","2026-11-07 07:26:38",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add HigorAlves\u002Forc --skill improve-codebase-architecture",{"tool":62,"command":63},"bunx","bunx skills add HigorAlves\u002Forc --skill improve-codebase-architecture",{"tool":65,"command":66},"pnpm","pnpm dlx skills add HigorAlves\u002Forc --skill improve-codebase-architecture","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Fcodex\u002Forc\u002Fcontent\u002Fskills\u002Fimprove-codebase-architecture\u002FSKILL.md",true,[70],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002FHTML-REPORT.md","REFERENCE","参考文档",6694,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Fcodex\u002Forc\u002Fcontent\u002Fskills\u002Fimprove-codebase-architecture\u002Freferences\u002FHTML-REPORT.md",[77,115,138,159,181,201],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":96,"publishedAt":37},"01M71SW40F9TAAEDKBYYBCM814","writing-plans","Write a comprehensive implementation plan of bite-sized TDD tasks that an engineer with zero codebase context could execute — exact files, code, tests, and verification steps","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-plans\u002FSKILL.md",[83,88,93],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":94,"categoryName":95,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000036","内容创作者",[97,98,99,100,101,102,103,34,104,105,106,107,108,109,110,111,112,113,114,28],"writing","writing plans","plans","engineer","superpowers","implementation plan","files","you","code","tasks","verification","plan","write","steps","context","ZeRO","for","tests",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":126,"publishedAt":37},"01M71SW15KHE4MHJW9NEXV65X2","writing-for-agents","orc's doctrine layer for writing any document an agent consumes — skills, AGENTS.md\u002FCLAUDE.md, reference docs","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-for-agents\u002FSKILL.md",[121,122,125],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},{"categoryNo":123,"categoryName":124,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":94,"categoryName":95,"taxonomyType":91,"taxonomyTypeDesc":92},[127,97,113,35,34,128,129,130,131,132,133,134,28,135,26,24,136,137],"writing for agents","inline","tuning","a skill","layer","doctrine","push","editing","document","reference","docs",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":145,"publishedAt":37},"01M71SVYQKXT743HHHWGHT3G13","workspace-mode","Use when cwd is a parent dir holding multiple sibling git repos — defines repo auto-detection, --repos\u002F--repo\u002F--all-repos\u002F--this-repo precedence, per-repo dispatch, and linked-PR mechanics.","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fworkspace-mode\u002FSKILL.md",[144],{"categoryNo":123,"categoryName":124,"taxonomyType":86,"taxonomyTypeDesc":87},[146,147,148,149,150,34,151,152,153,154,28,155,156,157,158],"workspace mode","mode","workspace","mechanics","auto","repos","git","pr","repo","dispatch","auto-detection","detection","parent",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":166,"publishedAt":37},"01M71SVVP3BXS06G9395P2K0RH","wizard","Generate an interactive bash wizard walking a human through work only they can perform — credentials, secrets, one-off migrations","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwizard\u002FSKILL.md",[165],{"categoryNo":123,"categoryName":124,"taxonomyType":86,"taxonomyTypeDesc":87},[161,167,168,169,170,35,34,171,172,173,174,175,176,110,177,178,113,28,179,180],"condition","never","provisioning infrastructure","only","Bash","work","credentials","generate","human","secrets","infrastructure","do","one","interactive",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":187,"publishedAt":37},"01M71SVT4AR6NKAM5B077E7QSJ","wait-what","Stop and re-pitch — the last message did not land; say it again simply, in the project's own vocabulary.","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwait-what\u002FSKILL.md",[],[188,189,190,191,192,35,193,194,195,196,26,24,197,198,199,200],"wait what","wait","project","re","true","pitch","last","say","message","land","it","stop","vocabulary",{"skillNo":202,"name":203,"nameZh":6,"description":204,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":205,"categories":206,"keywords":211,"publishedAt":37},"01M71SVQVYRA9QBQ6G8MWR8G6F","vitest","Vitest fast unit testing framework powered by Vite with Jest-compatible API","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fvitest\u002FSKILL.md",[207,210],{"categoryNo":208,"categoryName":209,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},[203,212,213,214,215,216,97,34,217,218,219,220,221,222,223,224,225,226,114,227],"coverage","unit","testing","testing framework","generated","api","jest","2026","at","scripts","unit testing","antfu","framework","vite","mocking","dev"]