Skip to main content
Stacks add technology-specific capabilities on top of dotbot’s base workflow. When you install a stack, dotbot gains skills tuned to your tech, lifecycle hooks for your dev environment, numbered verification scripts that run before every commit, and optional MCP tools that surface framework-specific operations to the AI. Stacks compose additively: 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, deploy, or query framework-specific resources. See Stack and workflow MCP tools for the full reference.
  • Settings overrides — Stack-specific values that deep-merge on top of the workflow defaults.

​
Available built-in stacks

​
How stack inheritance works

When a stack declares extends: 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

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:
The stack’s 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.

​
MCP tools added by the dotnet stack

The dotnet stack ships a set of MCP tools under content/stacks/dotnet/systems/mcp/tools/. Once the stack is installed, the AI can call these tools during a run to manage the dev and production environments. Because dotnet-blazor and dotnet-ef extend dotnet, they inherit the same tools.
Each tool declares its input schema in a metadata.json file beside its script.ps1. For the full parameter reference, see Stack and workflow MCP tools.

​
Verify hooks

After each task completes, dotbot runs the verify scripts in numeric order. The default hooks are: Stacks insert their own numbered scripts into the sequence (for example, 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.
Keep stacks focused on a single technology layer. If you need to support both Blazor and Entity Framework, install two stacks that both extend dotnet rather than one stack that does everything. This makes it easier to mix and match per project.