Module Governance

# 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.