[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DATXSSPP40B5A30HF3VVEA":3,"skill-same:01M6DATXSSPP40B5A30HF3VVEA":66},{"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":17,"publishedAt":29,"linkOnly":30,"markdownContent":31,"markdownBody":32,"frontMatter":33,"refName":40,"commitSha":41,"skillDirectory":42,"forksCount":13,"repositoryHtmlUrl":43,"repositoryHomepageUrl":6,"ownerHtmlUrl":44,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":45,"install":46,"resources":59},"01M6DATXSSPP40B5A30HF3VVEA","dependency-hygiene",null,"Use when auditing or designing module boundaries and dependency chains — dependency direction, layering, cycles, public surface area, and third-party dependency admission or upgrades — in a codebase, package, or proposed change.","tzeusy-org\u002Fai-bootstrap","tzeusy-org","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F141543652?v=4","01M6DAM1AP09H27BYGFY9QCNPB","01M6DAM1F4R187EK11XDN9JZKH",0,"MIT","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Fdependency-hygiene\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28],"dependency","hygiene","dependency hygiene","change","package","public","upgrades","use","active","third-party","module","2026-11-10 10:12:30",false,"---\nname: dependency-hygiene\ndescription: >\n  Use when auditing or designing module boundaries and dependency chains — dependency\n  direction, layering, cycles, public surface area, and third-party dependency\n  admission or upgrades — in a codebase, package, or proposed change.\nmetadata:\n  owner: tze\n  authors:\n    - tze\n    - Claude Fable 5\n  status: active\n  last_reviewed: \"2026-06-12\"\n---\n\n# Dependency Hygiene\n\nArchitecture is mostly the shape of the dependency graph. This subskill keeps\nthat graph legible: dependencies point one way, modules expose less than they\ncontain, every third-party package pays rent.\n\n## Use This Skill When\n\n- Auditing a codebase's import\u002Fmodule structure (\"untangle these dependencies\")\n- A change adds an import that feels like it points the wrong way\n- Deciding whether to admit a new third-party dependency or upgrade one\n- Carving a module boundary: what is public, what is internal\n- Cycles, god-modules, or \"everything imports utils\" complaints\n\n## Do Not Use This Skill For\n\n- Within-function clarity — [code-readability](..\u002Fcode-readability\u002FSKILL.md)\n- Retired-interface leftovers — [cruft-cleanup](..\u002Fcruft-cleanup\u002FSKILL.md)\n- Repo-wide topology documentation (lay-and-land pillar) — `\u002Fth-projects`\n\n## Core Rule\n\n**Dependencies point from less stable to more stable, never back.**\nPolicy depends on mechanism, callers depend on interfaces, leaves depend on\ncore. Any edge pointing the other way — and any cycle, which is both\ndirections at once — is a finding regardless of whether the code currently\nworks.\n\n## The Bar\n\nReviewable expectations — cite the one violated, with module\u002Fimport evidence:\n\n1. **One direction per layer boundary** — Name the layers the project implies\n   (e.g. domain ← application ← interface\u002Finfra); verify every import\n   crosses boundaries in the sanctioned direction. Invert upward imports\n   via an interface owned by the lower layer, never wave them through.\n2. **No cycles, at any granularity** — Module- or package-level cycles\n   make units untestable in isolation and changes non-local. Break them by\n   extracting the shared piece downward or inverting one edge; never by\n   deferring imports inside functions to hide the cycle from tooling.\n3. **Public surface is deliberate and minimal** — A module exports what its\n   contract promises, not whatever happens to be defined. Reaching into\n   another module's internals (deep imports, private-by-convention access)\n   couples to accidents. Shrinking surface beats documenting it.\n4. **No god-modules** — A `utils`\u002F`common`\u002F`helpers` that everything imports\n   becomes a cycle hub and change magnet. Split by domain; a helper used by\n   one consumer moves to that consumer.\n5. **Third-party dependencies pay rent** — Admitting a package is an\n   ownership decision: you adopt its security surface, upgrade cadence,\n   transitive tree. Before adding one, state what it saves over ~50 lines of\n   owned code, check maintenance health, prefer the standard library.\n   Wrap volatile or heavy dependencies behind an owned interface at the\n   boundary so they stay replaceable; don't wrap stable, idiomatic ones.\n   For seam placement by dependency category, the deletion test, and the\n   test strategy per category, read\n   [`references\u002Fseams-and-dependencies.md`](.\u002Freferences\u002Fseams-and-dependencies.md).\n6. **Versions are pinned, upgrades are deliberate** — Commit lockfiles;\n   make each upgrade its own reviewed change with the changelog read,\n   not a side effect of unrelated work. Record new dependencies\n   wherever the host project documents them (for example, the dotfiles repo\n   that ships this skill uses a `DEPENDENCIES.md`).\n7. **Test\u002Fdev dependencies stay out of production chains** — Fixtures,\n   fakes, and tooling must not be importable from shipped code paths.\n\n## Workflow\n\n1. Map before judging: extract the actual import graph (language tooling, or\n   `rg`\u002F`grep` over import statements) for the scope under review. For audits,\n   render the module graph — `..\u002Fexcalidraw-diagram\u002FSKILL.md` if available,\n   otherwise Mermaid — so direction violations are visible, not asserted.\n2. Establish intended direction: from the project's stated layering\n   (lay-and-land docs, README) or, absent that, from stability — what changes\n   most often must depend on what changes least.\n3. Walk the edges: flag wrong-direction imports (1), cycles (2), deep\n   imports (3), god-module fan-in (4). For each, propose the concrete\n   inversion or extraction, smallest first. Judge suspect wrappers and\n   layers with the deletion test\n   ([`references\u002Fseams-and-dependencies.md`](.\u002Freferences\u002Fseams-and-dependencies.md)).\n4. For each third-party package in scope, apply the rent test (5); check\n   pinning\u002Frecording (6) and test\u002Fprod separation (7).\n5. Apply small in-scope fixes (move a helper, narrow an export, pin a\n   version) directly; structural inversions get a sequenced proposal with\n   the cycle-breaking step first.\n\n## Trigger Sanity Check\n\n- Should trigger: \"core imports the HTTP layer and I can't test it alone — untangle this.\"\n- Should trigger: \"should we pull in this package or write the ~40 lines ourselves?\"\n- Should trigger: \"everything imports `utils` and every change touches it — is that fine?\"\n- Should not trigger: \"Rename these variables\" or \"update the lockfile after CI told us to.\"\n","# Dependency Hygiene\n\nArchitecture is mostly the shape of the dependency graph. This subskill keeps\nthat graph legible: dependencies point one way, modules expose less than they\ncontain, every third-party package pays rent.\n\n## Use This Skill When\n\n- Auditing a codebase's import\u002Fmodule structure (\"untangle these dependencies\")\n- A change adds an import that feels like it points the wrong way\n- Deciding whether to admit a new third-party dependency or upgrade one\n- Carving a module boundary: what is public, what is internal\n- Cycles, god-modules, or \"everything imports utils\" complaints\n\n## Do Not Use This Skill For\n\n- Within-function clarity — [code-readability](..\u002Fcode-readability\u002FSKILL.md)\n- Retired-interface leftovers — [cruft-cleanup](..\u002Fcruft-cleanup\u002FSKILL.md)\n- Repo-wide topology documentation (lay-and-land pillar) — `\u002Fth-projects`\n\n## Core Rule\n\n**Dependencies point from less stable to more stable, never back.**\nPolicy depends on mechanism, callers depend on interfaces, leaves depend on\ncore. Any edge pointing the other way — and any cycle, which is both\ndirections at once — is a finding regardless of whether the code currently\nworks.\n\n## The Bar\n\nReviewable expectations — cite the one violated, with module\u002Fimport evidence:\n\n1. **One direction per layer boundary** — Name the layers the project implies\n   (e.g. domain ← application ← interface\u002Finfra); verify every import\n   crosses boundaries in the sanctioned direction. Invert upward imports\n   via an interface owned by the lower layer, never wave them through.\n2. **No cycles, at any granularity** — Module- or package-level cycles\n   make units untestable in isolation and changes non-local. Break them by\n   extracting the shared piece downward or inverting one edge; never by\n   deferring imports inside functions to hide the cycle from tooling.\n3. **Public surface is deliberate and minimal** — A module exports what its\n   contract promises, not whatever happens to be defined. Reaching into\n   another module's internals (deep imports, private-by-convention access)\n   couples to accidents. Shrinking surface beats documenting it.\n4. **No god-modules** — A `utils`\u002F`common`\u002F`helpers` that everything imports\n   becomes a cycle hub and change magnet. Split by domain; a helper used by\n   one consumer moves to that consumer.\n5. **Third-party dependencies pay rent** — Admitting a package is an\n   ownership decision: you adopt its security surface, upgrade cadence,\n   transitive tree. Before adding one, state what it saves over ~50 lines of\n   owned code, check maintenance health, prefer the standard library.\n   Wrap volatile or heavy dependencies behind an owned interface at the\n   boundary so they stay replaceable; don't wrap stable, idiomatic ones.\n   For seam placement by dependency category, the deletion test, and the\n   test strategy per category, read\n   [`references\u002Fseams-and-dependencies.md`](.\u002Freferences\u002Fseams-and-dependencies.md).\n6. **Versions are pinned, upgrades are deliberate** — Commit lockfiles;\n   make each upgrade its own reviewed change with the changelog read,\n   not a side effect of unrelated work. Record new dependencies\n   wherever the host project documents them (for example, the dotfiles repo\n   that ships this skill uses a `DEPENDENCIES.md`).\n7. **Test\u002Fdev dependencies stay out of production chains** — Fixtures,\n   fakes, and tooling must not be importable from shipped code paths.\n\n## Workflow\n\n1. Map before judging: extract the actual import graph (language tooling, or\n   `rg`\u002F`grep` over import statements) for the scope under review. For audits,\n   render the module graph — `..\u002Fexcalidraw-diagram\u002FSKILL.md` if available,\n   otherwise Mermaid — so direction violations are visible, not asserted.\n2. Establish intended direction: from the project's stated layering\n   (lay-and-land docs, README) or, absent that, from stability — what changes\n   most often must depend on what changes least.\n3. Walk the edges: flag wrong-direction imports (1), cycles (2), deep\n   imports (3), god-module fan-in (4). For each, propose the concrete\n   inversion or extraction, smallest first. Judge suspect wrappers and\n   layers with the deletion test\n   ([`references\u002Fseams-and-dependencies.md`](.\u002Freferences\u002Fseams-and-dependencies.md)).\n4. For each third-party package in scope, apply the rent test (5); check\n   pinning\u002Frecording (6) and test\u002Fprod separation (7).\n5. Apply small in-scope fixes (move a helper, narrow an export, pin a\n   version) directly; structural inversions get a sequenced proposal with\n   the cycle-breaking step first.\n\n## Trigger Sanity Check\n\n- Should trigger: \"core imports the HTTP layer and I can't test it alone — untangle this.\"\n- Should trigger: \"should we pull in this package or write the ~40 lines ourselves?\"\n- Should trigger: \"everything imports `utils` and every change touches it — is that fine?\"\n- Should not trigger: \"Rename these variables\" or \"update the lockfile after CI told us to.\"\n",{"name":5,"metadata":34,"description":39},{"owner":35,"status":26,"authors":36,"last_reviewed":38},"tze",[35,37],"Claude Fable 5","2026-06-12","Use when auditing or designing module boundaries and dependency chains — dependency direction, layering, cycles, public surface area, and third-party dependency admission or upgrades — in a codebase, package, or proposed change.\n","main","c907d6f0bf96bd61b936e8972e0f1c66ebb8148c","skills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Fdependency-hygiene","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap","https:\u002F\u002Fgithub.com\u002Ftzeusy-org","2026-11-10 23:17:25",{"source":8,"skillName":5,"commands":47,"prompt":57,"zipAvailable":58},[48,51,54],{"tool":49,"command":50},"npx","npx skills add tzeusy-org\u002Fai-bootstrap --skill dependency-hygiene",{"tool":52,"command":53},"bunx","bunx skills add tzeusy-org\u002Fai-bootstrap --skill dependency-hygiene",{"tool":55,"command":56},"pnpm","pnpm dlx skills add tzeusy-org\u002Fai-bootstrap --skill dependency-hygiene","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Fdependency-hygiene\u002FSKILL.md",true,[60],{"path":61,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":64,"sourceHtmlUrl":65},"references\u002Fseams-and-dependencies.md","REFERENCE","参考文档",3085,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Fdependency-hygiene\u002Freferences\u002Fseams-and-dependencies.md",[67,92,119,134,153,164],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":29},"01M6DAZD21TWH2ET70V9FF75CQ","user-run","Use when a step needs privileges this session lacks (docker, sudo, another user's checkout or secrets, host access) and the owner must run it as tze. Writes a reviewable \u002Fhome\u002Forca\u002F.tmp\u002F\u003Cslug>\u002Frun.sh that impersonates tze (USER_TO_IMPERSONATE overrides), tees timestamped logs plus latest.log and collects artifacts there; Claude presents it with a risk and time brief, then continues from the logs. Triggers: \"I'll run it for you\", \"permission denied on docker.sock\", \"needs sudo\", \"sudo: a password is required\", \"run as tze\", \"\u002Fuser-run\".","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fuser-run\u002FSKILL.md",[],[74,75,76,77,78,25,79,80,81,82,26,83,84,85,86,87,88,89,90,91],"user run","user","run","docker","logs","host","as","triggers","permission","time","log","artifacts","session","password","access","secrets","risk","brief",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":108,"publishedAt":29},"01M6DAZAHTCBAD2WF0GAHWPST8","requesting-code-review","Use when completing tasks, implementing major features, or before merging to verify work meets requirements","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Frequesting-code-review\u002FSKILL.md",[98,103],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[109,110,111,112,113,114,26,115,116,25,117,118],"requesting code review","code","review","code review","work","requirements","upstream","superpowers","verify","tasks",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":127,"publishedAt":29},"01M6DAZ7CJ82D81XZB2YHVVY48","receiving-code-review","Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Freceiving-code-review\u002FSKILL.md",[125,126],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},[128,110,111,112,26,115,129,116,25,130,131,132,133],"receiving code review","implementation","code review feedback","technical","feedback","verification",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":29},"01M6DAZ4ER76ADXJ9KRFP7V3Q9","finishing-a-development-branch","Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Ffinishing-a-development-branch\u002FSKILL.md",[],[141,142,143,144,25,145,113,146,147,148,116,149,150,151,26,115,152,129],"branch","development","finishing a development branch","integrate","decide","how","cleanup","pr","merge","tests","structured","options",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":29},"01M6DAYZFWWW2YPKP89QNQR96H","executing-plans","Use when you have a written implementation plan to execute in a separate session with review checkpoints","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Fexecuting-plans\u002FSKILL.md",[],[160,161,162,111,163,26,115,129,116,25,86],"plans","executing plans","plan","execute",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":170,"publishedAt":29},"01M6DAYWM2YQHYCK7C35K1D29J","dispatching-parallel-agents","Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Fdispatching-parallel-agents\u002FSKILL.md",[],[171,172,173,25,116,115,174,26,175,118,176],"parallel agents","parallel","dispatching parallel agents","state","dependencies","shared"]