[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CFAXJJZ59SWHZ1RAGQ461N":3,"skill-same:01M6CFAXJJZ59SWHZ1RAGQ461N":78},{"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":52,"ownerDescription":53,"updatedAt":54,"install":55,"resources":67},"01M6CFAXJJZ59SWHZ1RAGQ461N","improve-codebase-architecture",null,"Use when the user wants architectural deepening opportunities for a codebase or named files, shown as a visual HTML report, and when they then pick candidates from that report to implement in the code already reviewed.","HeathWang\u002Fhw-cc-plugin","HeathWang","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F4961711?v=4","01M6CF9BZ3A0CSSG3QQGGDPFEH","Heath Wang","01M6CF9C3HT4NPM370Z8MYZW4G",1,"MIT","https:\u002F\u002Fgithub.com\u002FHeathWang\u002Fhw-cc-plugin\u002Fblob\u002Fmaster\u002Fskills\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],"improve","architecture","improve codebase architecture","codebase","user","implement","code","visual","use","files","true","for","as","html","html report","pick","report","2026-11-10 10:12:30",false,"---\nname: improve-codebase-architecture\ndescription: Use when the user wants architectural deepening opportunities for a codebase or named files, shown as a visual HTML report, and when they then pick candidates from that report to implement in the code already reviewed.\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\n## Language and Expression Rules\n\n1. **Follow User \u002F Context Language**:\n   - Determine the output language from the user's request, recent conversation context, or project documentation (`CONTEXT.md`, `CLAUDE.md`, README, commit history). If the user only provides a slash command and file paths (e.g. `\u002Fimprove-codebase-architecture path\u002Fto\u002FFile.swift`), infer the language from the conversation history, user rules, or codebase comments\u002Fdocs (defaulting to Simplified Chinese when working in a Chinese user\u002Fproject context).\n   - **Both the HTML report and the chat conclusion MUST use that language** — including HTML `\u003Chtml lang=\"...\">`, `\u003Ctitle>`, section headers, legend, candidate titles, badges, diagram labels\u002Fannotations, Problem\u002FSolution descriptions, benefits, Top Recommendation, and follow-up questions.\n   - Keep code identifiers (class names, method names, file paths) in their original code form.\n\n2. **Concise, Plain, and Easy to Understand (精炼通俗，直白易懂)**:\n   - Write for human developers who want to grasp the problem in 5 seconds, not for an academic architecture textbook.\n   - Replace obscure academic jargon with plain, concrete cause-and-effect language. For example, instead of *\"split-brain state bounces across the engine seam via raw DTOs\"*, write *\"结果页的 6 个修改接口直接写在 VC 里，改完又塞回 Engine 刷新，状态两头跑\"*.\n   - State **what is messy right now**, **how to merge\u002Fsimplify it**, and **what concrete benefit we get** (e.g., fewer places to touch, delete dead code, testable without UI).\n   - Keep every sentence short and direct. No filler, no pompous phrasing.\n\nThis command is _informed_ by the project's domain model and built on a shared design mindset:\n\n- Focus on core architecture concepts: **module (模块)**, **interface (接口\u002F对外入口)**, **depth (深度：小接口封装复杂实现 vs 浅层透传)**, **seam (接缝\u002F解耦点)**, **adapter (适配层)**, **leverage (杠杆率：一处实现多处复用)**, and **locality (内聚性\u002F局部性：改动集中在同一处)**. Apply these principles directly: the deletion test, \"the interface is the test surface\", \"one adapter = hypothetical seam, two = real\". Express conclusions in natural, everyday developer language.\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**, with an 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 (all text in the user's context language) with:\n\n- **Files**: which files\u002Fmodules are involved\n- **Problem (现状痛点)**: plain, everyday explanation of why the current code is painful to read, change, or test (1–2 short sentences)\n- **Solution (优化方案)**: clear, down-to-earth description of how to consolidate or simplify it (1–2 short sentences)\n- **Benefits (收益)**: concrete, easy-to-read bullets showing what gets deleted, where changes concentrate (locality), and how testing becomes simpler\n- **Before \u002F After diagram**: side-by-side, custom-drawn, illustrating the current mess vs. the simplified structure (use the user's language for diagram annotations and explanations, keeping only real code symbols in code font)\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, explained in plain language.\n\n**Use `CONTEXT.md` domain terms and keep architectural explanations natural.** Do not force awkward English glossary words into non-English reports. Explain module depth, interface size, and coupling in clear, idiomatic language that any developer on the team can immediately understand.\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 detailed code interfaces in the report. After the file is written, summarize the candidates briefly in the user's language (concise and plain) and ask which candidates to implement.\n\n### 3. Implement the chosen candidates\n\nWhen the user names one or more candidates — by number, title, or quoted report text — and asks to do, optimize, or land them, implement that selection in the codebase under review. This step has no other skill and no lookup step: the report and the code already read are the procedure. Several named candidates are one change when they touch the same state.\n\nThe spec is already in context:\n\n- the HTML report's Problem, Solution, and Before \u002F After for the chosen cards\n- the files, methods, and call paths read during Explore\n- the user's selection\n\nFollow behavior the current code already shows, except where the chosen Solution explicitly changes it. User-visible copy, error codes, popup and toast ownership, paywall triggers, and refresh timing come from that code and the report. Put the deepened logic in the module the report named. Leave UI the report left in the view layer (popups, toasts, navigation, paywalls) there. Shape the new interface to match the module's existing types and call style. Do not design a second interface in parallel.\n\nA fact you can read from code already opened is not a question. If the report's Solution and that code name the module, the methods to move, and what stays in the UI, edit now.\n\nStop and ask one question only when a behavior the candidate must change is neither stated in the report nor visible in the code you read. State the choice and a recommended default, then wait. Do not open a decision tree or a round of design questions before that.\n\nWhile editing:\n\n- **The deepened module needs a domain term `CONTEXT.md` does not already name?** Add that term. Create `CONTEXT.md` only in that case.\n- **The edit makes a fuzzy term in `CONTEXT.md` precise?** Update that term in the same edit.\n- **The user rejects a candidate for a reason a later review would need in order not to suggest it again?** Offer one ADR: _\"Want me to record this as an ADR so future architecture reviews don't re-suggest it?\"_ Skip \"not worth it right now\" and reasons that are obvious from the code.\n\nAfter the edit, run the check the repo already uses for those files (its test target or compiler command). Do not add a new test harness as a side task. If the repo has no such check, say so. The moved logic must be callable without presenting UI.\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\n## Language and Expression Rules\n\n1. **Follow User \u002F Context Language**:\n   - Determine the output language from the user's request, recent conversation context, or project documentation (`CONTEXT.md`, `CLAUDE.md`, README, commit history). If the user only provides a slash command and file paths (e.g. `\u002Fimprove-codebase-architecture path\u002Fto\u002FFile.swift`), infer the language from the conversation history, user rules, or codebase comments\u002Fdocs (defaulting to Simplified Chinese when working in a Chinese user\u002Fproject context).\n   - **Both the HTML report and the chat conclusion MUST use that language** — including HTML `\u003Chtml lang=\"...\">`, `\u003Ctitle>`, section headers, legend, candidate titles, badges, diagram labels\u002Fannotations, Problem\u002FSolution descriptions, benefits, Top Recommendation, and follow-up questions.\n   - Keep code identifiers (class names, method names, file paths) in their original code form.\n\n2. **Concise, Plain, and Easy to Understand (精炼通俗，直白易懂)**:\n   - Write for human developers who want to grasp the problem in 5 seconds, not for an academic architecture textbook.\n   - Replace obscure academic jargon with plain, concrete cause-and-effect language. For example, instead of *\"split-brain state bounces across the engine seam via raw DTOs\"*, write *\"结果页的 6 个修改接口直接写在 VC 里，改完又塞回 Engine 刷新，状态两头跑\"*.\n   - State **what is messy right now**, **how to merge\u002Fsimplify it**, and **what concrete benefit we get** (e.g., fewer places to touch, delete dead code, testable without UI).\n   - Keep every sentence short and direct. No filler, no pompous phrasing.\n\nThis command is _informed_ by the project's domain model and built on a shared design mindset:\n\n- Focus on core architecture concepts: **module (模块)**, **interface (接口\u002F对外入口)**, **depth (深度：小接口封装复杂实现 vs 浅层透传)**, **seam (接缝\u002F解耦点)**, **adapter (适配层)**, **leverage (杠杆率：一处实现多处复用)**, and **locality (内聚性\u002F局部性：改动集中在同一处)**. Apply these principles directly: the deletion test, \"the interface is the test surface\", \"one adapter = hypothetical seam, two = real\". Express conclusions in natural, everyday developer language.\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**, with an 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 (all text in the user's context language) with:\n\n- **Files**: which files\u002Fmodules are involved\n- **Problem (现状痛点)**: plain, everyday explanation of why the current code is painful to read, change, or test (1–2 short sentences)\n- **Solution (优化方案)**: clear, down-to-earth description of how to consolidate or simplify it (1–2 short sentences)\n- **Benefits (收益)**: concrete, easy-to-read bullets showing what gets deleted, where changes concentrate (locality), and how testing becomes simpler\n- **Before \u002F After diagram**: side-by-side, custom-drawn, illustrating the current mess vs. the simplified structure (use the user's language for diagram annotations and explanations, keeping only real code symbols in code font)\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, explained in plain language.\n\n**Use `CONTEXT.md` domain terms and keep architectural explanations natural.** Do not force awkward English glossary words into non-English reports. Explain module depth, interface size, and coupling in clear, idiomatic language that any developer on the team can immediately understand.\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 detailed code interfaces in the report. After the file is written, summarize the candidates briefly in the user's language (concise and plain) and ask which candidates to implement.\n\n### 3. Implement the chosen candidates\n\nWhen the user names one or more candidates — by number, title, or quoted report text — and asks to do, optimize, or land them, implement that selection in the codebase under review. This step has no other skill and no lookup step: the report and the code already read are the procedure. Several named candidates are one change when they touch the same state.\n\nThe spec is already in context:\n\n- the HTML report's Problem, Solution, and Before \u002F After for the chosen cards\n- the files, methods, and call paths read during Explore\n- the user's selection\n\nFollow behavior the current code already shows, except where the chosen Solution explicitly changes it. User-visible copy, error codes, popup and toast ownership, paywall triggers, and refresh timing come from that code and the report. Put the deepened logic in the module the report named. Leave UI the report left in the view layer (popups, toasts, navigation, paywalls) there. Shape the new interface to match the module's existing types and call style. Do not design a second interface in parallel.\n\nA fact you can read from code already opened is not a question. If the report's Solution and that code name the module, the methods to move, and what stays in the UI, edit now.\n\nStop and ask one question only when a behavior the candidate must change is neither stated in the report nor visible in the code you read. State the choice and a recommended default, then wait. Do not open a decision tree or a round of design questions before that.\n\nWhile editing:\n\n- **The deepened module needs a domain term `CONTEXT.md` does not already name?** Add that term. Create `CONTEXT.md` only in that case.\n- **The edit makes a fuzzy term in `CONTEXT.md` precise?** Update that term in the same edit.\n- **The user rejects a candidate for a reason a later review would need in order not to suggest it again?** Offer one ADR: _\"Want me to record this as an ADR so future architecture reviews don't re-suggest it?\"_ Skip \"not worth it right now\" and reasons that are obvious from the code.\n\nAfter the edit, run the check the repo already uses for those files (its test target or compiler command). Do not add a new test harness as a side task. If the repo has no such check, say so. The moved logic must be callable without presenting UI.\n",{"name":5,"description":7,"disable-model-invocation":46},true,"master","f542825aef4a5ca7e8c6c69d1f5b32fb325550ad","skills\u002Fimprove-codebase-architecture",0,"https:\u002F\u002Fgithub.com\u002FHeathWang\u002Fhw-cc-plugin","https:\u002F\u002Fgithub.com\u002FHeathWang","iOS \u002F front end \u002F python develper","2026-11-03 17:20:23",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":46},[57,60,63],{"tool":58,"command":59},"npx","npx skills add HeathWang\u002Fhw-cc-plugin --skill improve-codebase-architecture",{"tool":61,"command":62},"bunx","bunx skills add HeathWang\u002Fhw-cc-plugin --skill improve-codebase-architecture",{"tool":64,"command":65},"pnpm","pnpm dlx skills add HeathWang\u002Fhw-cc-plugin --skill improve-codebase-architecture","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FHeathWang\u002Fhw-cc-plugin\u002Fblob\u002Fmaster\u002Fskills\u002Fimprove-codebase-architecture\u002FSKILL.md",[68,74],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"agents\u002Fopenai.yaml","REFERENCE","参考文档",188,"https:\u002F\u002Fgithub.com\u002FHeathWang\u002Fhw-cc-plugin\u002Fblob\u002Fmaster\u002Fskills\u002Fimprove-codebase-architecture\u002Fagents\u002Fopenai.yaml",{"path":75,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":76,"sourceHtmlUrl":77},"HTML-REPORT.md",8234,"https:\u002F\u002Fgithub.com\u002FHeathWang\u002Fhw-cc-plugin\u002Fblob\u002Fmaster\u002Fskills\u002Fimprove-codebase-architecture\u002FHTML-REPORT.md",[79,110,128,138,150,166],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":90,"publishedAt":41},"01M6CFBEFHMPFRFM9AQAJVVAR0","reconstructing-ui-from-screenshots","Use when implementing or correcting an app or web UI from a design image, screenshot, mockup, or reference PNG where accurate size, spacing, color, typography, assets, and alignment matter.","https:\u002F\u002Fgithub.com\u002FHeathWang\u002Fhw-cc-plugin\u002Fblob\u002Fmaster\u002Fskills\u002Freconstructing-ui-from-screenshots\u002FSKILL.md",[85],{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[91,92,93,94,95,96,97,98,99,32,100,101,102,103,104,105,106,107,108,109],"screenshots","ui","reconstructing ui from screenshots","web","design","image","screenshot","png","assets","typography","reference","alignment","app","color","web ui","spacing","mockup","size","implementing",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":116,"publishedAt":41},"01M6CFBBT8EXTSBHXEFGRWRZ3C","question-answer","Use when the user wants a read-only explanation of existing code behavior, architecture, control flow, data flow, dependencies, or implementation decisions and has not requested project changes.","https:\u002F\u002Fgithub.com\u002FHeathWang\u002Fhw-cc-plugin\u002Fblob\u002Fmaster\u002Fskills\u002Fquestion-answer\u002FSKILL.md",[],[117,118,119,32,120,121,28,122,123,25,124,30,125,126,127],"question answer","question","only","webfetch","implementation","behavior","read","decisions","flow","data","grep",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":41},"01M6CFB60X8Q9479W73SJCDEVJ","java-to-swift","Use when converting Java 1.8 classes to Swift 5.0+ Codable structs - handling type mapping, nullability, inheritance flattening, BaseReq exclusions, and property naming conventions.","https:\u002F\u002Fgithub.com\u002FHeathWang\u002Fhw-cc-plugin\u002Fblob\u002Fmaster\u002Fskills\u002Fjava-to-swift\u002FSKILL.md",[],[135,136,137,127,123,32],"swift","java","java to swift",{"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":144,"publishedAt":41},"01M6CFB3DMRW02HSYWMMK3VDPM","java-to-nextjs","Use when converting Java 1.8 classes to Next.js TypeScript interface definitions - handling type mapping, nullability, inheritance, naming conventions, and BaseReq\u002FBaseResponse exclusions.","https:\u002F\u002Fgithub.com\u002FHeathWang\u002Fhw-cc-plugin\u002Fblob\u002Fmaster\u002Fskills\u002Fjava-to-nextjs\u002FSKILL.md",[],[145,136,146,147,148,149,127,123,32],"nextjs","java to nextjs","typescript","Next.js","js",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":159,"publishedAt":41},"01M6CFB055EXKR72703ST6H3XW","ios-i18n-workflow","Use when iOS apps using SwiftGen L10n need localization work - adding keys, checking missing translations, or cleaning unused entries. Triggered by hardcoded strings, missing L10n references, incomplete translations across multiple languages, or unused localization cleanup requests.","https:\u002F\u002Fgithub.com\u002FHeathWang\u002Fhw-cc-plugin\u002Fblob\u002Fmaster\u002Fskills\u002Fios-i18n-workflow\u002FSKILL.md",[156],{"categoryNo":157,"categoryName":158,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[160,161,162,32,163,164,165],"ios i18n workflow","ios","workflow","cleanup","work","references",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":41},"01M6CFATZXZK0RNE86AEN4AAH3","handoff","Use when the user asks to create a handoff, session summary, context compact, continuation note, 交接文档, 压缩上下文, or instructions for the next agent to resume work later.","https:\u002F\u002Fgithub.com\u002FHeathWang\u002Fhw-cc-plugin\u002Fblob\u002Fmaster\u002Fskills\u002Fhandoff\u002FSKILL.md",[],[168,173,174,175,176,164,177,178,28,179,32,180,181],"session summary","create","文档","压缩","context","instructions","session","resume","later"]