module-boundary-and-configuration

Guides module layering, explicit installation, configuration, and controlled degradation decisions.

Updated Mar 17, 2026
One-click install
npx skills add https://github.com/DJackyB/Project_Rent --skill module-boundary-and-configuration-djackyb
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: module-boundary-and-configuration
Source: https://github.com/DJackyB/Project_Rent/tree/main/.claude/skills/module-boundary-and-configuration
Command: npx skills add https://github.com/DJackyB/Project_Rent --skill module-boundary-and-configuration-djackyb

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When designing reusable modules, integrating third-party systems, or wiring up configuration, teams often blur module boundaries, rely on implicit auto-registration, confuse reference documents with runtime sources of truth, and let fallbacks silently mask broken core logic. This Skill provides a structured set of engineering principles to keep module boundaries clean and configuration explicit. ## Core Features & Use Cases - Three-Layer Module Design: Classifies capabilities into core layer, preset layer, and project integration layer, with clear rules for what belongs in each. - Explicit Installation & Configuration: Enforces explicit bootstrap/registration over implicit side effects, and explicit Inspector/registry configuration over runtime guessing for stable structures. - Single Source of Truth & Controlled Degradation: Distinguishes reference material from runtime truth, and restricts fallback/no-op behavior to genuinely optional capabilities. - Use Case: When extracting a shared capability from a Unity project into a reusable module, use this Skill to decide which layer each piece belongs to, how it should be installed, which references must be explicitly configured, and how to verify the wiring. ## Quick Start Use the module-boundary-and-configuration skill to review whether my new module's layering, installation, and configuration follow clean boundary principles.

Frequently Asked Questions about module-boundary-and-configuration

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

FAQPage Schema
How do I decide which layer a reusable module belongs to?▼

Classify capabilities into three layers: core layer for generic protocols and cross-project behavior, preset layer for stable reusable defaults, and project integration layer for project-specific semantics. If logic depends on project naming or state, it must stay in the integration layer.

When should configuration be explicit instead of runtime-resolved?▼

Use explicit configuration for core references, stable prefab structures, key UI nodes, and high-reuse or error-prone objects. Runtime resolution is acceptable only for prototypes, pure display overlays, or low-risk nodes still in flux.

What is the difference between a reference source and a runtime source of truth?▼

Design documents, Excel sheets, and derived caches are reference material, not runtime truth. The runtime source of truth must be a single, explicit, verifiable configuration entry that the system actually reads at execution time.

When is fallback or no-op degradation acceptable in module design?▼

Degradation is acceptable only for capabilities explicitly designed as optional, such as display modules or enhancement services. It must never mask missing configuration, broken contracts, or core logic failures behind default values.

How should third-party SDKs be integrated without polluting core modules?▼

Integrate external systems through adapters, bridges, and service boundaries in the integration layer. Adapters translate external semantics into internal inputs, keeping project and vendor concepts out of the core layer.