Module Governance

Connect module-level working rules to existing domain language, contracts, and decisions. This is an orchestration skill, not a second DDD methodology or an automatic documentation generator.

When to Activate

• The user asks to implement a new business module, without needing to name this skill.
• The user asks to document an existing module or maintain a confirmed responsibility change.
• An authorized module change needs local instructions and canonical knowledge pointers.

Do not start setup for an ordinary bug, styling change, internal refactor with unchanged boundaries, or a new directory/UI component that simply inherits parent conventions. For design discussion or an audit alone, inspect and report without creating files. Intent-based selection is not a background hook and does not grant permission for unrelated code, commits, pushes, or business choices.

How It Works

1. Discover the boundary before creating documents

Read applicable project and ancestor harness instructions, the existing map, requirements, relevant code, and contracts. Identify the module's responsibilities, non-responsibilities, state ownership, and actual consumers. Directory names alone do not establish a bounded context. Surface material ambiguities instead of inventing business rules.

For an existing boundary change, use change-impact first. Its read-only and authorization constraints still apply; do not run an unrelated development workflow.

2. Separate project-wide rules from local rules

The project-level instruction source owns global constraints, module navigation, and cross-module collaboration. A local AGENTS.md owns only additional module constraints: responsibilities, state ownership, public-interface pointers, and verification entry points. Local rules cannot waive project-wide constraints.