# Module Governance

Set up a module's local agent instructions and interface ownership when it changes.

- Repository: https://github.com/affaan-m/ECC (294725 stars)
- Category: AI and agents
- License: MIT
- Last updated: 2026-10-30
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add affaan-m/ECC --skill module-governance -g -a claude-code -y`
Codex: `npx skills add affaan-m/ECC --skill module-governance -g -a codex -y`
Cursor: `npx skills add affaan-m/ECC --skill module-governance -g -a cursor -y`
Gemini CLI: `npx skills add affaan-m/ECC --skill module-governance -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add affaan-m/ECC`

## Description

Establish or maintain a business module's local agent instructions, domain-context links, and interface ownership when implementing a new module or changing its responsibilities. Reuse project-level rules and existing ECC workflows; ordinary bug fixes, styling, and read-only design discussions do not start module documentation setup.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

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

The rest: https://github.com/affaan-m/ECC/blob/HEAD/.agents/skills/module-governance/SKILL.md