Help us improve
Share bugs, ideas, or general feedback.
From dapr-skills
Creates a Dapr workflow application using .NET Aspire, with sidecar orchestration, Valkey state store, and Diagrid Dev Dashboard. Invoke when user requests an Aspire workflow.
npx claudepluginhub diagrid-labs/dapr-skills --plugin dapr-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/dapr-skills:create-workflow-aspireThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill describes how to create a Dapr Workflow application using Aspire. The generated solution uses Aspire to orchestrate the Dapr sidecar, a Valkey state store, and the Diagrid Dev Dashboard as container resources.
Guides technical evaluation of code review feedback: read fully, restate for understanding, verify against codebase, respond with reasoning or pushback before implementing.
Share bugs, ideas, or general feedback.
This skill describes how to create a Dapr Workflow application using Aspire. The generated solution uses Aspire to orchestrate the Dapr sidecar, a Valkey state store, and the Diagrid Dev Dashboard as container resources.
You MUST follow these phases in strict order:
## Show final message section. Do NOT add any other text, summary, or commentary after it.If you don't have enough context what to build, ask the user the following clarifying questions one by one using an interview style:
The following must be installed by the user before this skill can run:
curl -sSL https://aspire.dev/install.sh | bash or irm https://aspire.dev/install.ps1 | iexAdditional runtime dependencies (handled during project setup):
Dapr.Workflow version 1.17.9 (ApiService)Dapr.Workflow.Versioning version 1.17.9 (ApiService)CommunityToolkit.Aspire.Hosting.Dapr version 13.0.0 (AppHost)Aspire.Hosting.Valkey version 13.3.0 (AppHost)Scaffold the solution using the Aspire CLI inside the current location where the terminal is open, then customize it for Dapr Workflow.
IMPORTANT: Always include --non-interactive and --test-framework none in the aspire new command below. Omitting either flag causes the command to block waiting for user input, which breaks skill execution.
aspire new aspire-starter -n <SolutionRoot> -o <SolutionRoot> --non-interactive --test-framework none
After scaffolding:
<SolutionRoot>.Web project is not needed. Delete the <SolutionRoot>.Web folder and remove its project reference from <SolutionRoot>.AppHost.csproj and the .sln file.<SolutionRoot> folder (do NOT cd elsewhere between commands, as the working directory persists across Bash calls and will break subsequent file operations that use relative paths):
dotnet add <SolutionRoot>.ApiService/<SolutionRoot>.ApiService.csproj package Dapr.Workflow --version 1.17.9
dotnet add <SolutionRoot>.ApiService/<SolutionRoot>.ApiService.csproj package Dapr.Workflow.Versioning --version 1.17.9
dotnet add <SolutionRoot>.AppHost/<SolutionRoot>.AppHost.csproj package CommunityToolkit.Aspire.Hosting.Dapr --version 13.0.0
dotnet add <SolutionRoot>.AppHost/<SolutionRoot>.AppHost.csproj package Aspire.Hosting.Valkey --version 13.3.0
REFERENCE.md for complete code.<SolutionRoot>/
├── .aspire/
│ └── settings.json
├── .gitignore
├── <SolutionRoot>.sln
├── <SolutionRoot>.ApiService/
│ ├── <SolutionRoot>.ApiService.csproj
│ ├── <SolutionRoot>.ApiService.http
│ ├── Program.cs
│ ├── appsettings.json
│ ├── appsettings.Development.json
│ ├── Properties/
│ │ └── launchSettings.json
│ ├── Models/
│ │ └── <ModelName>.cs
│ ├── Workflows/
│ │ └── <WorkflowName>.cs
│ └── Activities/
│ └── <ActivityName>.cs
├── <SolutionRoot>.AppHost/
│ ├── <SolutionRoot>.AppHost.csproj
│ ├── AppHost.cs
│ ├── appsettings.json
│ ├── appsettings.Development.json
│ ├── Properties/
│ │ └── launchSettings.json
│ └── Resources/
│ ├── statestore.yaml
│ └── statestore-dashboard.yaml
└── <SolutionRoot>.ServiceDefaults/
├── <SolutionRoot>.ServiceDefaults.csproj
└── Extensions.cs
Visual Studio style .gitignore file in the solution root. Ignores build output (bin, obj), debug/release folders, and other common .NET artifacts. See REFERENCE.md for full example.
Configures Dapr via AddDapr(), adds a Valkey cache container on port 16379, registers the ApiService project with WithDaprSidecar(), and adds the Diagrid Dashboard as a container resource. See REFERENCE.md for full example and key points.
Uses Aspire.AppHost.Sdk, references CommunityToolkit.Aspire.Hosting.Dapr and Aspire.Hosting.Valkey packages, includes a project reference to ApiService, and copies Resources to output. See REFERENCE.md for full example.
State store component for the apiservice Dapr sidecar. Uses localhost:16379 to connect to the Valkey container managed by Aspire. See REFERENCE.md for full example and key points.
State store component for the Diagrid Dashboard container. Uses host.docker.internal:16379 because the dashboard runs in a Docker container and needs to reach Valkey on the host. Scoped to diagrid-dashboard. See REFERENCE.md for full example and key points.
Same pattern as the dotnet skill but adds builder.AddServiceDefaults() at the start and app.MapDefaultEndpoints() before app.Run(). Uses AddDaprWorkflow to register workflow and activity types. Uses DaprWorkflowClient to schedule workflow instances and query status via HTTP endpoints. Includes start, status, pause, resume, and terminate endpoints. See REFERENCE.md for full example and key points.
Standard ASP.NET Core web project targeting net10.0 with Dapr.Workflow and Dapr.Workflow.Versioning packages and a project reference to ServiceDefaults. See REFERENCE.md for full example.
Record types for workflow and activity input/output, placed in a Models folder. Must be serializable since Dapr persists workflow state. See REFERENCE.md for full example and key points.
Inherits from Workflow<TInput, TOutput>, overrides RunAsync, and orchestrates activities via context.CallActivityAsync. Must be internal sealed. Place in a Workflows folder/namespace. See REFERENCE.md for full example, key points, determinism rules, and workflow patterns (chaining, fan-out/fan-in, sub-workflows).
Inherits from WorkflowActivity<TInput, TOutput>, overrides RunAsync, and contains the actual business logic. Must be internal sealed. Place in an Activities folder/namespace. See REFERENCE.md for full example and key points.
Template-generated file that adds OpenTelemetry, health checks, service discovery, and resilience. No modifications needed — keep as scaffolded by aspire new. See REFERENCE.md for reference.
HTTP request file for testing the workflow endpoints. Contains a start request (POST) to schedule a new workflow instance and a status request (GET) to query the workflow state. See REFERENCE.md for full example.
IMPORTANT: After Project Setup you MUST show these exact verification instructions:
dotnet build on the .sln file to check for build errors.aspire run in the solution root to start the Aspire-orchestrated workflow app.IMPORTANT: After Verify you MUST run these instructions:
Create a README.md file inside the <SolutionRoot> folder.
The README contains the following sections:
aspire run.Program.cs file and provide examples how to call these using curl. Also include a link to the <SolutionRoot>.ApiService/<SolutionRoot>.ApiService.http file.IMPORTANT: This is the LAST step. After Create README.md, your final output MUST be ONLY the message below — no preamble, no summary, no additional commentary, only replace the with the actual value:
The workflow application is created. Open the README.md file in the folder for a summary and instructions for running locally.