ワンクリックで
dotnet-add-ci
Adding CI/CD to a .NET project. GitHub Actions vs Azure DevOps detection, workflow templates.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Adding CI/CD to a .NET project. GitHub Actions vs Azure DevOps detection, workflow templates.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Guidelines for writing TUnit tests in .NET, including setup, assertions, async testing, and best practices. Use when writing unit tests with TUnit framework, setting up TUnit in a .NET project, or migrating from other test frameworks to TUnit.
Hosted services, background jobs, outbox patterns, and graceful shutdown handling for ASP.NET Core applications. Includes patterns for reliable job processing, distributed systems, and lifecycle management. Use when implementing background processing in ASP.NET Core applications, handling outbox patterns for reliable message delivery, or managing graceful service shutdown.
Design stable, compatible public APIs using extend-only design principles. Manage API compatibility, wire compatibility, versioning, naming conventions, parameter ordering, and return types for NuGet packages and distributed systems. Use when designing public APIs for NuGet packages or libraries, making changes to existing public APIs, planning wire format changes for distributed systems, or reviewing pull requests for breaking changes.
Write modern, high-performance C# code using records, pattern matching, value objects, async/await, Span<T>/Memory<T>, and best-practice API design patterns. Emphasizes functional-style programming with C# 12+ features. Use when writing new C# code or refactoring existing code, designing public APIs for libraries or services, optimizing performance-critical code paths, or building async/await-heavy applications.
Choosing the right concurrency abstraction in .NET - from async/await for I/O to Channels for producer/consumer to Akka.NET for stateful entity management. Covers both high-level abstractions and low-level synchronization primitives. Use when deciding how to handle concurrent operations in .NET, evaluating whether to use async/await, Channels, or Akka.NET, or managing state across multiple concurrent entities.
Design .NET types for performance. Covers struct vs class decision matrix, sealed by default, readonly structs, ref struct and Span/Memory selection, FrozenDictionary, ValueTask, and collection return types. Use when designing new types and APIs, reviewing code for performance issues, choosing between class, struct, and record, or working with collections and enumerables.
| name | dotnet-add-ci |
| description | Adding CI/CD to a .NET project. GitHub Actions vs Azure DevOps detection, workflow templates. |
Add starter CI/CD workflows to an existing .NET project. Detects the hosting platform (GitHub Actions or Azure DevOps) and generates an appropriate starter workflow for build, test, and pack.
Scope boundary: This skill provides starter templates only. For advanced CI/CD patterns — composable reusable workflows, matrix builds, deployment pipelines, release automation, and environment promotion — see [skill:dotnet-gha-patterns], [skill:dotnet-ado-patterns], and related CI/CD depth skills.
Prerequisites: Run [skill:dotnet-version-detection] first to determine SDK version for the workflow. Run [skill:dotnet-project-analysis] to understand solution structure.
Cross-references: [skill:dotnet-project-structure] for build props layout, [skill:dotnet-scaffold-project] which generates the project structure these workflows build.
Detect the CI platform from existing repo indicators:
| Indicator | Platform |
|---|---|
.github/ directory exists | GitHub Actions |
azure-pipelines.yml exists | Azure DevOps |
.github/workflows/ has YAML files | GitHub Actions (already configured) |
| Neither | Ask the user which platform to target |
Create .github/workflows/build.yml:
name: Build and Test
on:
push:
branches: [main]
pull_request:
branches: [main]
permissions:
contents: read
env:
DOTNET_NOLOGO: true
DOTNET_CLI_TELEMETRY_OPTOUT: true
DOTNET_SKIP_FIRST_TIME_EXPERIENCE: true
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup .NET
uses: actions/setup-dotnet@v4
with:
global-json-file: global.json
- name: Restore
run: dotnet restore --locked-mode
- name: Build
run: dotnet build --no-restore -c Release
- name: Test
run: dotnet test --no-build -c Release --logger trx --results-directory TestResults
- name: Upload test results
uses: actions/upload-artifact@v4
if: always()
with:
name: test-results
path: TestResults/**/*.trx
global-json-file — uses the repo's global.json to install the exact SDK version. If the project has no global.json, replace with dotnet-version: '10.0.x' (or the appropriate version)--locked-mode — ensures packages.lock.json files are respected; fails if they're out of date. If the project doesn't use lock files, replace with plain dotnet restore-c Release — builds in Release mode so ContinuousIntegrationBuild takes effectpermissions: contents: read — principle of least privilegeFor projects that publish to NuGet, add a pack step:
- name: Pack
run: dotnet pack --no-build -c Release -o artifacts
- name: Upload packages
uses: actions/upload-artifact@v4
with:
name: nuget-packages
path: artifacts/*.nupkg
Create azure-pipelines.yml at the repo root:
trigger:
branches:
include:
- main
pr:
branches:
include:
- main
pool:
vmImage: 'ubuntu-latest'
variables:
DOTNET_NOLOGO: true
DOTNET_CLI_TELEMETRY_OPTOUT: true
DOTNET_SKIP_FIRST_TIME_EXPERIENCE: true
buildConfiguration: 'Release'
steps:
- task: UseDotNet@2
displayName: 'Setup .NET SDK'
inputs:
useGlobalJson: true
- script: dotnet restore --locked-mode
displayName: 'Restore'
- script: dotnet build --no-restore -c $(buildConfiguration)
displayName: 'Build'
- task: DotNetCoreCLI@2
displayName: 'Test'
inputs:
command: 'test'
arguments: '--no-build -c $(buildConfiguration) --logger trx'
publishTestResults: true
- script: dotnet pack --no-build -c $(buildConfiguration) -o $(Build.ArtifactStagingDirectory)
displayName: 'Pack'
- task: PublishBuildArtifacts@1
displayName: 'Publish NuGet packages'
inputs:
pathToPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: 'nuget-packages'
If the project multi-targets, the default workflow works without changes — dotnet build and dotnet test handle all TFMs automatically. No matrix is needed for the starter.
Change the runner:
# GitHub Actions
runs-on: windows-latest
# Azure DevOps
pool:
vmImage: 'windows-latest'
If the repo has multiple solutions or uses solution filters:
- name: Build
run: dotnet build MyApp.slnf --no-restore -c Release
After adding the workflow, verify locally:
# GitHub Actions — validate YAML syntax
# Install: gh extension install moritztomasi/gh-workflow-validator
gh workflow-validator .github/workflows/build.yml
# Or simply verify the build steps work locally
dotnet restore --locked-mode
dotnet build --no-restore -c Release
dotnet test --no-build -c Release
Push a branch and open a PR to trigger the workflow.
This starter covers build-test-pack. For advanced scenarios, see the CI/CD depth skills: