[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BV4ZACJP61C1DAR05KXHMP":3,"skill-same:01M6BV4ZACJP61C1DAR05KXHMP":69},{"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":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":14,"repositoryHtmlUrl":38,"repositoryHomepageUrl":6,"ownerHtmlUrl":39,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":40,"install":41,"resources":54},"01M6BV4ZACJP61C1DAR05KXHMP","connascence",null,"Assess coupling using the connascence taxonomy. Use when reviewing code for coupling issues, planning refactors, or when the user mentions 'connascence' or 'coupling'.","bnferguson\u002Fdotfiles","bnferguson","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F47749?v=4","01M6BV4H2TJKK8P14W86V1ZCPP","Brandon Ferguson","01M6BV4H7GJWTZJ1BVHQ1TX11Y",0,"MIT","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fconnascence\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29],"code","planning","issues","taxonomy","user","use","coupling","assess","reviewing code","for","when","2026-11-10 10:12:30",false,"---\nname: connascence\ndescription: \"Assess coupling using the connascence taxonomy. Use when reviewing code for coupling issues, planning refactors, or when the user mentions 'connascence' or 'coupling'.\"\n---\n\n# Connascence Analysis\n\n## Overview\n\nThis skill applies the connascence framework to assess coupling in code. Connascence gives a precise vocabulary for different kinds of coupling, ordered by strength, so you can make informed decisions about what to refactor and what to leave alone.\n\n## When to Use This Skill\n\n- User explicitly asks for connascence analysis\n- User asks about coupling, dependencies, or why something is hard to change\n- During code review when coupling patterns affect maintainability\n- When planning a refactor and you need to prioritize what to address\n- When evaluating a design decision that introduces new coupling\n\n## Setup\n\nLoad the reference material before analysis:\n\n```\nRead references\u002Ftaxonomy.md\nRead references\u002Frefactoring-guide.md\n```\n\n## Analysis Workflow\n\n### 1. Identify the Scope\n\nDetermine what you are analyzing:\n- A single file or class — look for internal connascence and connascence with direct dependencies\n- A module boundary or API surface — focus on what crosses the boundary\n- A PR diff — assess whether changes introduce stronger connascence or increase degree\n- A design proposal — evaluate what connascence the design would create\n\n### 2. Scan for Connascence\n\nWork from strongest to weakest — strong connascence crossing wide boundaries is the highest-value finding.\n\n**Priority order for findings:**\n\n| Priority | What to look for |\n|---|---|\n| Critical | Dynamic connascence (CoE, CoTm, CoV, CoI) crossing module\u002Fservice boundaries |\n| High | CoA (Algorithm) duplicated across modules or languages |\n| High | CoP (Position) in public APIs with many callers |\n| Medium | CoM (Meaning) — magic values, sentinel returns, implicit conventions |\n| Low | CoT, CoN within a module — usually acceptable |\n\n**Do not flag:**\n- CoN (Name) unless renaming would cascade across an unusual number of files\n- Any connascence that is purely internal to a small function or method\n- Connascence that is an inherent consequence of the language or framework (e.g., positional args in a language without keyword support)\n\n### 3. Measure with LSP\n\nWhen an LSP is available, use it to quantify degree and locality before assessing findings. This turns gut-feel estimates into concrete numbers.\n\n**Degree measurement:**\n- Use \"Find all references\" on the coupled symbol (method, constant, type) to count how many components depend on it. A function with CoP and 3 callers is different from one with 34 callers across 8 packages.\n- Use \"Type hierarchy\" to see how many implementations exist for an interface — this is the degree of CoN\u002FCoT on that contract.\n\n**Locality measurement:**\n- Use \"Call hierarchy\" (incoming) to see where callers live. If all callers are in the same package, locality is tight and the finding is less urgent. If they span modules or services, it's a boundary-crossing problem.\n\n**Rename testability:**\n- Use \"Rename symbol\" as a probe. If the LSP can handle the rename cleanly, CoN is mechanical and well-managed. If it can't (cross-language refs, string-based lookups, generated code), that signals the coupling is worse than it appears structurally.\n\nSkip this step when reviewing a single small file or a design proposal where the code doesn't exist yet.\n\n### 4. Assess Each Finding\n\nFor each instance worth reporting, note:\n\n- **Type** — which of the 9 forms (use the abbreviation: CoN, CoT, CoM, CoP, CoA, CoE, CoTm, CoV, CoI)\n- **Locality** — where the coupled components are relative to each other (same function, same class, same module, cross-module, cross-service). Use LSP call hierarchy data when available.\n- **Degree** — how many components are involved. Use LSP reference counts when available.\n- **Verdict** — acceptable (and why) or worth addressing (and why)\n\n### 5. Suggest Transformations\n\nFor findings worth addressing, consult `references\u002Frefactoring-guide.md` and suggest a specific transformation:\n\n- Name the target form (e.g., \"convert CoP → CoN by using keyword arguments\")\n- Show a concrete before\u002Fafter\n- Note if the transformation has tradeoffs (e.g., introducing a struct to eliminate CoP adds a type to maintain)\n\n### 6. Prioritize\n\nOrder recommendations by impact:\n1. Strong connascence crossing wide boundaries (fix first)\n2. High-degree connascence regardless of strength (many components affected)\n3. Connascence that is likely to cause bugs (especially dynamic forms)\n4. Connascence that makes the code hard to change (affects velocity)\n\n## Reporting Format\n\nStructure findings as:\n\n```\n## Connascence Assessment: [scope]\n\n### Findings\n\n#### [Finding title]\n- **Type:** CoX (Connascence of X)\n- **Strength:** [weak\u002Fmedium\u002Fstrong]\n- **Locality:** [within function \u002F within class \u002F cross-module \u002F cross-service]\n- **Degree:** [number of components involved]\n- **Assessment:** [acceptable \u002F worth addressing]\n\n[Brief explanation of what is coupled and why it matters or doesn't]\n\n[If worth addressing: suggested transformation with before\u002Fafter]\n\n### Summary\n\n[1-2 sentences: overall coupling health and top recommendation]\n```\n\n## Things to Remember\n\n- Connascence is a lens for prioritization, not a score to minimize. Some coupling is necessary and fine.\n- The locality corollary: acceptable strength decreases as distance increases. CoA within a class may be fine; CoA across services is a problem.\n- Dynamic connascence (CoE, CoTm, CoV, CoI) is inherently harder to reason about than static. Flag it even at close locality.\n- When analyzing a PR diff, focus on *changes* to connascence — did the PR introduce stronger coupling? Did it increase degree? That matters more than pre-existing coupling.\n- Be honest about the limits of static analysis for dynamic connascence types. You can identify *likely* CoTm from shared mutable state + concurrency, but you cannot be certain without runtime analysis.\n","# Connascence Analysis\n\n## Overview\n\nThis skill applies the connascence framework to assess coupling in code. Connascence gives a precise vocabulary for different kinds of coupling, ordered by strength, so you can make informed decisions about what to refactor and what to leave alone.\n\n## When to Use This Skill\n\n- User explicitly asks for connascence analysis\n- User asks about coupling, dependencies, or why something is hard to change\n- During code review when coupling patterns affect maintainability\n- When planning a refactor and you need to prioritize what to address\n- When evaluating a design decision that introduces new coupling\n\n## Setup\n\nLoad the reference material before analysis:\n\n```\nRead references\u002Ftaxonomy.md\nRead references\u002Frefactoring-guide.md\n```\n\n## Analysis Workflow\n\n### 1. Identify the Scope\n\nDetermine what you are analyzing:\n- A single file or class — look for internal connascence and connascence with direct dependencies\n- A module boundary or API surface — focus on what crosses the boundary\n- A PR diff — assess whether changes introduce stronger connascence or increase degree\n- A design proposal — evaluate what connascence the design would create\n\n### 2. Scan for Connascence\n\nWork from strongest to weakest — strong connascence crossing wide boundaries is the highest-value finding.\n\n**Priority order for findings:**\n\n| Priority | What to look for |\n|---|---|\n| Critical | Dynamic connascence (CoE, CoTm, CoV, CoI) crossing module\u002Fservice boundaries |\n| High | CoA (Algorithm) duplicated across modules or languages |\n| High | CoP (Position) in public APIs with many callers |\n| Medium | CoM (Meaning) — magic values, sentinel returns, implicit conventions |\n| Low | CoT, CoN within a module — usually acceptable |\n\n**Do not flag:**\n- CoN (Name) unless renaming would cascade across an unusual number of files\n- Any connascence that is purely internal to a small function or method\n- Connascence that is an inherent consequence of the language or framework (e.g., positional args in a language without keyword support)\n\n### 3. Measure with LSP\n\nWhen an LSP is available, use it to quantify degree and locality before assessing findings. This turns gut-feel estimates into concrete numbers.\n\n**Degree measurement:**\n- Use \"Find all references\" on the coupled symbol (method, constant, type) to count how many components depend on it. A function with CoP and 3 callers is different from one with 34 callers across 8 packages.\n- Use \"Type hierarchy\" to see how many implementations exist for an interface — this is the degree of CoN\u002FCoT on that contract.\n\n**Locality measurement:**\n- Use \"Call hierarchy\" (incoming) to see where callers live. If all callers are in the same package, locality is tight and the finding is less urgent. If they span modules or services, it's a boundary-crossing problem.\n\n**Rename testability:**\n- Use \"Rename symbol\" as a probe. If the LSP can handle the rename cleanly, CoN is mechanical and well-managed. If it can't (cross-language refs, string-based lookups, generated code), that signals the coupling is worse than it appears structurally.\n\nSkip this step when reviewing a single small file or a design proposal where the code doesn't exist yet.\n\n### 4. Assess Each Finding\n\nFor each instance worth reporting, note:\n\n- **Type** — which of the 9 forms (use the abbreviation: CoN, CoT, CoM, CoP, CoA, CoE, CoTm, CoV, CoI)\n- **Locality** — where the coupled components are relative to each other (same function, same class, same module, cross-module, cross-service). Use LSP call hierarchy data when available.\n- **Degree** — how many components are involved. Use LSP reference counts when available.\n- **Verdict** — acceptable (and why) or worth addressing (and why)\n\n### 5. Suggest Transformations\n\nFor findings worth addressing, consult `references\u002Frefactoring-guide.md` and suggest a specific transformation:\n\n- Name the target form (e.g., \"convert CoP → CoN by using keyword arguments\")\n- Show a concrete before\u002Fafter\n- Note if the transformation has tradeoffs (e.g., introducing a struct to eliminate CoP adds a type to maintain)\n\n### 6. Prioritize\n\nOrder recommendations by impact:\n1. Strong connascence crossing wide boundaries (fix first)\n2. High-degree connascence regardless of strength (many components affected)\n3. Connascence that is likely to cause bugs (especially dynamic forms)\n4. Connascence that makes the code hard to change (affects velocity)\n\n## Reporting Format\n\nStructure findings as:\n\n```\n## Connascence Assessment: [scope]\n\n### Findings\n\n#### [Finding title]\n- **Type:** CoX (Connascence of X)\n- **Strength:** [weak\u002Fmedium\u002Fstrong]\n- **Locality:** [within function \u002F within class \u002F cross-module \u002F cross-service]\n- **Degree:** [number of components involved]\n- **Assessment:** [acceptable \u002F worth addressing]\n\n[Brief explanation of what is coupled and why it matters or doesn't]\n\n[If worth addressing: suggested transformation with before\u002Fafter]\n\n### Summary\n\n[1-2 sentences: overall coupling health and top recommendation]\n```\n\n## Things to Remember\n\n- Connascence is a lens for prioritization, not a score to minimize. Some coupling is necessary and fine.\n- The locality corollary: acceptable strength decreases as distance increases. CoA within a class may be fine; CoA across services is a problem.\n- Dynamic connascence (CoE, CoTm, CoV, CoI) is inherently harder to reason about than static. Flag it even at close locality.\n- When analyzing a PR diff, focus on *changes* to connascence — did the PR introduce stronger coupling? Did it increase degree? That matters more than pre-existing coupling.\n- Be honest about the limits of static analysis for dynamic connascence types. You can identify *likely* CoTm from shared mutable state + concurrency, but you cannot be certain without runtime analysis.\n",{"name":5,"description":7},"main","e63965e4644984470d4cc8b3014a8b001f0c2666",".agents\u002Fskills\u002Fconnascence","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles","https:\u002F\u002Fgithub.com\u002Fbnferguson","2026-11-11 03:04:59",{"source":8,"skillName":5,"commands":42,"prompt":52,"zipAvailable":53},[43,46,49],{"tool":44,"command":45},"npx","npx skills add bnferguson\u002Fdotfiles --skill connascence",{"tool":47,"command":48},"bunx","bunx skills add bnferguson\u002Fdotfiles --skill connascence",{"tool":50,"command":51},"pnpm","pnpm dlx skills add bnferguson\u002Fdotfiles --skill connascence","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fconnascence\u002FSKILL.md",true,[55,61,65],{"path":56,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":59,"sourceHtmlUrl":60},"REFERENCE.md","REFERENCE","参考文档",7400,"https:\u002F\u002Fgithub.com\u002Flaurigates\u002Fclaude-plugins\u002Fblob\u002Fmain\u002Fkubernetes-plugin\u002Fskills\u002Fhelm-release-management\u002FREFERENCE.md",{"path":62,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":63,"sourceHtmlUrl":64},"references\u002Frefactoring-guide.md",7866,"https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fconnascence\u002Freferences\u002Frefactoring-guide.md",{"path":66,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":67,"sourceHtmlUrl":68},"references\u002Ftaxonomy.md",12568,"https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fconnascence\u002Freferences\u002Ftaxonomy.md",[70,101,118,148,157,170],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":74,"licenseFileUrl":75,"sourceHtmlUrl":76,"categories":77,"keywords":83,"publishedAt":30},"01M6BVA3RS3M016FANZ6792F9H","skill-creator","Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002Fclaude\u002Fconfig\u002Fskills\u002Fskill-creator\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002Fclaude\u002Fconfig\u002Fskills\u002Fskill-creator\u002FSKILL.md",[78],{"categoryNo":79,"categoryName":80,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,28,99,29,100],"creator","skill creator","specialized","workflows","create","update","capabilities","knowledge","tool","integrations","guide","new skill","existing skill","users","with","Existing","new",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":115,"publishedAt":30},"01M6BV94WN2RPYM8N6PN8TBNT8","writing-shape","Writing, exploit: shape raw material into an article, paragraph by paragraph.","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwriting-shape\u002FSKILL.md",[107,110],{"categoryNo":108,"categoryName":109,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":111,"categoryName":112,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[116,117],"writing shape","writing",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":74,"licenseFileUrl":122,"sourceHtmlUrl":123,"categories":124,"keywords":131,"publishedAt":30},"01M6BV8QDFJ6PXBVK5NFBZT5M7","webapp-testing","Test local web applications using Playwright. Use when verifying frontend functionality, debugging UI behavior, capturing browser screenshots, or viewing browser logs.","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[125,128],{"categoryNo":126,"categoryName":127,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":129,"categoryName":130,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000009","前端开发",[132,133,134,135,136,137,138,139,140,141,142,143,144,145,24,146,147,29],"webapp","webapp testing","testing","browser","frontend","screenshots","playwright","test","web","debugging","ui","logs","applications","behavior","local","test local",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":30},"01M6BV8MDXKXNVHKS3QF3YDFTF","wait-what","Stop. That last message did not land: re-pitch it.","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwait-what\u002FSKILL.md",[],[155,156],"wait what","land",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":166,"publishedAt":30},"01M6BV756DJHT5BDA1HVRVHJJ7","prototype","Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fprototype\u002FSKILL.md",[163],{"categoryNo":164,"categoryName":165,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000032","设计师",[159,167,168,142,169],"design","explore","state",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":177,"publishedAt":30},"01M6BV6SBW166685KVBPWM2K4N","improve-codebase-architecture","Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fimprove-codebase-architecture\u002FSKILL.md",[176],{"categoryNo":129,"categoryName":130,"taxonomyType":81,"taxonomyTypeDesc":82},[178,179,180,181],"architecture","improve","improve codebase architecture","report"]