# CI Release Governance

> Use this skill when designing or reviewing DotNetRepoInspector CI, release/versioning, package publication, GitHub Action distribution, permissions, artifacts, or automated quality gates. Do not use it for ordinary production-code changes with no pipeline impact.

- Skill: `rodri-oliveira-dev/ci-release-governance-3` (Agent Skill)
- Install (CLI): `npx skillmds@latest add rodri-oliveira-dev/ci-release-governance-3`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rodri-oliveira-dev/ci-release-governance-3/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: rodri-oliveira-dev (https://skillmd.com/u/rodri-oliveira-dev)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/rodri-oliveira-dev/ci-release-governance-3

---


# CI and Release Governance

## Goals

Keep build, test, package, and release automation reproducible, least-privileged, and consistent with the repository's published contracts.

## Use for

- `.github/workflows/` design;
- NuGet/.NET tool packaging;
- GitHub Action packaging and version tags;
- release/versioning conventions;
- test/coverage/security gates;
- workflow permissions, secrets, artifacts, retention, and triggers.

For workflow YAML syntax and expression quoting, also use `authoring-github-workflows`.

## Rules

- Pin or deliberately version third-party actions; avoid floating behavior in security-sensitive jobs.
- Grant the minimum `GITHUB_TOKEN` permissions required by each workflow/job.
- Never place credentials in repository files or logs.
- Keep pull-request validation separate from publishing/release permissions.
- Do not publish packages/releases from untrusted fork code with write credentials.
- Avoid expensive jobs on every event unless their value justifies the cost.
- Keep CLI, JSON schema, NuGet package, and GitHub Action versioning implications explicit.
- Do not remove tests, analyzers, audit checks, or security gates merely to make CI green.

## Validation

For workflow changes, validate syntax with `actionlint` when available. For packaging changes, prefer a local pack/dry-run path before real publication. Publishing a release, NuGet package, container, or marketplace artifact always requires explicit user intent.

## Completion

Report changed triggers/permissions, build/test/package impact, validations performed, and any compatibility implications for existing consumers.