How do I install the Validation Scopes skill?

Run npx skillmds@latest add atherio-danp/validation-scopes in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Validation Scopes safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Validation Scopes?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Validation Scopes free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Validation Scopes?

atherio-danp (@atherio-danp) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Validation Scopes by atherio-danp — Agent Skill

Name: Validation Scopes
Author: atherio-danp

Validation Scopes

Place validation in the correct one of our three scopes in the .NET API — API contract (no DB), Application business via Kommand IValidator, or Domain invariants that throw. Use when adding any validation/guard, or deciding where a check belongs.

atherio-danp 1fb31d5 3.1 KB Updated Sep 17, 2026

File contents

Serena MCP is mandatory for C# code. First call mcp__serena__initial_instructions to load the Serena tool manual, then use the Serena tools for ALL .cs reading / searching / navigation / creation / editing — prefer symbol navigation (get_symbols_overview / find_symbol / find_referencing_symbols) over whole-file reads. Native Edit/Write on .cs is hook-blocked (the TS/React frontend uses the native tools).

Validation — the three scopes

Validation is three distinct concerns; put each check in the right one. Source of truth (the facts — read them): .claude/rules/backend/api-design.md (§4.1), cqrs-kommand.md, domain-model.md, and docs/projectStandards/backend-architecture.md §4.1. We do NOT use FluentValidation or any validation library. C# (.cs) edits via Serena.

Scope	Where	Validates	On failure
Contract	API endpoint, before dispatch	request shape, required fields, types, and access control inferable from the JWT/cookie	reject → ProblemDetails; never reaches a handler. No DB calls.
Business	Application — a Kommand `IValidator<T>` on the command/query	rules needing data/understanding ("is this buyer ≥18 for alcohol?")	a failed `Result` (`Error.Validation(failures)`) → `ValidationProblemDetails`
Invariant	Domain entity factories/methods	an object can never be created or mutated into an invalid state	throw; the handler catches and folds into `Result.Failure`

Procedure — placing a check

Is it pure shape / required-field / JWT-derivable authz, with no DB? → Contract (API). Hand-roll the check in the endpoint (or a small reusable guard); short-circuit to ProblemDetails before dispatching.
Does it need data or business understanding? → Business. Add a IValidator<T> beside the command/query (co-located in Commands//Queries/, named …Validator). Surface failures as a failed Result — prefer a validation interceptor that returns the failed Result<T> over Kommand's throwing default (see cqrs-kommand reference/patterns.md).
Is it an invariant that must hold for the object to exist or change? → Invariant. Enforce it inside the domain factory/method and throw (use the add-domain-entity skill). Never rely on outer layers to keep the domain valid — it's the last line of defence.

Don'ts

Don't repeat the same rule across scopes (e.g. re-checking a business rule in the handler that the IValidator already guarantees) — each rule lives in exactly one scope.
Don't do DB work in contract validation; don't put business logic in the endpoint.
Failures become Result/ProblemDetails (see the result-pattern skill), not ad-hoc exceptions at the boundary.

---name: validation-scopesdescription: Place validation in the correct one of our three scopes in the .NET API — API contract (no DB), Application business via Kommand IValidator, or Domain invariants that throw. Use when adding any validation/guard, or deciding where a check belongs.---> **Serena MCP is mandatory for C# code.** First call `mcp__serena__initial_instructions` to load the Serena tool manual, then use the Serena tools for ALL `.cs` reading / searching / navigation / creation / editing — prefer symbol navigation (`get_symbols_overview` / `find_symbol` / `find_referencing_symbols`) over whole-file reads. Native `Edit`/`Write` on `.cs` is hook-blocked (the TS/React frontend uses the native tools).# Validation — the three scopesValidation is **three distinct concerns**; put each check in the right one. Source of truth (the *facts* —read them): `.claude/rules/backend/api-design.md` (§4.1), `cqrs-kommand.md`, `domain-model.md`, and`docs/projectStandards/backend-architecture.md` §4.1. **We do NOT use FluentValidation or any validationlibrary.** C# (`.cs`) edits via **Serena**.| Scope | Where | Validates | On failure ||---|---|---|---|| **Contract** | API endpoint, *before* dispatch | request shape, required fields, types, and access control inferable from the **JWT/cookie** | reject → **ProblemDetails**; never reaches a handler. **No DB calls.** || **Business** | Application — a Kommand **`IValidator<T>`** on the command/query | rules needing data/understanding ("is this buyer ≥18 for alcohol?") | a **failed `Result`** (`Error.Validation(failures)`) → `ValidationProblemDetails` || **Invariant** | Domain entity factories/methods | an object can never be **created or mutated** into an invalid state | **throw**; the handler catches and folds into `Result.Failure` |## Procedure — placing a check1. **Is it pure shape / required-field / JWT-derivable authz, with no DB?** → **Contract** (API). Hand-roll the check in the endpoint (or a small reusable guard); short-circuit to ProblemDetails before dispatching.2. **Does it need data or business understanding?** → **Business**. Add a `IValidator<T>` beside the command/query (co-located in `Commands/`/`Queries/`, named `…Validator`). Surface failures as a failed `Result` — prefer a validation interceptor that returns the failed `Result<T>` over Kommand's throwing default (see `cqrs-kommand` `reference/patterns.md`).3. **Is it an invariant that must hold for the object to exist or change?** → **Invariant**. Enforce it inside the domain factory/method and **throw** (use the `add-domain-entity` skill). Never rely on outer layers to keep the domain valid — it's the last line of defence.## Don'ts- Don't repeat the same rule across scopes (e.g. re-checking a business rule in the handler that the `IValidator` already guarantees) — each rule lives in exactly one scope.- Don't do DB work in contract validation; don't put business logic in the endpoint.- Failures become `Result`/ProblemDetails (see the `result-pattern` skill), not ad-hoc exceptions at the boundary.

Frequently asked questions