MCAF Governance

Keep MCAF as one opt-in governance layer. Do not create parallel mcaf-* implementation or process skills.

Workflow

1. Confirm that the request is explicitly about adopting MCAF or changing MCAF governance.
2. Read the root AGENTS.md and the nearest local AGENTS.md, if one exists.
3. Keep only durable repository rules that future contributors and agents must know.
4. Put each rule next to the area that owns it. Add a local AGENTS.md only when a subtree genuinely differs.
5. Record exact build, test, format, analysis, and operational commands when the repository depends on them.
6. Route implementation work to the normal catalog skill closest to the actual technology or behavior.
7. Validate the changed policy, documentation links, and repository commands.

Minimal Rules

• Keep one root AGENTS.md.
• Add local policy only for real local differences; local rules may tighten but not silently weaken root rules.
• Keep one source of truth for each durable fact.
• Describe the current repository, not an intended future state.
• Make acceptance and verification expectations concrete and runnable.
• Add feature specifications, ADRs, review plans, or quality constraints only when the task actually needs those artifacts.
• Turn repeated team pain into a small durable rule; do not encode one-off preferences.

Boundaries

• Do not use MCAF as a router for normal .NET work; use dotnet or the narrow framework skill.
• Do not impose generic agile ceremonies, branch naming, UI/UX choices, onboarding templates, NFR catalogs, or ML process.
• Do not duplicate testing, CI, documentation, security, observability, or architecture skills under an MCAF namespace.
• Do not require brainstorm or plan files for every non-trivial task unless the repository explicitly adopts that workflow.
• Do not add process artifacts that are larger than the decision or behavior they clarify.

Deliver

• the smallest repository-native governance change that resolves the explicit MCAF request
• direct routing to implementation-focused skills for everything outside governance

Validate

• every new rule is durable, scoped, and owned by a repository surface
• no rule duplicates a normal implementation skill
• referenced commands and paths exist
• removed or renamed MCAF surfaces leave no dangling catalog, bundle, watch, or documentation references

Reference

Read references/adoption.md only when bootstrapping MCAF in a repository.