Review .NET changes for bugs, regressions, architectural drift, missing tests, incorrect async or disposal behavior, and platform-specific pitfalls before you approve or merge…
MCAF Governance
Apply minimal MCAF repository governance when the user explicitly asks to adopt MCAF or change MCAF-specific rules. USE FOR: creating or tightening root and local AGENTS.md policy; placing durable engineering context; defining the repository's own verification contract. DO NOT USE FOR: ordinary .NET implementation, documentation edits, UI/UX, testing, CI, Git, NFR, developer-experience, or ML work unless the request is specifically about MCAF governance. INVOKES: inspect repository policy and documentation, make the smallest durable governance change, then validate the affected repository surfaces.
Workflow
- Confirm that the request is explicitly about adopting MCAF or changing MCAF governance.
- Read the root
AGENTS.mdand the nearest localAGENTS.md, if one exists. - Keep only durable repository rules that future contributors and agents must know.
- Put each rule next to the area that owns it. Add a local
AGENTS.mdonly when a subtree genuinely differs. - Record exact build, test, format, analysis, and operational commands when the repository depends on them.
- Route implementation work to the normal catalog skill closest to the actual technology or behavior.
- Validate the changed policy, documentation links, and repository commands.
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