tpo-module-structure-guidelines

Plan and review software module structures with boundary rules, templates, and checklists.

Updated Mar 22, 2026
One-click install
npx skills add https://github.com/TECH-HY/SKILLS --skill tpo-module-structure-guidelines-tech-hy
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: tpo-module-structure-guidelines
Source: https://github.com/TECH-HY/SKILLS/tree/main/skills/tpo-module-structure-guidelines
Command: npx skills add https://github.com/TECH-HY/SKILLS --skill tpo-module-structure-guidelines-tech-hy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Software projects often grow into tangled codebases where modules lack clear responsibilities, circular dependencies appear, and shared folders become dumping grounds. This Skill gives a Technical Product Owner agent concrete guidelines, templates, and review checklists to plan and audit module structure so the project stays understandable for humans and AI agents. ## Core Features & Use Cases - Module Structure Planning: Provides recommended directory layouts for modular monoliths, backend-heavy, and frontend-heavy projects, plus a module plan template covering dependencies, public interfaces, and integration adapters. - Boundary Enforcement Rules: Defines five boundary rules covering inward imports, shared-folder discipline, infrastructure adapters, dependency direction, and single data ownership per entity. - Review Checklists and Templates: Ships a module README template, split/merge decision criteria, and a review checklist for validating module quality. - Use Case: When starting a new MVP, ask the agent to produce a module plan; it will output a module list with responsibilities, data ownership, dependency map, and risky boundaries that developers can implement against. ## Quick Start Ask the agent to create a module structure plan for your project using the module structure guidelines, including the module list, dependency map, and public interfaces.

Frequently Asked Questions about tpo-module-structure-guidelines

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

FAQPage Schema
How do I plan a module structure for a new software project?▼

Start with a modular monolith layout separating app, features, shared, integrations, and jobs directories. Then produce a module plan listing each module's responsibility, data ownership, dependencies, and public interfaces using the provided planning template.

What is the recommended folder structure for a modular monolith?▼

The recommended default places feature modules under src/features, reusable utilities under src/shared, external service adapters under src/integrations, and background work under src/jobs. Each feature module exposes a public API through an index file.

When should I split a module into smaller modules?▼

Split a module when it has more than one clear responsibility, changes for unrelated reasons, or its tests require too many mixed dependencies. Do not split merely because a module has many files; split when responsibility is unclear.

How do I avoid circular dependencies between modules?▼

Define and document a single dependency direction, such as UI to feature API to service to repository. If a circular dependency appears, introduce a domain event or shared abstraction to break the cycle.

What belongs in a shared folder and what does not?▼

Shared folders should hold stable reusable utilities like generic UI components, config helpers, logging, and API client bases. Business logic specific to one feature, temporary hacks, and module-specific data mutations do not belong there.