cto/skills/cto-dotnet-toolkit/SKILL.md
2026-05-25 12:57:33 -04:00

4.4 KiB

name description metadata
cto-dotnet-toolkit Use when the user mentions '.NET', 'C#', 'CQRS', 'Minimal API', 'gRPC', 'FluentValidation', 'dotnet build', 'dotnet test', or the target stack identified by cto-agent is .NET/C#. Encodes Plan B .NET CQRS patterns, direct WebUI coding gates, and Sandcastle prompt requirements anchored to cortex/L6-svrnty.lib-dotnet-cqrs and related tools.
version model hermes tier status owner source last_reviewed
0.1.0 qwen-local/qwen3.6-35b-a3b
requires_toolsets
terminal
memory_tool
T2 active jp hand 2026-05-25

CTO .NET Toolkit — CQRS + Verification Patterns

Karpathy 4 Rules

  1. Think Before Coding — identify the project, target bounded context, generated files, test surface, and approval risks before editing.
  2. Simplicity First — follow the existing CQRS/Minimal API/gRPC patterns before adding abstractions or packages.
  3. Surgical Changes — touch only task-owned handlers, validators, contracts, tests, or generated artifacts explicitly in scope.
  4. Goal-Driven Execution — finish only after dotnet build, relevant dotnet test, diff inspection, and skipped-check reporting.

When CTO Routes Here

  • The repo contains .sln, .csproj, Directory.Build.props, global.json, or *.proto files tied to C# generation.
  • The task mentions .NET, C#, CQRS, Minimal API, gRPC, FluentValidation, DTCG, DESIGN.md export, or BTE.
  • cto-agent detects a .NET backend or a task spanning .NET backend plus Angular/Flutter clients.

Canonical Plan B References

Reference Use
../../cortex/L6-svrnty.lib-dotnet-cqrs CQRS framework, .NET 10 project layout, handler/validator conventions, gRPC source-gen patterns.
../../cortex/L5-svrnty.tool-cqrs-plugin Scaffolding patterns for commands, queries, validators, endpoints, and tests.
../../cortex/pi-bte-plugin BTE linting, DTCG validation, DESIGN.md export, contrast checks, and .NET build verification.
../../cortex/PG-svrnty.lib-quality-gates Optional broader gates for C#/proto/docker quality where available.

Read the target repo first. Use these references as patterns, not as copy-paste sources.

Direct WebUI Coding Loop

For scoped R1/R2 .NET work:

  1. Inspect solution/project files and identify the owning bounded context.
  2. Search with rg for existing handler, endpoint, validator, and test patterns.
  3. Patch minimal files using Hermes patch.
  4. Run focused verification first:
    • dotnet build <project-or-sln>
    • dotnet test <test-project> --no-restore when restore/build already ran
  5. Broaden for shared behavior:
    • dotnet test <solution>
    • proto/design-token validation if contracts changed
  6. Run git diff --check and inspect changed files before reporting.

Sandcastle Background Pattern

Use Sandcastle for broad migrations, generated-code changes, dependency upgrades, or multi-project refactors. The prompt must include:

  • Target solution/project path.
  • Allowed write scope.
  • Generated-file policy.
  • Required dotnet build and dotnet test commands.
  • CQRS reference paths from this skill.
  • Branch strategy cto/<work-id>.
  • No noSandbox or branchStrategy: head without JP approval.

Verification Matrix

Change Required verification
Handler/query/command logic Focused unit/integration test plus dotnet build.
Validator rules Validator tests or API request fixture plus dotnet test.
Minimal API endpoint Endpoint test or documented manual local request plus build.
gRPC/proto contract Regenerate code, build server and affected client, inspect generated files.
DTCG/DESIGN.md/BTE output Run BTE lint/export command and validate generated artifact shape.
Package change Review lock/generated changes, run build/test, note approval status for major upgrades.

Anti-Patterns

  • Do not invent a new CQRS shape when an existing handler/validator pattern exists.
  • Do not edit generated obj/, bin/, or generated proto output by hand unless the task explicitly scopes generated artifacts.
  • Do not bump .NET SDK, NuGet major versions, or shared framework packages without JP approval.
  • Do not let tests hit production/staging services; ambiguous environment targets require approval.
  • Do not claim build/test success without command output evidence.
  • ../cto-agent/SKILL.md
  • ../cto-direct-coder/SKILL.md
  • ../cto-reviewer/SKILL.md
  • ../cto-sandbox-job/SKILL.md