mcaf

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 every affected local AGENTS.md completely before editing any of them.
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.

MCAF 1.3.68 Policy Contract

When a repository declares that it follows MCAF 1.3, preserve these upstream mandatory policies rather than treating them as optional templates:

• MCAF-ARCH-001: keep the complete solution in one repository and use one canonical vertical-slice identity across applicable code, tests, infrastructure, and feature documentation.
• MCAF-GOV-001: merge incoming MCAF guidance into existing root and local AGENTS.md files. Never overwrite, truncate, summarize away, weaken, or silently omit an existing repository rule.
• MCAF-REQ-001: for non-trivial features, keep stable requirements and acceptance criteria, map them to automated tests or explicit evidence exceptions, and link any required ADR implementation contract.
• MCAF-AI-001: use a capable planning/integration owner for non-trivial work and keep delegated scopes bounded, independently verified, and joined before completion when the execution environment supports delegation.

Do not inject these policies into a repository that has not chosen MCAF. When updating an existing MCAF repository, preserve any stricter local rule and report a genuine conflict instead of weakening it.

Minimal Rules

• Keep one root AGENTS.md.
• In a multi-project MCAF solution, keep a local AGENTS.md in each project or module root with its entry points, boundaries, commands, applicable skills, and local risks.
• 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 invent planning artifacts beyond the repository's adopted MCAF version. Current MCAF 1.3 repositories require brainstorm, acceptance, and plan artifacts for non-trivial work, so preserve that contract when it is already adopted.
• 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
• an MCAF 1.3 repository preserves MCAF-ARCH-001, MCAF-GOV-001, MCAF-REQ-001, and MCAF-AI-001 or records an explicit versioned migration state
• scripts/verify-mandatory-policies.sh passes when the consuming repository has adopted the upstream verifier
• 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.