PluginBench
Skill
Pass
Audit score 90

project-setup

codewithmukesh/dotnet-claude-kit

Tech-stack selection advisor for .NET projects with recommended defaults and rationale.

What is project-setup?

Recommends defaults for database, auth, caching, messaging, observability, and resilience in .NET projects, with trade-off explanations. Load when choosing or reviewing a tech stack, or when the user asks about database, auth, caching, or similar infrastructure decisions.

  • Provides recommended defaults across 8 tech-stack dimensions (database, auth, caching, messaging, observability, resilience, API docs, testing)
  • Explains the rationale and trade-offs for each default choice
  • Prioritizes built-in .NET features and MIT-licensed alternatives over commercial packages
  • Routes to specialized skills (dotnet-init, health-check, migrate, architecture-advisor) for workflows outside tech-stack selection
  • Avoids prescribing a stack without context; asks about organizational constraints first

How to install project-setup

npx skills add https://github.com/codewithmukesh/dotnet-claude-kit --skill project-setup
Claude Code
Cursor
Windsurf
Cline

How to use project-setup

  1. 1.Reference the tech-stack dimensions table when a user asks about database, auth, caching, messaging, observability, resilience, API docs, or testing choices
  2. 2.Present the kit default, explain the why in one line, and ask about organizational constraints that might override it
  3. 3.Route to dotnet-init if the user is initializing a project, health-check for codebase assessment, migrate for upgrades, or architecture-advisor for architecture questions
  4. 4.Do not re-run workflows owned by other skills; defer to the canonical owner

Use cases

Good for
  • Deciding between PostgreSQL, SQL Server, or SQLite for a new .NET project
  • Choosing between JWT Bearer, OIDC, or no auth for an API
  • Evaluating whether to use HybridCache, Redis, or no caching layer
  • Determining if a message bus (Wolverine, MassTransit) is needed now or later
  • Selecting observability tools (Serilog + OpenTelemetry vs. basic logging)
Who it's for
  • Architects designing new .NET projects
  • Teams reviewing or upgrading existing tech stacks
  • Developers onboarding to a .NET codebase and learning its infrastructure choices
  • Teams evaluating open-source vs. commercial tooling trade-offs

project-setup FAQ

When should I add a message bus like Wolverine?

The kit default is 'None (add later)' because most projects don't need async messaging on day one. Reach for Wolverine when actual async workflows appear, not speculatively.

Why PostgreSQL over SQL Server?

PostgreSQL is open source and has the best EF Core provider outside SQL Server, plus first-class Testcontainers support. Use SQL Server if your organization has existing licenses or DBA support.

Should I use Redis or HybridCache?

Start with HybridCache (built-in, stampede protection, L1+L2 caching). Add Redis only as its L2 backend when you need distributed caching across multiple instances.

Why Serilog + OpenTelemetry from day one?

Structured logs and traces are cheap to add upfront but expensive to retrofit. One-line setup with Serilog and OpenTelemetry gives production-grade observability from the start.

What if my team uses MassTransit or MediatR instead of the kit defaults?

Defaults are starting points, not mandates. The kit prefers MIT alternatives (Wolverine, Mediator) to avoid commercial licensing surprises, but your team's existing expertise and constraints may justify a different choice.

Full instructions (SKILL.md)

Source of truth, from codewithmukesh/dotnet-claude-kit.


name: project-setup description: > Tech-stack selection advisor for .NET projects: recommended defaults for database, auth, caching, messaging, observability, and resilience, with the rationale behind each default. Load when choosing or reviewing a project's tech stack, or when the user says "tech stack", "which database", "pick a stack", "recommended defaults", or "what should I use for". For project initialization use dotnet-init, for codebase assessment use health-check, for upgrades and schema changes use migrate.

Project Setup — Tech-Stack Advisor

This skill owns one thing: the kit's recommended tech-stack defaults and why. The workflows that consume it live elsewhere:

  • Initializing a project / generating CLAUDE.md → dotnet-init (interactive flow, architecture questionnaire, CLAUDE.md generation)
  • Assessing an existing codebase → health-check (the canonical 8-dimension graded assessment)
  • EF Core schema, NuGet, or .NET version migrations → migrate
  • Choosing an architecture → architecture-advisor (always ask before recommending)

Core Principles

  1. Recommend a default, explain the why, let the user choose — Every dimension has a kit default, but defaults are starting points, not mandates. State the trade-off in one line so the choice is informed.
  2. Prefer built-in .NET over third-party — HybridCache over Redis-client wrappers, built-in rate limiting over packages, built-in OpenAPI over Swashbuckle. Fewer dependencies means fewer licensing surprises and upgrade breaks.
  3. License-aware picks — MediatR (v13+), MassTransit (v9+), and FluentAssertions (v8+) went commercial. The kit defaults to MIT alternatives: Mediator, Wolverine, plain xUnit asserts.
  4. Add messaging later, not never — Most projects don't need a message bus on day one. Default to "None (add later)" and reach for Wolverine when async workflows actually appear.

Patterns

Tech-Stack Dimensions and Defaults

DimensionOptionsDefaultWhy
DatabasePostgreSQL, SQL Server, SQLitePostgreSQLOpen source, best EF Core provider outside SQL Server, first-class Testcontainers support
AuthJWT Bearer, OIDC (Keycloak/Auth0), NoneJWT BearerSimplest secure default for APIs; move to OIDC when an external IdP exists
CachingHybridCache, Redis, NoneHybridCacheBuilt-in, stampede protection, L1+L2 — add Redis only as its L2 backend
MessagingWolverine (RabbitMQ), MassTransit, NoneNone (add later)Premature messaging adds ops burden; Wolverine (MIT) when needed
ObservabilitySerilog + OpenTelemetry, Basic loggingSerilog + OTELStructured logs + traces from day one are cheap; retrofitting is not
ResiliencePolly v8 pipelines, Basic retryPolly v8AddStandardResilienceHandler() is one line for production-grade defaults
API docsBuilt-in OpenAPI + ScalarOpenAPI + ScalarFramework-maintained spec generation; Scalar replaces Swagger UI
TestingxUnit v3 + TestcontainersxUnit v3 + TestcontainersReal databases in tests; in-memory providers hide real bugs

Once dimensions are chosen, dotnet-init bakes them into the generated CLAUDE.md, and each choice maps to a skill to load when working in that area (ef-core, authentication, caching, messaging, serilog, opentelemetry, resilience, openapi, scalar, testing).

Anti-patterns

Prescribing a Stack Without Asking

# BAD — assuming the kit defaults apply everywhere
"You should use PostgreSQL and Wolverine."
# The team runs SQL Server enterprise-wide and has zero async workflows.

# GOOD — default + trade-off + question
"Kit default is PostgreSQL (best OSS EF provider). Any organizational
constraint — existing SQL Server licenses, DBA support — that should
override it?"

Re-Running Workflows This Skill Doesn't Own

# BAD — improvising a health grading or init flow from this skill
"Let me grade your codebase across 5 categories..."
# That grading conflicts with the canonical one.

# GOOD — route to the owner
Init/CLAUDE.md → dotnet-init | Assessment → health-check | Upgrades → migrate

Decision Guide

ScenarioRoute to
"Set up this project for Claude Code"dotnet-init
"Which database/auth/caching should I use?"This skill — table above
"How healthy is this codebase?"health-check
"Upgrade to .NET 10" / "update packages"migrate
"Which architecture fits?"architecture-advisor
Stack chosen, ready to buildscaffold for the first feature