mcaf

Name: mcaf
Author: managedcode

461stars35forks

How to install mcaf?

managedcode/dotnet-skills/mcaf

$npx -y skills add managedcode/dotnet-skills --skill mcaf

Installs into the current project.

Summary

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 US

Files · 1

View on GitHub

SKILL.md

1	# MCAF Governance
2
3	Keep MCAF as one opt-in governance layer. Do not create parallel `mcaf-*` implementation or process skills.
4
5	## Workflow
6
7	1. Confirm that the request is explicitly about adopting MCAF or changing MCAF governance.
8	2. Read the root `AGENTS.md` and the nearest local `AGENTS.md`, if one exists.
9	3. Keep only durable repository rules that future contributors and agents must know.
10	4. Put each rule next to the area that owns it. Add a local `AGENTS.md` only when a subtree genuinely differs.
11	5. Record exact build, test, format, analysis, and operational commands when the repository depends on them.
12	6. Route implementation work to the normal catalog skill closest to the actual technology or behavior.
13	7. Validate the changed policy, documentation links, and repository commands.
14
15	## Minimal Rules
16
17	- Keep one root `AGENTS.md`.
18	- Add local policy only for real local differences; local rules may tighten but not silently weaken root rules.
19	- Keep one source of truth for each durable fact.
20	- Describe the current repository, not an intended future state.
21	- Make acceptance and verification expectations concrete and runnable.
22	- Add feature specifications, ADRs, review plans, or quality constraints only when the task actually needs those artifacts.
23	- Turn repeated team pain into a small durable rule; do not encode one-off preferences.
24
25	## Boundaries
26
27	- Do not use MCAF as a router for normal .NET work; use `dotnet` or the narrow framework skill.
28	- Do not impose generic agile ceremonies, branch naming, UI/UX choices, onboarding templates, NFR catalogs, or ML process.
29	- Do not duplicate testing, CI, documentation, security, observability, or architecture skills under an MCAF namespace.
30	- Do not require brainstorm or plan files for every non-trivial task unless the repository explicitly adopts that workflow.
31	- Do not add process artifacts that are larger than the decision or behavior they clarify.
32
33	## Deliver
34
35	- the smallest repository-native governance change that resolves the explicit MCAF request
36	- direct routing to implementation-focused skills for everything outside governance
37
38	## Validate
39
40	- every new rule is durable, scoped, and owned by a repository surface
41	- no rule duplicates a normal implementation skill
42	- referenced commands and paths exist
43	- removed or renamed MCAF surfaces leave no dangling catalog, bundle, watch, or documentation references
44
45	## Reference
46
47	Read [references/adoption.md](references/adoption.md) only when bootstrapping MCAF in a repository.

People who liked this also viewed

6 picks

Type

mcaf

461stars35forks

View on GitHub

How to install mcaf?

managedcode/dotnet-skills/mcaf

$npx -y skills add managedcode/dotnet-skills --skill mcaf

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# MCAF Governance
2
3	Keep MCAF as one opt-in governance layer. Do not create parallel `mcaf-*` implementation or process skills.
4
5	## Workflow
6
7	1. Confirm that the request is explicitly about adopting MCAF or changing MCAF governance.
8	2. Read the root `AGENTS.md` and the nearest local `AGENTS.md`, if one exists.
9	3. Keep only durable repository rules that future contributors and agents must know.
10	4. Put each rule next to the area that owns it. Add a local `AGENTS.md` only when a subtree genuinely differs.
11	5. Record exact build, test, format, analysis, and operational commands when the repository depends on them.
12	6. Route implementation work to the normal catalog skill closest to the actual technology or behavior.
13	7. Validate the changed policy, documentation links, and repository commands.
14
15	## Minimal Rules
16
17	- Keep one root `AGENTS.md`.
18	- Add local policy only for real local differences; local rules may tighten but not silently weaken root rules.
19	- Keep one source of truth for each durable fact.
20	- Describe the current repository, not an intended future state.
21	- Make acceptance and verification expectations concrete and runnable.
22	- Add feature specifications, ADRs, review plans, or quality constraints only when the task actually needs those artifacts.
23	- Turn repeated team pain into a small durable rule; do not encode one-off preferences.
24
25	## Boundaries
26
27	- Do not use MCAF as a router for normal .NET work; use `dotnet` or the narrow framework skill.
28	- Do not impose generic agile ceremonies, branch naming, UI/UX choices, onboarding templates, NFR catalogs, or ML process.
29	- Do not duplicate testing, CI, documentation, security, observability, or architecture skills under an MCAF namespace.
30	- Do not require brainstorm or plan files for every non-trivial task unless the repository explicitly adopts that workflow.
31	- Do not add process artifacts that are larger than the decision or behavior they clarify.
32
33	## Deliver
34
35	- the smallest repository-native governance change that resolves the explicit MCAF request
36	- direct routing to implementation-focused skills for everything outside governance
37
38	## Validate
39
40	- every new rule is durable, scoped, and owned by a repository surface
41	- no rule duplicates a normal implementation skill
42	- referenced commands and paths exist
43	- removed or renamed MCAF surfaces leave no dangling catalog, bundle, watch, or documentation references
44
45	## Reference
46
47	Read [references/adoption.md](references/adoption.md) only when bootstrapping MCAF in a repository.

People who liked this also viewed

6 picks

Type