dotnet-blazor automatically pulls in dotnet via an extends chain, so you never install the same foundation twice.
What stacks add
Each stack can contribute any combination of the following:- Skills — Reusable prompt guidance injected into AI sessions (for example, idiomatic .NET patterns or Blazor component structure).
- Hooks — PowerShell scripts that run at dev environment start and stop.
- Verify scripts — Numbered scripts (
00-,01-, …) that run in order after each task completes. They check privacy, git cleanliness, and push status before dotbot marks a task done. - MCP tools — Additional tools exposed via the MCP server so the AI can run build commands, run migrations, or query framework-specific APIs.
- Settings overrides — Stack-specific values that deep-merge on top of the workflow defaults.
Available built-in stacks
| Stack | Extends | Description |
|---|---|---|
dotnet | — | .NET skills, hooks, dev environment, and MCP tools |
dotnet-blazor | dotnet | Blazor-specific skills, component patterns, and rendering guidance |
dotnet-ef | dotnet | Entity Framework migrations, design patterns, and database tools |
How stack inheritance works
When a stack declaresextends: dotnet, dotbot installs the parent stack first and then layers the child stack on top. You never need to install both dotnet and dotnet-blazor separately — installing dotnet-blazor is sufficient and the dotnet foundation is pulled in automatically.
This inheritance chain means:
- Skills from the parent are available alongside child skills
- Verify scripts from both stacks run in numeric order
- Settings from the child deep-merge on top of the parent’s settings
If you install both
dotnet-blazor and dotnet-ef, the shared dotnet parent is only installed once. dotbot deduplicates the inheritance graph before applying changes.Installing stacks
- Single stack
- Multiple stacks
- Stack with a workflow
- After initialisation
Install one stack during project initialisation:
How settings from stacks merge with workflow settings
dotbot merges settings in this order, with each layer able to override the previous:settings/ directory contains JSON files that patch the base settings. You only need to provide the keys you want to override — unchanged keys from earlier layers are preserved. This means a stack can, for example, set a default model or enable a specific MCP tool without replacing your workflow’s existing configuration.
Verify hooks
After each task completes, dotbot runs the verify scripts in numeric order. The default hooks are:| Script | Purpose |
|---|---|
00-privacy-scan.ps1 | Runs gitleaks to detect secrets or sensitive data in staged files |
01-git-clean.ps1 | Confirms the working tree has no uncommitted changes |
02-git-pushed.ps1 | Verifies the task branch has been pushed to the remote |
03-dotnet-build.ps1). dotbot runs all scripts from all installed stacks in numeric order, so the prefix number controls when each script fires relative to others.