module-boundaries

Evaluate module boundaries for merging or separating responsibilities.

11|Updated Feb 25, 2026
One-click install
npx skills add https://github.com/codybrom/clairvoyance --skill module-boundaries
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: module-boundaries
Source: https://github.com/codybrom/clairvoyance/tree/main/skills/module-boundaries
Command: npx skills add https://github.com/codybrom/clairvoyance --skill module-boundaries

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps determine whether modules are divided in the right places, preventing shallow pass-through components, duplicated knowledge, and tightly coupled boundaries that make changes harder to understand and maintain.

Core Features & Use Cases

  • Boundary Evaluation: Analyze whether related responsibilities should be merged and unrelated responsibilities should be separated.
  • Decomposition Guidance: Identify merge signals, split signals, conjoined methods, and opportunities for a genuine third abstraction.
  • Knowledge Ownership Analysis: Check whether each boundary fully encloses the design decisions and shared information it owns.
  • Use Case: Apply it when deciding whether to split a large class, merge tightly coupled modules, or review a decomposition where changes repeatedly span multiple components.

Quick Start

Use the module-boundaries skill to review the architecture and boundary decisions in the specified file or module path.

Frequently Asked Questions about module-boundaries

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide whether to split a large class or merge tightly coupled modules?

To evaluate module boundaries, test merge and split signals to determine if related responsibilities should be combined or separated. You map shared knowledge, check for conjoined methods, and validate that boundaries enclose authoritative design decisions.

Why does repeated cross-module changes happen during software architecture decomposition?

Repeated cross-module changes occur when module boundaries are drawn incorrectly, failing to fully enclose authoritative design decisions. This indicates tightly coupled boundaries where related responsibilities are split or duplicated knowledge exists.

What are the signals for refactoring tightly coupled code into separate modules?

Refactoring signals for separating modules include identifying conjoined methods, duplicated knowledge, and shallow pass-through components. You validate that genuine boundaries enclose distinct authoritative design decisions and fully own their shared information.

When should I merge modules during code review?

Merge modules during code review when boundaries contain tightly coupled responsibilities and duplicated knowledge. Testing merge signals helps determine if combining them creates a stronger boundary that better encloses authoritative design decisions.

What is a shallow pass-through component in software architecture?

A shallow pass-through component is a module boundary that does not enclose authoritative design decisions, instead merely routing shared information. It signals incorrect decomposition where responsibilities should likely be merged to simplify boundaries.