component-boundary-identifier
SolidIdentifies boundaries between modules or components in software systems through static code analysis and dependency detection. Use when Claude needs to analyze software architecture, identify module boundaries, detect boundary violations, find circular dependencies, or assess component coupling. Supports Python (packages and imports) and Java (packages and dependencies). Trigger when users ask to "identify boundaries", "find component boundaries", "detect boundary violations", "analyze module structure", "check architecture", or "find circular dependencies".
Install
Quality Score: 84/100
Skill Content
Details
- Author
- ArabelaTso
- Repository
- ArabelaTso/Skills-4-SE
- Created
- 7 months ago
- Last Updated
- 1 months ago
- Language
- Python
- License
- Apache-2.0
Similar Skills
Semantically similar based on skill content — not just same category
design-boundaries
Use when an agent needs to design component boundaries for a feature or system before the code exists; partitions responsibilities into single-purpose components with minimal interfaces and an acyclic dependency direction, then pressure-tests the boundaries rather than editing code, splitting an existing tangled unit, or extracting a separate repository.
service-boundary-analysis
Trigger: service boundary analysis, microservice inputs/outputs, API/consumer/output mapping. Map one backend boundary with evidence and confidence.
component-and-release-boundaries
Deciding what becomes an independently releasable component — a Maven module, a JPMS module, a published library — and what that costs: the tension between reusing code and being able to release it, why a shared jar couples every service depending on it, breaking cycles between components, and judging whether a component is stable enough to depend on. Use when a `common` or `shared` module is proposed or has grown, when extracting code into a library so two services can reuse it, when a dependency cycle appears between Maven modules, when upgrading one library forces a coordinated release of several services, or when services are independently deployable in theory but always ship together. Does not cover cohesion and coupling at class and package level (java-cohesion-coupling), whether a component should become a separate process (distribution-boundaries), the API compatibility of a published type (java-api-design), or wire contract versioning (rpc-and-api-contracts).