[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CDAEB3EZ86CQSYM28J34ZS":3,"skill-same:01M6CDAEB3EZ86CQSYM28J34ZS":102},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":53,"updatedAt":54,"install":55,"resources":67},"01M6CDAEB3EZ86CQSYM28J34ZS","pdf-processing",null,"Extract PDF text, fill forms, merge files. Use when handling PDFs.","mrwogu\u002Fpromptscript","mrwogu","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2917861?v=4","01M6CD988FG8NZ7SGMM9JG76Y7","Wojciech Guziak","01M6CD98C8MZJE9HW7P95CYB3S",344,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmrwogu\u002Fpromptscript\u002Fblob\u002Fmain\u002Fpackages\u002Fformatters\u002Fsrc\u002F__tests__\u002Ffixtures\u002Fplatform-contracts\u002Fgemini\u002Fskill.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37],"PDF","pdf processing","processing","merge","text","extract","use","example","files","forms","extract pdf","org","fill","when","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":43,"description":44,"disable-model-invocation":45},"improve-codebase-architecture","Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.",true,"main","dc4098a7dc9add9d1941b997a10367e6af940231","packages\u002Fformatters\u002Fsrc\u002F__tests__\u002Ffixtures\u002Fplatform-contracts\u002Fgemini",7,"https:\u002F\u002Fgithub.com\u002Fmrwogu\u002Fpromptscript","https:\u002F\u002Fgetpromptscript.dev\u002F","https:\u002F\u002Fgithub.com\u002Fmrwogu","AI Developer Experience","2026-11-09 13:55:29",{"source":8,"skillName":43,"commands":56,"prompt":66,"zipAvailable":45},[57,60,63],{"tool":58,"command":59},"npx","npx skills add mrwogu\u002Fpromptscript --skill improve-codebase-architecture",{"tool":61,"command":62},"bunx","bunx skills add mrwogu\u002Fpromptscript --skill improve-codebase-architecture",{"tool":64,"command":65},"pnpm","pnpm dlx skills add mrwogu\u002Fpromptscript --skill improve-codebase-architecture","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmrwogu\u002Fpromptscript\u002Fblob\u002Fmain\u002Fpackages\u002Fformatters\u002Fsrc\u002F__tests__\u002Ffixtures\u002Fplatform-contracts\u002Fgemini\u002Fskill.md",[68,74,78,82,86,90,94,98],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"agents-skills.md","REFERENCE","参考文档",1145,"https:\u002F\u002Fgithub.com\u002Fmrwogu\u002Fpromptscript\u002Fblob\u002Fmain\u002Fpackages\u002Fformatters\u002Fsrc\u002F__tests__\u002Ffixtures\u002Fplatform-contracts\u002Fgemini\u002Fagents-skills.md",{"path":75,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":76,"sourceHtmlUrl":77},"gemini-md.md",800,"https:\u002F\u002Fgithub.com\u002Fmrwogu\u002Fpromptscript\u002Fblob\u002Fmain\u002Fpackages\u002Fformatters\u002Fsrc\u002F__tests__\u002Ffixtures\u002Fplatform-contracts\u002Fgemini\u002Fgemini-md.md",{"path":79,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":80,"sourceHtmlUrl":81},"INDEX.md",3173,"https:\u002F\u002Fgithub.com\u002Fmrwogu\u002Fpromptscript\u002Fblob\u002Fmain\u002Fpackages\u002Fformatters\u002Fsrc\u002F__tests__\u002Ffixtures\u002Fplatform-contracts\u002Fgemini\u002FINDEX.md",{"path":83,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002FDEEPENING.md",2565,"https:\u002F\u002Fgithub.com\u002FRyanParsley\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fimprove-codebase-architecture\u002Freferences\u002FDEEPENING.md",{"path":87,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002FINTERFACE-DESIGN.md",2725,"https:\u002F\u002Fgithub.com\u002FRyanParsley\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fimprove-codebase-architecture\u002Freferences\u002FINTERFACE-DESIGN.md",{"path":91,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002FLANGUAGE.md",3804,"https:\u002F\u002Fgithub.com\u002FRyanParsley\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fimprove-codebase-architecture\u002Freferences\u002FLANGUAGE.md",{"path":95,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":96,"sourceHtmlUrl":97},"runtime-commands.md",619,"https:\u002F\u002Fgithub.com\u002Fmrwogu\u002Fpromptscript\u002Fblob\u002Fmain\u002Fpackages\u002Fformatters\u002Fsrc\u002F__tests__\u002Ffixtures\u002Fplatform-contracts\u002Fgemini\u002Fruntime-commands.md",{"path":99,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":100,"sourceHtmlUrl":101},"settings-hooks.json",295,"https:\u002F\u002Fgithub.com\u002Fmrwogu\u002Fpromptscript\u002Fblob\u002Fmain\u002Fpackages\u002Fformatters\u002Fsrc\u002F__tests__\u002Ffixtures\u002Fplatform-contracts\u002Fgemini\u002Fsettings-hooks.json",[103,136,145,161,169,191],{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":107,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":118,"publishedAt":38},"01M6CDARG1R0SC1QS30MG6NH4Z","promptscript","PromptScript language expert for reading, writing, modifying, and troubleshooting .prs files. Use when working with PromptScript syntax, creating or editing .prs files, adding blocks like @identity, @standards, @restrictions, @shortcuts, @skills, or @agents, configuring promptscript.yaml, resolving compilation errors, understanding inheritance (@inherit), composition (@use, @extend, @override), contextual @header metadata, or migrating AI instructions to PromptScript. Also use when asked about the 50 built-in coding agent compilation targets, including GitHub Copilot, Claude Code, Cursor, Antigravity, Factory AI, and AGENTS.md-based platforms, or about the bundle and prompt-text targets for application prompts.","MIT","https:\u002F\u002Fgithub.com\u002Fmrwogu\u002Fpromptscript\u002Fblob\u002Fmain\u002Fskills\u002Fpromptscript\u002FSKILL.md",[110,113],{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":114,"categoryName":115,"taxonomyType":116,"taxonomyTypeDesc":117},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[105,119,120,32,121,28,122,123,124,125,126,127,128,129,130,131,132,133,134,135],"standards","Composition","writing","read","write","coding","identity","gemini","expert","kiro-cli","inheritance","windsurf","kilo","reading","factory-ai","goose","for",{"skillNo":137,"name":127,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":107,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":141,"publishedAt":38},"01M6CDANHZWNCXCKZQSGVZW8S8","Base expert skill","https:\u002F\u002Fgithub.com\u002Fmrwogu\u002Fpromptscript\u002Fblob\u002Fmain\u002Fpackages\u002Fresolver\u002Fsrc\u002F__tests__\u002F__fixtures__\u002Fskill-references\u002Fskills\u002Fexpert\u002FSKILL.md",[],[127,142,143,144],"spring","references","base",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":107,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":152,"publishedAt":38},"01M6CDAK4J08AXZ8ZKX9VWP9NE","tdd-workflow","Test-driven development workflow","https:\u002F\u002Fgithub.com\u002Fmrwogu\u002Fpromptscript\u002Fblob\u002Fmain\u002Fpackages\u002Fresolver\u002Fsrc\u002F__tests__\u002F__fixtures__\u002Fregistry\u002Fnative-skills\u002Ftdd-workflow\u002FSKILL.md",[151],{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},[153,154,155,156,157,158,159,160],"tdd workflow","tdd","workflow","development","development workflow","test","test-driven","driven",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":107,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"publishedAt":38},"01M6CDAGQMZ3SZP69Q1XREEX48","alpha","Alpha skill","https:\u002F\u002Fgithub.com\u002Fmrwogu\u002Fpromptscript\u002Fblob\u002Fmain\u002Fpackages\u002Fresolver\u002Fsrc\u002F__tests__\u002F__fixtures__\u002Fmd-imports\u002Fskill-dir\u002Falpha\u002FSKILL.md",[],[163,168],"alpha skill",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":107,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":178,"publishedAt":38},"01M6CDABP7FSQ9BY079P1QWJR2","react-component-patterns","Conventions for writing React components in this codebase.","https:\u002F\u002Fgithub.com\u002Fmrwogu\u002Fpromptscript\u002Fblob\u002Fmain\u002Fpackages\u002Fformatters\u002Fsrc\u002F__tests__\u002Ffixtures\u002Fplatform-contracts\u002Fcursor\u002Fskill.md",[175],{"categoryNo":176,"categoryName":177,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[179,180,181,182,183,184,185,121,186,187,188,189,135,190],"patterns","react component","component","react","react component patterns","conventions","tsx","components","react components","packages","ui","codebase",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":107,"licenseFileUrl":6,"sourceHtmlUrl":195,"categories":196,"keywords":201,"publishedAt":38},"01M6CDA8P4H25QD7EPHBJQCEEV","deploy-app","Deploy the application to staging or production environments. Use when deploying code or when the user mentions deployment, releases, or environments.","https:\u002F\u002Fgithub.com\u002Fmrwogu\u002Fpromptscript\u002Fblob\u002Fmain\u002Fpackages\u002Fformatters\u002Fsrc\u002F__tests__\u002Ffixtures\u002Fplatform-contracts\u002Fcodex\u002Fskill.md",[197,200],{"categoryNo":198,"categoryName":199,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":114,"categoryName":115,"taxonomyType":116,"taxonomyTypeDesc":117},[202,203,204,205,206,37,207,208,209,210,211,30],"deploy","deploy app","app","deployment","environments","user","application","Production","releases","code"]