MCAF: .NET ArchUnitNET
Trigger On
- the repo uses or wants
ArchUnitNET
- architecture testing needs richer modeling than simple dependency checks
Value
- produce a concrete project delta: code, docs, config, tests, CI, or review artifact
- reduce ambiguity through explicit planning, verification, and final validation skills
- leave reusable project context so future tasks are faster and safer
Do Not Use For
- the lightest possible architecture rule checks
Inputs
- the nearest
AGENTS.md
- target assemblies
- architecture boundaries and naming conventions
Quick Start
- Read the nearest
AGENTS.md and confirm scope and constraints.
- Run this skill's
Workflow through the Ralph Loop until outcomes are acceptable.
- Return the
Required Result Format with concrete artifacts and verification evidence.
Workflow
- Load the architecture once per test assembly where possible.
- Encode a small number of durable, high-value architecture rules first.
- Use the test-framework-specific integration package that matches the repo.
Bootstrap When Missing
If ArchUnitNET is not configured yet:
- Detect existing setup:
rg -n "TngTech\\.ArchUnitNET" -g '*.csproj' .
- Add packages to the architecture test project:
dotnet add TEST_PROJECT.csproj package TngTech.ArchUnitNET
- add one framework bridge package:
TngTech.ArchUnitNET.xUnit, TngTech.ArchUnitNET.xUnitV3, TngTech.ArchUnitNET.MSTestV2, or TngTech.ArchUnitNET.TUnit
- Add at least one durable boundary rule test.
- Wire architecture tests into the standard
test command in AGENTS.md and CI.
- Run
dotnet test TEST_PROJECT.csproj and return status: configured or status: improved.
- If
NetArchTest already covers the same boundary policy and no gap exists, return status: not_applicable.
Deliver
- architecture tests with richer domain and type modeling
- architecture-rule commands wired into repo test flow and CI expectations
Validate
- architecture load cost is reasonable for the suite
- rules are stable and tied to real boundaries
Ralph Loop
Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.
- Plan first (mandatory):
- analyze current state
- define target outcome, constraints, and risks
- write a detailed execution plan
- list final validation skills to run at the end, with order and reason
- Execute one planned step and produce a concrete delta.
- Review the result and capture findings with actionable next fixes.
- Apply fixes in small batches and rerun the relevant checks or review steps.
- Update the plan after each iteration.
- Repeat until outcomes are acceptable or only explicit exceptions remain.
- If a dependency is missing, bootstrap it or return
status: not_applicable with explicit reason and fallback path.
Required Result Format
status: complete | clean | improved | configured | not_applicable | blocked
plan: concise plan and current iteration step
actions_taken: concrete changes made
validation_skills: final skills run, or skipped with reasons
verification: commands, checks, or review evidence summary
remaining: top unresolved items or none
For setup-only requests with no execution, return status: configured and exact next commands.
Load References
- read
references/archunitnet.md first
Example Requests
- "Use ArchUnitNET for layered architecture tests."
- "Set up ArchUnitNET with xUnit or MSTest."
1---2name: mcaf-dotnet-archunitnet3description: Use the open-source free `ArchUnitNET` library for architecture rules in .NET tests. Use when a repo needs richer architecture assertions than lightweight fluent rule libraries usually provide.4---56# MCAF: .NET ArchUnitNET78## Trigger On910- the repo uses or wants `ArchUnitNET`11- architecture testing needs richer modeling than simple dependency checks1213## Value1415- produce a concrete project delta: code, docs, config, tests, CI, or review artifact16- reduce ambiguity through explicit planning, verification, and final validation skills17- leave reusable project context so future tasks are faster and safer1819## Do Not Use For2021- the lightest possible architecture rule checks2223## Inputs2425- the nearest `AGENTS.md`26- target assemblies27- architecture boundaries and naming conventions2829## Quick Start30311. Read the nearest `AGENTS.md` and confirm scope and constraints.322. Run this skill's `Workflow` through the `Ralph Loop` until outcomes are acceptable.333. Return the `Required Result Format` with concrete artifacts and verification evidence.3435## Workflow36371. Load the architecture once per test assembly where possible.382. Encode a small number of durable, high-value architecture rules first.393. Use the test-framework-specific integration package that matches the repo.4041## Bootstrap When Missing4243If `ArchUnitNET` is not configured yet:44451. Detect existing setup:46 - `rg -n "TngTech\\.ArchUnitNET" -g '*.csproj' .`472. Add packages to the architecture test project:48 - `dotnet add TEST_PROJECT.csproj package TngTech.ArchUnitNET`49 - add one framework bridge package: `TngTech.ArchUnitNET.xUnit`, `TngTech.ArchUnitNET.xUnitV3`, `TngTech.ArchUnitNET.MSTestV2`, or `TngTech.ArchUnitNET.TUnit`503. Add at least one durable boundary rule test.514. Wire architecture tests into the standard `test` command in `AGENTS.md` and CI.525. Run `dotnet test TEST_PROJECT.csproj` and return `status: configured` or `status: improved`.536. If `NetArchTest` already covers the same boundary policy and no gap exists, return `status: not_applicable`.545556## Deliver5758- architecture tests with richer domain and type modeling59- architecture-rule commands wired into repo test flow and CI expectations6061## Validate6263- architecture load cost is reasonable for the suite64- rules are stable and tied to real boundaries6566## Ralph Loop6768Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.69701. Plan first (mandatory):71 - analyze current state72 - define target outcome, constraints, and risks73 - write a detailed execution plan74 - list final validation skills to run at the end, with order and reason752. Execute one planned step and produce a concrete delta.763. Review the result and capture findings with actionable next fixes.774. Apply fixes in small batches and rerun the relevant checks or review steps.785. Update the plan after each iteration.796. Repeat until outcomes are acceptable or only explicit exceptions remain.807. If a dependency is missing, bootstrap it or return `status: not_applicable` with explicit reason and fallback path.8182### Required Result Format8384- `status`: `complete` | `clean` | `improved` | `configured` | `not_applicable` | `blocked`85- `plan`: concise plan and current iteration step86- `actions_taken`: concrete changes made87- `validation_skills`: final skills run, or skipped with reasons88- `verification`: commands, checks, or review evidence summary89- `remaining`: top unresolved items or `none`9091For setup-only requests with no execution, return `status: configured` and exact next commands.9293## Load References9495- read `references/archunitnet.md` first9697## Example Requests9899- "Use ArchUnitNET for layered architecture tests."100- "Set up ArchUnitNET with xUnit or MSTest."