> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dotbot.ch/llms.txt
> Use this file to discover all available pages before exploring further.

# Add technology stacks to your dotbot project

> Install built-in stacks like dotnet and dotnet-blazor, understand stack inheritance via extends, compose multiple stacks, and see how settings merge.

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](/reference/mcp-tools/stack-and-workflow-tools) for the full reference.
* **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 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

<Note>
  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.
</Note>

## Installing stacks

<Tabs>
  <Tab title="Single stack">
    Install one stack during project initialisation:

    ```powershell theme={null}
    dotbot init -Stack dotnet
    ```
  </Tab>

  <Tab title="Multiple stacks">
    Install several stacks at once with a comma-separated list:

    ```powershell theme={null}
    dotbot init -Stack dotnet-blazor,dotnet-ef
    ```
  </Tab>

  <Tab title="Stack with a workflow">
    Combine a workflow and one or more stacks in a single command:

    ```powershell theme={null}
    dotbot init -Workflow start-from-jira -Stack dotnet
    ```
  </Tab>

  <Tab title="After initialisation">
    Add a stack to an already-initialised project by re-running `dotbot init` with the `-Stack` flag:

    ```powershell theme={null}
    dotbot init -Stack dotnet-ef
    ```
  </Tab>
</Tabs>

## How settings from stacks merge with workflow settings

dotbot merges settings in this order, with each layer able to override the previous:

```
default → workflows → stacks
```

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.

| Tool          | Purpose                                                                                                                                                  |
| ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `dev_db`      | Query the project's SQLite database read-only. Lists tables when called with no query, or runs a supplied query against the `dev` or `prod` environment. |
| `dev_deploy`  | Trigger a production deployment after verifying the git state is clean and pushed. Auto-increments the version with a `major`, `minor`, or `patch` bump. |
| `dev_logs`    | View logs from the local dev environment or the deployed instance, filtered by log level and line count, with an optional follow mode.                   |
| `dev_release` | Start the development environment in Release mode for local production testing.                                                                          |
| `prod_start`  | Start the production container, optionally pulling the latest image first.                                                                               |
| `prod_stop`   | Stop the production container, gracefully or forced.                                                                                                     |

<Note>
  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](/reference/mcp-tools/stack-and-workflow-tools).
</Note>

## 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            |

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.

<Tip>
  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.
</Tip>