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.