ci-cd
Skill235 starsChanged 3 months agoApache-2.0View on GitHub
CI/CD pipelines for .NET applications. Covers GitHub Actions and Azure DevOps YAML pipelines with build, test, publish, and deploy stages. Load this skill when setting up continuous integration, automated testing, deployment workflows, or when the user mentions "CI/CD", "pipeline", "GitHub Actions", "Azure DevOps", "workflow", "deploy", "build pipeline", "publish", "NuGet push", "release", or "continuous integration".
- Reads credentials
Files
CI/CD
Core Principles
- Pipeline as code — YAML pipelines committed to the repo. No click-ops in the UI.
- Fast feedback — Build and test on every push. Cache NuGet packages. Fail fast.
- Build once, deploy many — Build the artifact once, promote it through environments (dev → staging → production).
- Never skip tests — Tests gate the pipeline. No deployment without passing tests.
Patterns
GitHub Actions — Build + Test
# .github/workflows/ci.yml
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
env:
DOTNET_VERSION: '10.0.x'
DOTNET_NOLOGO: true
DOTNET_CLI_TELEMETRY_OPTOUT: true
jobs:
build-and-test:
runs-on: ubuntu-latest
services:
postgres:
image: postgres:17
env:
POSTGRES_DB: testdb
POSTGRES_USER: postgres
POSTGRES_PASSWORD: postgres
ports:
- 5432:5432
options: >-
--health-cmd pg_isready
--health-interval 10s
--health-timeout 5s
--health-retries 5
steps:
- uses: actions/checkout@v4
- name: Setup .NET
uses: actions/setup-dotnet@v4
with:
dotnet-version: ${{ env.DOTNET_VERSION }}
- name: Restore
run: dotnet restore
- name: Build
run: dotnet build --no-restore --configuration Release
- name: Format check
run: dotnet format --verify-no-changes --no-restore
- name: Test
run: dotnet test --no-build --configuration Release --logger trx --results-directory TestResults
env:
ConnectionStrings__Default: "Host=localhost;Database=testdb;Username=postgres;Password=postgres"
- name: Publish test results
uses: actions/upload-artifact@v4
if: always()
with:
name: test-results
path: TestResults/*.trxGitHub Actions — Build + Publish Docker Image
# .github/workflows/publish.yml
name: Publish
on:
push:
tags: ['v*']
jobs:
publish:
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
steps:
- uses: actions/checkout@v4
- name: Login to GitHub Container Registry
uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Extract version from tag
id: version
run: echo "VERSION=${GITHUB_REF#refs/tags/v}" >> $GITHUB_OUTPUT
- name: Build and push
uses: docker/build-push-action@v5
with:
context: .
push: true
tags: |
ghcr.io/${{ github.repository }}:${{ steps.version.outputs.VERSION }}
ghcr.io/${{ github.repository }}:latestAzure DevOps — Build + Test
Same restore → build → format → test flow as GitHub Actions. Key differences:
# azure-pipelines.yml
trigger:
branches:
include: [main]
paths:
exclude: ['*.md', docs/]
pool:
vmImage: 'ubuntu-latest' # vs runs-on: ubuntu-latest
variables:
dotnetVersion: '10.0.x'
# Key task differences from GitHub Actions:
# Setup .NET: task: UseDotNet@2 (inputs: version: $(dotnetVersion))
# Test results: task: PublishTestResults@2 (testResultsFormat: VSTest)
# Steps use `script:` + `displayName:` instead of `- name:` + `run:`
# Services (e.g., Postgres) require a separate Docker task or pipeline service connectionNuGet Package Publishing
# Part of GitHub Actions workflow
- name: Pack
run: dotnet pack src/MyLibrary -c Release -o ./nupkg --no-build
- name: Push to NuGet
run: dotnet nuget push ./nupkg/*.nupkg --api-key ${{ secrets.NUGET_API_KEY }} --source https://api.nuget.org/v3/index.jsonAnti-patterns
Don't Build Different Artifacts per Environment
# BAD — building separately for each environment
- script: dotnet publish -c Debug # for dev
- script: dotnet publish -c Release # for prod
# GOOD — build once, deploy everywhere
- script: dotnet publish -c Release -o ./publish
# Then deploy the same ./publish artifact to dev, staging, prodDon't Skip Format Checks in CI
# BAD — no format enforcement
steps:
- run: dotnet build
- run: dotnet test
# GOOD — format check catches style issues early
steps:
- run: dotnet build
- run: dotnet format --verify-no-changes
- run: dotnet testDon't Hardcode Secrets in Pipelines
# BAD — secret in pipeline YAML
env:
DB_PASSWORD: "my-secret-password"
# GOOD — use pipeline secrets
env:
DB_PASSWORD: ${{ secrets.DB_PASSWORD }}Decision Guide
| Scenario | Recommendation |
| Open source project | GitHub Actions |
| Enterprise with Azure | Azure DevOps Pipelines |
| Docker deployment | Multi-stage build in CI, push to container registry |
| NuGet library | Build → Test → Pack → Push on tag |
| Database migrations | Run in CI test stage, script for production |
| Environment promotion | Same artifact, different configuration |
Other versions35 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 35
- cunarist/rinf★ 2.8ksame name
- kid-sid/claude-spellbook★ 190same name
- irahardianto/awesome-agv★ 157same name
- AsiaOstrich/universal-dev-standards★ 82same name
- nahid-sparktales/agent-dispatcher★ 59same name
- mgifford/accessibility-skills★ 48same name
- nimadorostkar/Claude-Skills-collection★ 33same name
- iuliandita/skills★ 10same name
- MiguelSavignano/claude-code-system★ 6same name
- kevinaimonster/skill-hub★ 4same name
25 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use feature-flags, auth and 7 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
SentrySkillfeature-flags
Gate a Sentry feature behind a FlagPole feature flag. Use when adding a feature flag, registering a flag in temporary.py, checking a flag from Python or the frontend, enabling a flag in tests, or asking where FlagPole rollout config lives. Trigger on "add a feature flag", "gate this behind a flag", "register a flag", "features.has", "api_expose", "OrganizationFeature", "ProjectFeature", "FlagPole".
Also in 4 projects that use this
OpenAISkillauth
Authentication integration guidance — Clerk (native Vercel Marketplace), Descope, and Auth0 setup for Next.js applications. Covers middleware auth patterns, sign-in/sign-up flows, and Marketplace provisioning. Use when implementing user authentication.
Also in 4 projects that use this
OpenAISkillobservability
Vercel Observability expert guidance — Drains (logs, traces, speed insights, web analytics), Web Analytics, Speed Insights, runtime logs, custom events, OpenTelemetry integration, and monitoring dashboards. Use when instrumenting, debugging, or optimizing application performance and user experience on Vercel.
Also in 11 projects that use this
mylee04Skillshell-scripting
Shell scripting best practices for cross-platform CLI tools
Also in 3 projects that use this
rogue-dev-studioSkillmonitoring
Claude monitoring and usage tracking tools (UV, claude-monitor, claude-usage-cli). Use when the project needs this capability or the user / team manifest asks for it. Use for specialized `monitoring` work when listed in TEAM.yaml or explicitly requested.
Also in 3 projects that use this
AnthropicSkillincident-response
Run an incident response workflow — triage, communicate, and write postmortem. Trigger with "we have an incident", "production is down", an alert that needs severity assessment, a status update mid-incident, or when writing a blameless postmortem after resolution.
Also in 7 projects that use this
In this repository96 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- 80-20-reviewSkill
- api-versioningSkill
- architecture-advisorSkill
- aspireSkill
- authenticationSkill
- autonomous-loopsSkill
- cachingSkill
- clean-architectureSkill
- code-review-workflowSkill
- configurationSkill
- container-publishSkill
- context-disciplineSkill
- convention-learnerSkill
- dddSkill
- dependency-injectionSkill
- de-sloppifySkill
- dockerSkill
- ef-coreSkill
- error-handlingSkill
- health-checkSkill
- httpclient-factorySkill
- instinct-systemSkill
- learning-logSkill
- loggingSkill
- messagingSkill
- migration-workflowSkill
- minimal-apiSkill
- model-selectionSkill
- modern-csharpSkill
- openapiSkill
- opentelemetrySkill
- project-setupSkill
- project-structureSkill
- resilienceSkill
- scaffoldingSkill
- scalarSkill
- security-scanSkill
- self-correction-loopSkill
- serilogSkill
- session-managementSkill
- split-memorySkill
- testingSkill
- verification-loopSkill
- vertical-sliceSkill
- workflow-masterySkill
- wrap-up-ritualSkill
- 80-20-reviewSkill
- api-versioningSkill
- architecture-advisorSkill
- aspireSkill
- authenticationSkill
- autonomous-loopsSkill
- cachingSkill
- ci-cdSkill
- clean-architectureSkill
- code-review-workflowSkill
- configurationSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

