.NET Application Solution Setup (Codebelt Conventions)

Scaffold new .NET standalone application solutions following the codebeltnet engineering conventions — the same pattern used across codebeltnet. Produces a fully wired solution with CI pipeline, centralized build config, semantic versioning, code quality tooling, and proper folder structure.

CRITICAL: All application projects must use the Codebelt.Bootstrapper.* framework — never vanilla WebApplication.CreateBuilder() or raw Host.CreateDefaultBuilder(). The bootstrapper provides a uniform, convention-driven Program.cs (and Startup.cs for classic hosting). The asset templates in assets/app/ already wire this up correctly — always copy from templates, never write Program.cs from scratch.

If a generated app fails because a bootstrapper type from the copied asset template does not resolve, first verify the copied template imports the correct Codebelt.Bootstrapper.* namespace and that the matching package reference is present. If the bootstrapper type still cannot be resolved, halt and report the template/package mismatch. Do not substitute vanilla .NET hosting code as a workaround.

Scope

This skill produces a complete solution scaffold — project structure, build config, CI pipeline, governance docs, and bootstrapper-wired entry points. It does not generate application logic (endpoints, services, controllers, middleware). The scaffold is the foundation; the user adds their code on top.

Generate the scaffold in the user's current working directory. Do not create an extra top-level {REPO_SLUG} or {SOLUTION_NAME} folder unless the user explicitly asks for a nested output folder.

Non-Negotiable Output Contract

The scaffold is incomplete unless it produces all required artifacts for the selected host types. These are not optional, and they must not be silently skipped:

• the solution file named {SOLUTION_NAME}.slnx with the original user-facing casing preserved