← ClaudeAtlas

scaffoldlisted

Scaffold a complete feature slice matching the repo's existing architecture — request/command type, handler, validator, DTOs, DI registration, and tests — never a half-feature. Use for "scaffold", "create feature", "add command", "add query", "new endpoint", "add validator", "generate feature".
lamuniercosta/dotnet-agent-harness · ★ 0 · AI & Automation · score 75
Install: claude install-skill lamuniercosta/dotnet-agent-harness
# Scaffold Adapted from [codewithmukesh/dotnet-claude-kit](https://github.com/codewithmukesh/dotnet-claude-kit) (MIT). ## What Generates a complete, consistent feature slice — **never half a feature**. Every scaffold includes the request type, its handler, a validator (when input needs validating), DI registration, and at least one test at the right seam. It **matches the repo's existing architecture rather than imposing one**. This skill has no preferred architecture: CQRS handlers, minimal-API endpoints, MediatR, vertical slices, and layered services are all fine — whichever the repo already uses. Consistency with the neighbouring code beats any pattern this skill could recommend. ## When - "Scaffold / create / add" a command, query, endpoint, validator, or processing step - Starting a new feature after `/speckit-tasks`, or during `/implement` - Any time you want a working skeleton wired into DI and tests ## How ### Step 1 — Learn the architecture (never skip) Run `/convention-learner`, or at minimum read the **two nearest siblings** to what you're adding. Determine and write down: - The organising principle — layered, vertical slice, or modular monolith - The dispatch mechanism — hand-rolled `ICommandHandler`, MediatR `IRequestHandler`, direct minimal-API delegates, controller actions - Where DI registration lives, and whether it is manual or assembly-scanned - Naming and access conventions — `sealed`, interface-in-same-file, suffixes, `CancellationToken ct = def