create-agent-dotnet

Files (2)

• REFERENCE.md
• SKILL.md

SKILL.md (first lines)

# Create a .NET Agent Application

## Overview

This skill describes how to create a durable AI agent application in .NET.

> **On naming.** [Dapr Agents](https://github.com/dapr/dapr-agents) is a **Python-only** framework and is not used here. The .NET path is [Microsoft Agent Framework](https://learn.microsoft.com/en-us/agent-framework/) (`Microsoft.Agents.AI` + `Microsoft.Extensions.AI`) executed durably on Dapr Workflow by the [`Diagrid.AI.Microsoft.AgentFramework`](https://www.nuget.org/packages/Diagrid.AI.Microsoft.AgentFramework) package. That package turns every LLM call and every tool call into its own workflow activity, so an agent run survives a process restart and resumes from the last completed step. The `Dapr` in `AddDaprAgents()` / `IDaprAgentInvoker` names that workflow runtime — it is not the Python framework.

The LLM is reached through a Dapr [conversation component](https://docs.dapr.io/reference/components-reference/supported-conversation/), not through a provider SDK registered in DI. Swapping providers is a YAML change, not a code change.

Observability: the Dapr sidecar emits workflow and conversation metrics and traces (see [`../dapr-shared/agent-metrics-prometheus.md`](../dapr-shared/agent-metrics-prometheus.md)). The package creates no spans or metrics of its own, but it sets W3C baggage (`agent.name`, `tool.name`, …) inside LLM and tool activities and logs prompts and tool arguments at `Debug` level. See "Observability" in `REFERENCE.md`.

## Execution Order

You MUST follow these phases in strict order:
1. **Check specification** — Check if the user specified what needs to be built.
2. **Check optional tools** — Check whether the Diagrid Dapr Dev Dashboard is installed and remember the result. Never stop, ask or install for this.
3. **Project Setup** — Create all files and folders.
4. **Verify** — Verify that the project builds.
5. **Create README.md** — Create a readme that summarizes what is built and how to run & test the application. Do not provide instructions at the end of this phase.
6. **Show final message** — Your LAST output MUST be EXACTLY the message defined in the `## Show final message` section: the closing sentence followed by the Dev Dashboard recommendation. Do NOT add any other text, summary, or commentary.

## Check specification

If you don't have enough context what to build, ask the user the following clarifying questions one by one using an interview style:

1. What is the purpose of the agent? This becomes the agent's instructions.
2. Topology: single agent, or coordinator + N specialists? (Coordinator + specialists runs all agents in one app, orchestrated by a Dapr Workflow, unless the user explicitly needs the specialists as separately deployed apps.)
3. Tool definitions: name, purpose, and argument schema for each tool.
4. LLM provider: OpenAI (default), Anthropic, Google AI (Gemini), or Ollama — this selects the conversation component.
5. Project name — used as folder and solution name. Don't use spaces.

## Prerequisites

The following must be installed by the user before this skill can run:

- [.NET 10 SDK](https://dotnet.microsoft.com/en-us/download)
- [Docker](https://www.docker.com/products/docker-desktop/) or [Podman](https://podman.io/docs/installation)
- [Dapr CLI](https://docs.dapr.io/getting-started/install-dapr-cli/) (version 1.18+)
- The API key for the chosen provider (`OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, `GOOGLE_API_KEY`) exported in the shell, or a local Ollama instance

Additional runtime dependencies (handled during project setup):

- NuGet package [`Diagrid.AI.Microsoft.AgentFramework`](https://www.nuget.org/packages/Diagrid.AI.Microsoft.AgentFramework) version `1.2.0` (multi-targets `net8.0`, `net9.0`, `net10.0`). It brings `Microsoft.Agents.AI`, `Microsoft.Extensions.AI`, `Dapr.Workflow` and the Dapr conversation/state clients transitively — do not add those at lower versions.
- Coordinator + specialists only: NuGet package `Dapr.Workflow` version `1.18.10`, referenced explicitly because the app defines its own workflow.
- License: the package is licensed under the Business Source License 1.1; production use without a commercial license is limited by its Additional Use Grant (see "License and usage analytics" in `REFERENCE.md`). Tell the user this in the generated README.

Optional, for inspecting workflow runs locally:

- Optional: the [Diagrid Dapr Dev Dashboard](https://github.com/diagridio/dev-dashboard) for inspecting workflow runs locally. The skill only checks whether it is installed (see `## Check optional tools`); it never installs it and never stops without it.

## Check optional tools

Check once whether the optional [Diagrid Dapr Dev Dashboard](https://github.com/diagridio/dev-dashboard) is installed by following the **Check** section of [`../dapr-shared/dev-dashboard.md`](../dapr-shared/dev-dashboard.md) (`diagrid-dev-dashboard --version`). Remember the result (`DevDashboardInstalled`) for the final message. This check never stops the skill: do not ask the user about it, do not install anything, and continue with the next step whether or not the dashboard is installed.

## Project Setup

Create the project root folder and a new ASP.NET Core web application inside it:

```shell
mkdir <ProjectRoot>
cd <ProjectRoot>
dotnet new web -n <ProjectName>
dotnet add <ProjectName> package Diagrid.AI.Microsoft.AgentFramework --version 1.2.0
```

The <ProjectName> should start with the <ProjectRoot> and end with `App`: <ProjectRoot>App.

### Folder structure (single agent)

```
<ProjectRoot>/
├── .gitignore
├── dapr.yaml
├── local.http
├── resources/
│   ├── agent-workflow.yaml
│   └── llm-provider.yaml
└── <ProjectName>/
    ├── <ProjectName>.csproj
    ├── Program.cs
    ├── Properties/
    │   └── launchSettings.json
    ├── Models/
    │   └── AgentContracts.cs
    └── Tools/
        └── <ToolName>Tools.cs
```

### Folder structure (coordinator + specialists)

All agents run in **one app**; a Dapr Workflow coordinates them. Same as above, plus a `Workflows/` folder and one tools file per specialist:

```
<ProjectRoot>/
├── .gitignore
├── dapr.yaml
├── local.http
├── resources/
│   ├── agent-workflow.yaml
│   └── llm-provider.yaml
└── <ProjectName>/
    ├── <ProjectName>.csproj
    ├── Program.cs
    ├── Properties/
    │   └── launchSettings.json
    ├── Models/
    │   └── AgentContracts.cs
    ├── Workflows/
    │   └── PlanWorkflow.cs
    └── Tools/
        └── <SpecialistName>Tools.cs
```

No `agent-pubsub.yaml` is needed. Only if the user explicitly needs the specialists as separately deployed apps, create one project per app instead (see "Alternative: specialists as separate apps" in `REFERENCE.md`).

**Port assignment (separate apps only).** Each app needs a unique `applicationUrl` in `Properties/launchSettings.json` and a matching `appPort` in `dapr.yaml`. Assign ports in sequence: `5100` for the coordinator, `5101` for the first specialist, `5102` for the second, and so on. Also bump `daprHTTPPort` (`3500`, `3501`, `3502`, …) and `daprGRPCPort` (`50001`, `50002`, `50003`, …) to match. Port collisions are the most common bring-up error in multi-app setups.

### .gitignore

From diagrid-labs/dapr-skills, MIT.

More from diagrid-labs/dapr-skills