Objetivo
Orientar mudanças em CI/CD, packaging, versionamento e release com segurança, rastreabilidade e aderência aos workflows que realmente existem no repositório.
Regra principal
Antes de assumir qualquer automação, inspecione .github/workflows/. O estado real do repositório é a fonte de verdade para triggers, permissões, credenciais, versionamento, packaging e publicação.
Processo
- Leia
AGENTS.md e liste os workflows existentes.
- Identifique trigger, permissões, comandos, credenciais, artifacts e fonte de versão do fluxo afetado.
- Preserve restore reproduzível, build e testes antes de packaging/publicação.
- Use permissões mínimas e evite credenciais persistentes quando houver mecanismo temporário/OIDC suportado.
- Preserve uma única fonte editável de versão por contexto e valide SemVer quando aplicável.
- Garanta que falhas de build, testes, análise, pack ou verificação bloqueiem publicação/release.
- Confirme que ações de terceiros estão pinadas de acordo com a política do repositório.
- Revise se uma mudança pertence apenas ao template/source repository ou também deve existir no projeto gerado.
- Atualize documentação quando o comportamento oficial do pipeline mudar.
- Execute a baseline e validações específicas definidas em
AGENTS.md.
Segurança de supply chain
- Não use
write-all por conveniência.
- Restrinja permissões de escrita aos jobs que realmente precisam delas.
- Não exponha secrets a eventos não confiáveis.
- Prefira OIDC/Trusted Publishing quando o destino suportar.
- Não permita publicação quando identidade, versão ou pacote não tiverem sido validados.
- Não enfraqueça CodeQL, Dependency Review, NuGet Audit, Sonar, secret scanning ou outros gates para acelerar release.
Restrições específicas
- Não execute publicação, criação de tag, GitHub Release ou deploy sem solicitação explícita.
- Não mantenha duas fontes de versão independentes para o mesmo artefato.
- Não assuma que variables, secrets, environments, rulesets ou Trusted Publishing são copiados por template de repositório.
- Não amplie permissões ou retenção de artifacts sem necessidade demonstrável.
As demais restrições e validações globais são definidas em AGENTS.md.
Critério de qualidade
Uma boa mudança de automação reproduz comandos suportados localmente, usa menor privilégio, mantém rastreabilidade entre commit, versão e artefato, falha de forma fechada antes de publicação e documenta somente capacidades realmente presentes no repositório.
1---2name: ci-release-governance-43description: Use esta skill para revisar ou ajustar GitHub Actions, packaging, segurança de automação, versionamento e fluxo de release de uma biblioteca .NET. Não use para mudanças funcionais sem impacto no pipeline.4license: MIT5---67# Objetivo89Orientar mudanças em CI/CD, packaging, versionamento e release com segurança, rastreabilidade e aderência aos workflows que realmente existem no repositório.1011# Regra principal1213Antes de assumir qualquer automação, inspecione `.github/workflows/`. O estado real do repositório é a fonte de verdade para triggers, permissões, credenciais, versionamento, packaging e publicação.1415# Processo16171. Leia `AGENTS.md` e liste os workflows existentes.182. Identifique trigger, permissões, comandos, credenciais, artifacts e fonte de versão do fluxo afetado.193. Preserve restore reproduzível, build e testes antes de packaging/publicação.204. Use permissões mínimas e evite credenciais persistentes quando houver mecanismo temporário/OIDC suportado.215. Preserve uma única fonte editável de versão por contexto e valide SemVer quando aplicável.226. Garanta que falhas de build, testes, análise, pack ou verificação bloqueiem publicação/release.237. Confirme que ações de terceiros estão pinadas de acordo com a política do repositório.248. Revise se uma mudança pertence apenas ao template/source repository ou também deve existir no projeto gerado.259. Atualize documentação quando o comportamento oficial do pipeline mudar.2610. Execute a baseline e validações específicas definidas em `AGENTS.md`.2728# Segurança de supply chain2930- Não use `write-all` por conveniência.31- Restrinja permissões de escrita aos jobs que realmente precisam delas.32- Não exponha secrets a eventos não confiáveis.33- Prefira OIDC/Trusted Publishing quando o destino suportar.34- Não permita publicação quando identidade, versão ou pacote não tiverem sido validados.35- Não enfraqueça CodeQL, Dependency Review, NuGet Audit, Sonar, secret scanning ou outros gates para acelerar release.3637# Restrições específicas3839- Não execute publicação, criação de tag, GitHub Release ou deploy sem solicitação explícita.40- Não mantenha duas fontes de versão independentes para o mesmo artefato.41- Não assuma que variables, secrets, environments, rulesets ou Trusted Publishing são copiados por template de repositório.42- Não amplie permissões ou retenção de artifacts sem necessidade demonstrável.4344As demais restrições e validações globais são definidas em `AGENTS.md`.4546# Critério de qualidade4748Uma boa mudança de automação reproduz comandos suportados localmente, usa menor privilégio, mantém rastreabilidade entre commit, versão e artefato, falha de forma fechada antes de publicação e documenta somente capacidades realmente presentes no repositório.
rodri-oliveira-dev