| name | archunitnet |
|---|---|
| description | 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. USE FOR: the repo uses or wants ArchUnitNET; architecture testing needs richer modeling than simple dependency checks. DO NOT USE FOR: the lightest possible architecture rule checks. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made. |
| compatibility | Requires a .NET test project; supports dedicated integrations for xUnit, xUnit v3, MSTest, TUnit, and others where available. |
- the repo uses or wants
ArchUnitNET - architecture testing needs richer modeling than simple dependency checks
- 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
- the lightest possible architecture rule checks
- the nearest
AGENTS.md - target assemblies
- architecture boundaries and naming conventions
- Read the nearest
AGENTS.mdand confirm scope and constraints. - Run this skill's
Workflowthrough theRalph Loopuntil outcomes are acceptable. - Return the
Required Result Formatwith concrete artifacts and verification evidence.
- 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.
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, orTngTech.ArchUnitNET.TUnit
- Add at least one durable boundary rule test.
- Wire architecture tests into the standard
testcommand inAGENTS.mdand CI. - Run
dotnet test TEST_PROJECT.csprojand returnstatus: configuredorstatus: improved. - If
NetArchTestalready covers the same boundary policy and no gap exists, returnstatus: not_applicable.
- architecture tests with richer domain and type modeling
- architecture-rule commands wired into repo test flow and CI expectations
- architecture load cost is reasonable for the suite
- rules are stable and tied to real boundaries
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_applicablewith explicit reason and fallback path.
status:complete|clean|improved|configured|not_applicable|blockedplan: concise plan and current iteration stepactions_taken: concrete changes madevalidation_skills: final skills run, or skipped with reasonsverification: commands, checks, or review evidence summaryremaining: top unresolved items ornone
For setup-only requests with no execution, return status: configured and exact next commands.
- "Use ArchUnitNET for layered architecture tests."
- "Set up ArchUnitNET with xUnit or MSTest."