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
- 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.
- 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.
- License-aware picks — MediatR (v13+), MassTransit (v9+), and FluentAssertions (v8+) went commercial. The kit defaults to MIT alternatives: Mediator, Wolverine, plain xUnit asserts.
- 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
| Dimension |
Options |
Default |
Why |
| Database |
PostgreSQL, SQL Server, SQLite |
PostgreSQL |
Open source, best EF Core provider outside SQL Server, first-class Testcontainers support |
| Auth |
JWT Bearer, OIDC (Keycloak/Auth0), None |
JWT Bearer |
Simplest secure default for APIs; move to OIDC when an external IdP exists |
| Caching |
HybridCache, Redis, None |
HybridCache |
Built-in, stampede protection, L1+L2 — add Redis only as its L2 backend |
| Messaging |
Wolverine (RabbitMQ), MassTransit, None |
None (add later) |
Premature messaging adds ops burden; Wolverine (MIT) when needed |
| Observability |
Serilog + OpenTelemetry, Basic logging |
Serilog + OTEL |
Structured logs + traces from day one are cheap; retrofitting is not |
| Resilience |
Polly v8 pipelines, Basic retry |
Polly v8 |
AddStandardResilienceHandler() is one line for production-grade defaults |
| API docs |
Built-in OpenAPI + Scalar |
OpenAPI + Scalar |
Framework-maintained spec generation; Scalar replaces Swagger UI |
| Testing |
xUnit v3 + Testcontainers |
xUnit v3 + Testcontainers |
Real 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
| Scenario |
Route 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 build |
scaffold for the first feature |
1---
2name: project-setup
3description: >
4 Tech-stack selection advisor for .NET projects: recommended defaults for
5 database, auth, caching, messaging, observability, and resilience, with the
6 rationale behind each default. Load when choosing or reviewing a project's
7 tech stack, or when the user says "tech stack", "which database", "pick a
8 stack", "recommended defaults", or "what should I use for". For project
9 initialization use dotnet-init, for codebase assessment use health-check,
10 for upgrades and schema changes use migrate.
11---
12
13# Project Setup — Tech-Stack Advisor
14
15This skill owns one thing: the kit's recommended tech-stack defaults and why. The workflows that consume it live elsewhere:
16
17- **Initializing a project / generating CLAUDE.md** → `dotnet-init` (interactive flow, architecture questionnaire, CLAUDE.md generation)
18- **Assessing an existing codebase** → `health-check` (the canonical 8-dimension graded assessment)
19- **EF Core schema, NuGet, or .NET version migrations** → `migrate`
20- **Choosing an architecture** → `architecture-advisor` (always ask before recommending)
21
22## Core Principles
23
241. **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.
252. **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.
263. **License-aware picks** — MediatR (v13+), MassTransit (v9+), and FluentAssertions (v8+) went commercial. The kit defaults to MIT alternatives: Mediator, Wolverine, plain xUnit asserts.
274. **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.
28
29## Patterns
30
31### Tech-Stack Dimensions and Defaults
32
33| Dimension | Options | Default | Why |
34|-----------|---------|---------|-----|
35| Database | PostgreSQL, SQL Server, SQLite | PostgreSQL | Open source, best EF Core provider outside SQL Server, first-class Testcontainers support |
36| Auth | JWT Bearer, OIDC (Keycloak/Auth0), None | JWT Bearer | Simplest secure default for APIs; move to OIDC when an external IdP exists |
37| Caching | HybridCache, Redis, None | HybridCache | Built-in, stampede protection, L1+L2 — add Redis only as its L2 backend |
38| Messaging | Wolverine (RabbitMQ), MassTransit, None | None (add later) | Premature messaging adds ops burden; Wolverine (MIT) when needed |
39| Observability | Serilog + OpenTelemetry, Basic logging | Serilog + OTEL | Structured logs + traces from day one are cheap; retrofitting is not |
40| Resilience | Polly v8 pipelines, Basic retry | Polly v8 | `AddStandardResilienceHandler()` is one line for production-grade defaults |
41| API docs | Built-in OpenAPI + Scalar | OpenAPI + Scalar | Framework-maintained spec generation; Scalar replaces Swagger UI |
42| Testing | xUnit v3 + Testcontainers | xUnit v3 + Testcontainers | Real databases in tests; in-memory providers hide real bugs |
43
44Once 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`).
45
46## Anti-patterns
47
48### Prescribing a Stack Without Asking
49
50```
51# BAD — assuming the kit defaults apply everywhere
52"You should use PostgreSQL and Wolverine."
53# The team runs SQL Server enterprise-wide and has zero async workflows.
54
55# GOOD — default + trade-off + question
56"Kit default is PostgreSQL (best OSS EF provider). Any organizational
57constraint — existing SQL Server licenses, DBA support — that should
58override it?"
59```
60
61### Re-Running Workflows This Skill Doesn't Own
62
63```
64# BAD — improvising a health grading or init flow from this skill
65"Let me grade your codebase across 5 categories..."
66# That grading conflicts with the canonical one.
67
68# GOOD — route to the owner
69Init/CLAUDE.md → dotnet-init | Assessment → health-check | Upgrades → migrate
70```
71
72## Decision Guide
73
74| Scenario | Route to |
75|----------|----------|
76| "Set up this project for Claude Code" | `dotnet-init` |
77| "Which database/auth/caching should I use?" | This skill — table above |
78| "How healthy is this codebase?" | `health-check` |
79| "Upgrade to .NET 10" / "update packages" | `migrate` |
80| "Which architecture fits?" | `architecture-advisor` |
81| Stack chosen, ready to build | `scaffold` for the first feature |
codewithmukesh