How to use the Module Governance agent skill

What an agent skill is and what Module Governance makes the agent do

An agent skill is a folder with a SKILL.md file that tells an AI coding agent how to handle a certain kind of task. The agent loads it when the request matches the skill's description.

Module Governance applies when you start a new business module or change what a module is responsible for. The agent first reads the project's existing rules, glossary, contracts and decisions. It then adds only the minimal local instruction file and links that are genuinely missing. It does not create documents for simple bug fixes, styling, internal refactors or read-only discussions, and it asks for confirmation on ambiguous business rules instead of inventing them.

The skill is an orchestration layer, not a documentation generator and not a full DDD methodology. It points to existing ECC skills for the actual work.

Install the Module Governance skill

Download the ZIP for the module-governance skill from this page. Unzip it into one of two locations, depending on how you want to use it.

For all your projects, unzip it into ~/.claude/skills/. For a single project, unzip it into the project's .claude/skills/ folder. The skill folder should contain SKILL.md and agents/openai.yaml.

You can also upload the skill in the Claude apps under Settings → Capabilities → Skills.

• Personal install: ~/.claude/skills/
• Project install: .claude/skills/ inside your repository
• Claude apps: Settings → Capabilities → Skills, then upload

Check the requirements before you rely on it

Most of the skill's steps depend on other ECC skills it references. If those are not installed, the steps will not work as written. Python 3 is needed to run the docs-governance audit script.

The referenced skills are docs-governance, context-and-decisions, architecture-decision-records, contract-first, change-impact and living-docs-governance.

• Python 3
• docs-governance
• context-and-decisions
• architecture-decision-records
• contract-first
• change-impact
• living-docs-governance

Trigger the skill with natural requests

You do not need to name the skill. Ask for a module task in plain words, such as implementing a new business module or documenting an existing one. The skill also activates when you ask to maintain a confirmed change to a module's responsibilities.

Requests that should not trigger setup include ordinary bug fixes, styling changes, internal refactors with unchanged boundaries, and design discussions. For those, the agent inspects and reports without creating files.

• Implement an inventory module.
• Document the existing payments module.
• Should payments become a separate module? (discussion only, no files written)
• Fix the inventory badge color. (no documentation generated)
• Audit module documentation. (read-only audit)

What the agent does when it runs the skill

The agent first discovers the module boundary by reading applicable instructions, the existing map, requirements, relevant code and contracts. It identifies responsibilities, non-responsibilities, state ownership and real consumers. Directory names alone do not establish a boundary.

Local rules go in a local AGENTS.md only where project rules do not already cover the module. Terminology belongs in the existing CONTEXT.md or equivalent. Existing contracts and ADRs are referenced, not copied.

Finally the agent verifies meaning and links. It runs the docs-governance read-only link check and reports broken references, contradictions and anything it could not verify.

• Reuses an established CLAUDE.md or other harness file instead of renaming it.
• Does not create empty files to meet a file count.
• Labels boundaries as confirmed design with code unverified when no implementation exists yet.

Safety notes: scripts and network access

The skill runs scripts. Its verification step runs the docs-governance audit script, which is described as a read-only link check. The skill does not use the network. Replace the placeholders in the command with the actual path to the installed docs-governance skill, your repository root and the module directory.

The skill states that intent-based selection does not grant permission for unrelated code, commits, pushes or business choices. Review the agent's proposed file changes before accepting them.

• Runs scripts: yes (the docs-governance audit script).
• Uses network: no.
• A passing link check does not prove the business logic is correct.

Tips for getting good results

Give the agent the module's purpose and boundaries in your request. Where a business rule is unclear, expect the agent to ask rather than guess, and answer those questions before it writes anything.

Keep the skill for real module work. Use it on large codebases split into modules; on small projects it adds overhead without benefit.

• Name the module directory so the audit can be scoped with --module.
• Ask for a read-only audit first if you are unsure whether files are needed.
• Check the audit exit code and any unverified targets it reports.