loose-coupling-checker
Purpose
Review a design for coupling risks across services, teams, schemas, deployments, and runtime behavior.
Expected inputs
- proposed architecture
- integration style
- deployment model
- ownership boundaries
Deliverables
- coupling review
- highest-risk couplings
- decoupling recommendations
- priority fixes
Trigger this skill when
- You need to make an enterprise or integration decision that spans more than a single codebase.
- Multiple systems, teams, environments, or governance constraints influence the design.
- A recommendation needs to be tied to enterprise reality rather than generic integration advice.
Operating procedure
- Clarify the system, estate, or cross-system workflow being assessed.
- Separate facts, assumptions, constraints, and missing enterprise context.
- Produce a context-specific analysis rather than a platform- or buzzword-driven recommendation.
- Make tradeoffs explicit, especially around governance, ownership, runtime failure, and operational cost.
- Recommend the next most useful architecture or delivery skill.
Quality gates
- Recommendations acknowledge enterprise constraints, ownership, and operational consequences.
- Interfaces, dependencies, and environment implications are not hand-waved away.
- Assumptions and open questions are visible.
- Output is specific enough to inform architecture, integration, or release planning.
Output style
- Be concrete and structured.
- Separate evidence, inference, and recommendation.
- Prefer explicit tradeoffs over single-answer absolutism.
- Use priority or severity where useful.
Failure modes to avoid
- Do not recommend technology because it sounds enterprise-grade.
- Do not ignore team boundaries, operational maturity, or integration sprawl.
- Do not treat all workloads as equally suited to the same platform pattern.
- Do not hide uncertainty behind confident language.
Minimum output skeleton
## Summary
## Findings or proposal
## Evidence vs assumptions
## Risks or tradeoffs
## Recommended next skill
Handoff targets
- rpc-vs-message-pattern-selector
- publish-subscribe-designer
- ci-cd-readiness-checker
1---2name: loose-coupling-checker3description: loose-coupling-checker4---5# loose-coupling-checker67## Purpose8Review a design for coupling risks across services, teams, schemas, deployments, and runtime behavior.910## Expected inputs11- proposed architecture12- integration style13- deployment model14- ownership boundaries1516## Deliverables17- coupling review18- highest-risk couplings19- decoupling recommendations20- priority fixes2122## Trigger this skill when23- You need to make an enterprise or integration decision that spans more than a single codebase.24- Multiple systems, teams, environments, or governance constraints influence the design.25- A recommendation needs to be tied to enterprise reality rather than generic integration advice.2627## Operating procedure281. Clarify the system, estate, or cross-system workflow being assessed.292. Separate facts, assumptions, constraints, and missing enterprise context.303. Produce a context-specific analysis rather than a platform- or buzzword-driven recommendation.314. Make tradeoffs explicit, especially around governance, ownership, runtime failure, and operational cost.325. Recommend the next most useful architecture or delivery skill.3334## Quality gates35- Recommendations acknowledge enterprise constraints, ownership, and operational consequences.36- Interfaces, dependencies, and environment implications are not hand-waved away.37- Assumptions and open questions are visible.38- Output is specific enough to inform architecture, integration, or release planning.3940## Output style41- Be concrete and structured.42- Separate evidence, inference, and recommendation.43- Prefer explicit tradeoffs over single-answer absolutism.44- Use priority or severity where useful.4546## Failure modes to avoid47- Do not recommend technology because it sounds enterprise-grade.48- Do not ignore team boundaries, operational maturity, or integration sprawl.49- Do not treat all workloads as equally suited to the same platform pattern.50- Do not hide uncertainty behind confident language.5152## Minimum output skeleton53```md54## Summary55## Findings or proposal56## Evidence vs assumptions57## Risks or tradeoffs58## Recommended next skill59```6061## Handoff targets62- rpc-vs-message-pattern-selector63- publish-subscribe-designer64- ci-cd-readiness-checker