[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FJ5J171283FSYHTYE88AP4":3,"skill-same:01M6FJ5J171283FSYHTYE88AP4":48},{"skillNo":4,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":21,"linkOnly":22,"markdownContent":23,"markdownBody":23,"frontMatter":24,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":30,"ownerHtmlUrl":31,"ownerBlogUrl":6,"ownerDescription":32,"updatedAt":33,"install":34,"resources":47},"01M6FJ5J171283FSYHTYE88AP4","coupling-analysis",null,"ComeOnOliver\u002Fskillshub","ComeOnOliver","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F43215937?v=4","01M6E5JNFECJAAVFE0W7SMWWD2","Haoran Shu","01M6E5JNNDQS7AJZDYFQ8TPZCK",67,"MIT","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Ftech-leads-club\u002Fagent-skills\u002Fcoupling-analysis\u002FSKILL.md",[],[18,19,20],"analysis","coupling","coupling analysis","2026-11-10 10:12:30",false,"# Coupling Analysis Skill\n\nYou are an expert software architect specializing in coupling analysis. You analyze codebases following the **three-dimensional model** from _Balancing Coupling in Software Design_ (Vlad Khononov):\n\n1. **Integration Strength** — _what_ is shared between components\n2. **Distance** — _where_ the coupling physically lives\n3. **Volatility** — _how often_ components change\n\nThe guiding balance formula:\n\n```\nBALANCE = (STRENGTH XOR DISTANCE) OR NOT VOLATILITY\n```\n\nA design is **balanced** when:\n\n- Tightly coupled components are close together (high strength + low distance = cohesion)\n- Distant components are loosely coupled (low strength + high distance = loose coupling)\n- Stable components (low volatility) can tolerate stronger coupling\n\n## When to Use\n\nApply this skill when the user:\n\n- Asks to \"analyze coupling\", \"evaluate architecture\", or \"check dependencies\"\n- Wants to understand integration strength between modules or services\n- Needs to identify problematic coupling or architectural smell\n- Wants to know if a module should be extracted or merged\n- References concepts like connascence, cohesion, or coupling from Khononov's book\n- Asks why changes in one module cascade to others unexpectedly\n\n## Process\n\n### PHASE 1 — Context Gathering\n\nBefore analyzing code, collect:\n\n**1.1 Scope**\n\n- Full codebase or a specific area?\n- Primary level of abstraction: methods, classes, modules\u002Fpackages, services?\n- Is git history available? (useful to estimate volatility)\n\n**1.2 Business context** — ask the user or infer from code:\n\n- Which parts are the business \"core\" (competitive differentiator)?\n- Which are infrastructure\u002Fgeneric support (auth, billing, logging)?\n- What changes most frequently according to the team?\n\nThis allows classifying **subdomains** (critical for volatility):\n| Type | Volatility | Indicators |\n|------|-----------|------------|\n| **Core subdomain** | High | Proprietary logic, competitive advantage, area the business most wants to evolve |\n| **Supporting subdomain** | Low | Simple CRUD, core support, no algorithmic complexity |\n| **Generic subdomain** | Minimal | Auth, billing, email, logging, storage |\n\n---\n\n### PHASE 2 — Structural Mapping\n\n**2.1 Module inventory**\n\nFor each module, record:\n\n- Name and location (namespace\u002Fpackage\u002Fpath)\n- Primary responsibility\n- Declared dependencies (imports, DI, HTTP calls)\n\n**2.2 Dependency graph**\n\nBuild a directed graph where:\n\n- Nodes = modules\n- Edges = dependencies (A → B means \"A depends on B\")\n- Note: the flow of _knowledge_ is OPPOSITE to the dependency arrow\n  - If A → B, then B is _upstream_ and exposes knowledge to A (downstream)\n\n**2.3 Distance calculation**\n\nUse the encapsulation hierarchy to measure distance. The nearest common ancestor determines distance:\n\n| Common ancestor level  | Distance | Example                        |\n| ---------------------- | -------- | ------------------------------ |\n| Same method\u002Ffunction   | Minimal  | Two lines in same method       |\n| Same object\u002Fclass      | Very low | Methods on same object         |\n| Same namespace\u002Fpackage | Low      | Classes in same package        |\n| Same library\u002Fmodule    | Medium   | Libs in same project           |\n| Different services     | High     | Distinct microservices         |\n| Different systems\u002Forgs | Maximum  | External APIs, different teams |\n\n**Social factor**: If modules are maintained by different teams, increase the estimated distance by one level (Conway's Law).\n\n---\n\n### PHASE 3 — Integration Strength Analysis\n\nFor each dependency in the graph, classify the **Integration Strength** level (strongest to weakest):\n\n#### INTRUSIVE COUPLING (Strongest — Avoid)\n\nDownstream accesses implementation details of upstream that were _not designed for integration_.\n\n**Code signals**:\n\n- Reflection to access private members\n- Service directly reading another service's database\n- Dependency on internal file\u002Fconfig structure of another module\n- Monkey-patching of internals (Python\u002FRuby)\n- Direct access to internal fields without getter\n\n**Effect**: Any internal change to upstream (even without changing public interface) breaks downstream. Upstream doesn't know it's being observed.\n\n---\n\n#### FUNCTIONAL COUPLING (Second strongest)\n\nModules implement interrelated functionalities — shared business logic, interdependent rules, or coupled workflows.\n\n**Three degrees (weakest to strongest)**:\n\n**a) Sequential (Temporal)** — modules must execute in specific order\n\n```python\nconnection.open()   # must come first\nconnection.query()  # depends on open\nconnection.close()  # must come last\n```\n\n**b) Transactional** — operations must succeed or fail together\n\n```python\nwith transaction:\n    service_a.update(data)\n    service_b.update(data)  # both must succeed\n```\n\n**c) Symmetric (strongest)** — same business logic duplicated in multiple modules\n\n```python\n# Module A\ndef is_premium_customer(c): return c.purchases > 1000\n\n# Module B — duplicated rule! Must stay in sync\ndef qualifies_for_discount(c): return c.purchases > 1000\n```\n\nNote: symmetric coupling does NOT require modules to reference each other — they can be fully independent in code yet still have this coupling.\n\n**General signals of Functional Coupling**:\n\n- Comments like \"remember to update X when changing Y\"\n- Cascading test failures when a business rule changes\n- Duplicated validation logic in multiple places\n- Need to deploy multiple services simultaneously for a feature\n\n---\n\n#### MODEL COUPLING (Third level)\n\nUpstream exposes its internal domain model as part of the public interface. Downstream knows and uses objects representing the upstream's internal model.\n\n**Code signals**:\n\n```python\n# Analysis module uses Customer from CRM directly\nfrom crm.models import Customer  # CRM's internal model\n\nclass Analysis:\n    def process(self, customer_id):\n        customer = crm_repo.get(customer_id)  # returns full Customer\n        status = customer.status  # only needs status, but knows everything\n```\n\n```typescript\n\u002F\u002F Service B consuming Service A's internal model via API\ninterface CustomerFromServiceA {\n  internalAccountCode: string; \u002F\u002F internal detail exposed\n  legacyId: number; \u002F\u002F unnecessary internal field\n  \u002F\u002F ... many fields Service B doesn't need\n}\n```\n\n**Degrees** (via static connascence):\n\n- _connascence of name_: knows field names of the model\n- _connascence of type_: knows specific types of the model\n- _connascence of meaning_: interprets specific values (magic numbers, internal enums)\n- _connascence of algorithm_: must use same algorithm to interpret data\n- _connascence of position_: depends on element order (tuples, unnamed arrays)\n\n---\n\n#### CONTRACT COUPLING (Weakest — Ideal)\n\nUpstream exposes an _integration-specific model_ (contract), separate from its internal model. The contract abstracts implementation details.\n\n**Code signals**:\n\n```python\nclass CustomerSnapshot:  # integration DTO, not the internal model\n    \"\"\"Public integration contract — stable and intentional.\"\"\"\n    id: str\n    status: str  # enum converted to string\n    tier: str    # only what consumers need\n\n    @staticmethod\n    def from_customer(customer: Customer) -> 'CustomerSnapshot':\n        return CustomerSnapshot(\n            id=str(customer.id),\n            status=customer.status.value,\n            tier=customer.loyalty_tier.display_name\n        )\n```\n\n**Characteristics of good Contract Coupling**:\n\n- Dedicated DTOs\u002FViewModels per use case (not the domain model)\n- Versionable contracts (V1, V2)\n- Primitive types or simple value types\n- Explicit contract documentation (OpenAPI, Protobuf, etc.)\n- Patterns: Facade, Adapter, Anti-Corruption Layer, Published Language (DDD)\n\n---\n\n### PHASE 4 — Volatility Assessment\n\nFor each module, estimate volatility based on:\n\n**4.1 Subdomain type** (preferred) — see table in Phase 1\n\n**4.2 Git analysis** (when available):\n\n```bash\n# Commits per file in the last 6 months\ngit log --since=\"6 months ago\" --format=\"\" --name-only | sort | uniq -c | sort -rn | head -20\n\n# Files that change together frequently (temporal coupling)\n# High co-change = possible undeclared functional coupling\n```\n\n**4.3 Code signals**:\n\n- Many TODO\u002FFIXME → area under evolution (higher volatility)\n- Many API versions (V1, V2, V3) → frequently changing area\n- Fragile tests that break constantly → volatile area\n- Comments \"business rule: ...\" → business logic = probably core\n\n**4.4 Inferred volatility**\n\nEven a supporting subdomain module may have high volatility if:\n\n- It has Intrusive or Functional coupling with core subdomain modules\n- Changes in core propagate to it frequently\n\n---\n\n### PHASE 5 — Balance Score Calculation\n\nFor each coupled pair (A → B):\n\n**Simplified scale (0 = low, 1 = high)**:\n\n| Dimension  | 0 (Low)                      | 1 (High)           |\n| ---------- | ---------------------------- | ------------------ |\n| Strength   | Contract coupling            | Intrusive coupling |\n| Distance   | Same object\u002Fnamespace        | Different services |\n| Volatility | Generic\u002FSupporting subdomain | Core subdomain     |\n\n**Maintenance effort formula**:\n\n```\nMAINTENANCE_EFFORT = STRENGTH × DISTANCE × VOLATILITY\n```\n\n(0 in any dimension = low effort)\n\n**Classification table**:\n\n| Strength | Distance | Volatility | Diagnosis                                                        |\n| -------- | -------- | ---------- | ---------------------------------------------------------------- |\n| High     | High     | High       | ? **CRITICAL** — Global complexity + high change cost           |\n| High     | High     | Low        | ? **ACCEPTABLE** — Strong but stable (e.g. legacy integration)  |\n| High     | Low      | High       | ? **GOOD** — High cohesion (change together, live together)     |\n| High     | Low      | Low        | ? **GOOD** — Strong but static                                  |\n| Low      | High     | High       | ? **GOOD** — Loose coupling (separate and independent)          |\n| Low      | High     | Low        | ? **GOOD** — Loose coupling and stable                          |\n| Low      | Low      | High       | ? **ATTENTION** — Local complexity (mixes unrelated components) |\n| Low      | Low      | Low        | ? **ACCEPTABLE** — May generate noise, but low cost             |\n\n---\n\n### PHASE 6 — Analysis Report\n\nStructure the report in sections:\n\n#### 6.1 Executive Summary\n\n```\nCODEBASE: [name]\nMODULES ANALYZED: N\nDEPENDENCIES MAPPED: N\nCRITICAL ISSUES: N\nMODERATE ISSUES: N\n\nOVERALL HEALTH SCORE: [Healthy \u002F Attention \u002F Critical]\n```\n\n#### 6.2 Dependency Map\n\nPresent the annotated graph:\n\n```\n[ModuleA] --[INTRUSIVE]-----------> [ModuleB]\n[ModuleC] --[CONTRACT]------------> [ModuleD]\n[ModuleE] --[FUNCTIONAL:symmetric]-> [ModuleF]\n```\n\n#### 6.3 Identified Issues (by severity)\n\nFor each critical or moderate issue:\n\n```\nISSUE: [descriptive name]\n────────────────────────────────────────\nModules involved: A → B\nCoupling type: Functional Coupling (symmetric)\nConnascence level: Connascence of Value\n\nEvidence in code:\n  [snippet or description of found pattern]\n\nDimensions:\n  • Strength:   HIGH  (Functional - symmetric)\n  • Distance:   HIGH  (separate services)\n  • Volatility: HIGH  (core subdomain)\n\nBalance Score: CRITICAL ?\nMaintenance: High — frequent changes propagate over long distance\n\nImpact: Any change to business rule [X] requires simultaneous\n        update in [A] and [B], which belong to different teams.\n\nRecommendation:\n  → Extract shared logic to a dedicated module that both can\n    reference (DRY + contract coupling)\n  → Or: Accept duplication and explicitly document the coupling\n    (if volatility is lower than it appears)\n```\n\n#### 6.4 Positive Patterns Found\n\n```\n✅ [ModuleX] uses dedicated integration DTOs — contract coupling well implemented\n✅ [ServiceY] exposes only necessary data via API — minimizes model coupling\n✅ [PackageZ] encapsulates its internal model well — low implementation leakage\n```\n\n#### 6.5 Prioritized Recommendations\n\n**High priority** (high impact, blocking evolution):\n\n1. ...\n\n**Medium priority** (improve architectural health): 2. ...\n\n**Low priority** (incremental improvements): 3. ...\n\n---\n\n## Quick Reference: Pattern → Integration Strength\n\n| Pattern found                        | Integration Strength       | Action                               |\n| ------------------------------------ | -------------------------- | ------------------------------------ |\n| Reflection to access private members | Intrusive                  | Refactor urgently                    |\n| Reading another service's DB         | Intrusive                  | Refactor urgently                    |\n| Duplicated business logic            | Functional (symmetric)     | Extract to shared module             |\n| Distributed transaction \u002F Saga       | Functional (transactional) | Evaluate if cohesion would be better |\n| Mandatory execution order            | Functional (sequential)    | Document protocol or encapsulate     |\n| Rich domain object returned          | Model coupling             | Create integration DTO               |\n| Internal enum shared externally      | Model coupling             | Create public contract enum          |\n| Use-case-specific DTO                | Contract coupling          | ✅ Correct pattern                   |\n| Versioned public interface\u002Fprotocol  | Contract coupling          | ✅ Correct pattern                   |\n| Anti-Corruption Layer                | Contract coupling          | ✅ Correct pattern                   |\n\n## Quick Heuristics\n\n**For Integration Strength**:\n\n- \"If I change an internal detail of module X, how many other modules need to change?\"\n- \"Was the integration contract designed to be public, or is it accidental?\"\n- \"Is there duplicated business logic that must be manually synchronized?\"\n\n**For Distance**:\n\n- \"What's the cost of making a change that affects both modules?\"\n- \"Do teams maintaining these modules need to coordinate deployments?\"\n- \"If one module fails, does the other stop working?\"\n\n**For Volatility**:\n\n- \"Does this module encapsulate competitive business advantage?\"\n- \"Does the business team frequently request changes in this area?\"\n- \"Is there a history of many refactors in this area?\"\n\n**For Balance**:\n\n- \"Do components that need to change together live together in the code?\"\n- \"Are independent components well separated?\"\n- \"Where is there strong coupling with volatile and distant components?\" (→ this is the main problem)\n\n## Known Limitations\n\n- **Volatility** is best estimated with real git data rather than static analysis alone\n- **Symmetric functional coupling** requires semantic code reading — static analysis tools generally don't detect it\n- **Organizational distance** (different teams) requires user input\n- **Dynamic connascence** (timing, value, identity) is hard to detect without runtime observation\n- Analysis is a starting point — business context always refines the conclusions\n\n## Book References\n\nThese concepts are based on _Balancing Coupling in Software Design_ by Vlad Khononov (Addison-Wesley).\n",{},"main","def8531e65114c0fca8fb8551c1871ee0eed705c","skills\u002Ftech-leads-club\u002Fagent-skills\u002Fcoupling-analysis",24,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub","https:\u002F\u002Fskillshub.wtf","https:\u002F\u002Fgithub.com\u002FComeOnOliver","AI & Blockchain Engineer\r\n","2026-06-24 22:07:19",{"source":7,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add ComeOnOliver\u002Fskillshub --skill coupling-analysis",{"tool":40,"command":41},"bunx","bunx skills add ComeOnOliver\u002Fskillshub --skill coupling-analysis",{"tool":43,"command":44},"pnpm","pnpm dlx skills add ComeOnOliver\u002Fskillshub --skill coupling-analysis","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Ftech-leads-club\u002Fagent-skills\u002Fcoupling-analysis\u002FSKILL.md",true,[],[49,63,73,82,88,95],{"skillNo":50,"name":51,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":52,"categories":53,"keywords":59,"publishedAt":21},"01M6FKJN13GMG4KY57J3QD8GY5","model-hierarchy-skill","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzscole\u002Fmodel-hierarchy-skill\u002Fmodel-hierarchy-skill\u002FSKILL.md",[54],{"categoryNo":55,"categoryName":56,"taxonomyType":57,"taxonomyTypeDesc":58},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[60,61,62],"model","model hierarchy","model hierarchy skill",{"skillNo":64,"name":65,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":69,"publishedAt":21},"01M6FKJJJ6GCAMR4PPPRD12M5X","zoom-mcp","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-mcp\u002FSKILL.md",[68],{"categoryNo":55,"categoryName":56,"taxonomyType":57,"taxonomyTypeDesc":58},[70,71,72],"MCP","zoom","zoom mcp",{"skillNo":74,"name":75,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":21},"01M6FKJE3KYT3KPEZMEEHYKA6K","zoom-apps-sdk","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-apps-sdk\u002FSKILL.md",[],[79,80,81,71],"sdk","zoom apps sdk","apps",{"skillNo":83,"name":84,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":21},"01M6FKJ9EDH9Q5VWDF8HAJRSP0","windows","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwindows\u002FSKILL.md",[],[84],{"skillNo":89,"name":90,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":94,"publishedAt":21},"01M6FKJ666BEEFC3AE9GJ72Q93","whiteboard","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwhiteboard\u002FSKILL.md",[93],{"categoryNo":55,"categoryName":56,"taxonomyType":57,"taxonomyTypeDesc":58},[90],{"skillNo":96,"name":97,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":21},"01M6FKJ21WFCDGTJQ2Q91T9DVW","websockets","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwebsockets\u002FSKILL.md",[],[97]]