Dependabot Validation
Poupa o trabalho manual de auditar dependências: junta os PRs abertos do
Dependabot, o status de CI de cada um, os alertas de segurança do repositório,
e aplica regras de "até onde pode atualizar" para te dizer, por PR, o que
subir, o que revisar e o que segurar. É somente leitura — nunca faz
merge, approve, comentário ou label.
Pré-requisitos
gh (GitHub CLI) autenticado (gh auth status) e jq instalados.
- Acesso de leitura ao repositório. Os alertas de segurança exigem permissão
extra (admin/security); sem ela, a skill segue só com os PRs e avisa.
Como usar
Descobrir o repositório. Use o owner/repo que o usuário informar. Se
não vier nenhum e você estiver dentro de um repo git, descubra com
gh repo view --json nameWithOwner -q .nameWithOwner. Em caso de dúvida,
pergunte — não invente.
Coletar os dados (read-only):
bash "$SKILL_DIR/scripts/fetch.sh" <owner/repo>
($SKILL_DIR = a pasta desta skill.) Isso imprime um JSON com
pull_requests[] (cada um com ecosystem, dependency, from_version,
to_version, grouped, ci, labels, body_excerpt) e
security_alerts[] (com severity, package, ecosystem,
vulnerable_range, patched). Se security_alerts_error não for nulo,
mencione isso no relatório.
Ler os guardrails em constraints.yml (mesma pasta da skill) com a
ferramenta Read. Cada regra tem ecosystem, match, max_major, reason.
Classificar cada PR (regras abaixo) e cruzar com os alertas.
Emitir o relatório no formato abaixo. Sem ações de escrita.
Como classificar cada PR
Determine o tipo de salto comparando from_version → to_version:
muda o major = major; muda o minor = minor; senão = patch.
(Para PRs com grouped: true, não há um único par de versões — use o
body_excerpt para listar os pacotes do grupo e trate como revisar.)
Aplique os guardrails: para cada regra de constraints.yml cujo
ecosystem bate com o do PR e cujo match é substring (case-insensitive) de
dependency, se o major de to_version > max_major, o PR é ⛔ HOLD
(cite a reason da regra).
Buckets, em ordem de prioridade:
- 🔴 Corrige alerta de segurança — o
package/ecosystem do PR casa com
algum security_alerts[] aberto e o to_version ≥ patched. Prioridade
máxima. (Se também cruzar um guardrail, sinalize o conflito explicitamente:
"corrige falha MAS cruzaria o teto — avaliar backport/exceção".)
- ⛔ Hold (guardrail) — cruza um teto de versão. Não subir; explicar o porquê.
- 🟡 Revisar — major bump (sem guardrail), OU
ci = FAILURE, OU grouped,
OU ci = PENDING/NONE. Explique o motivo (build vermelho? salto grande?).
- 🟢 Seguro para subir — patch/minor,
ci = SUCCESS, sem guardrail e sem
alerta pendente.
Mostre sempre, por PR: número (link), ecossistema, dependência,
from → to com o tipo de salto, estado do CI e o motivo da classificação.
Formato do relatório
## Dependabot — <owner/repo> · <data>
PRs abertos: <N> · Alertas de segurança abertos: <M>
<se houver security_alerts_error: linha de aviso sobre alertas indisponíveis>
### 🔴 Corrigem alertas de segurança (subir primeiro)
- #<n> <eco>: <dep> <from> → <to> (<salto>) · CI <✅/❌/⏳> · <severidade> — <recomendação>
### ⛔ Hold — guardrail
- #<n> <eco>: <dep> <from> → <to> (major) — BLOQUEADO: <reason do constraints.yml>
### 🟡 Revisar
- #<n> <eco>: <dep> <from> → <to> (<salto>) · CI <...> — <motivo: build vermelho / major / grupo>
### 🟢 Seguro para subir
- #<n> <eco>: <dep> <from> → <to> (<salto>) · CI ✅
### ⚠️ Alertas de segurança sem PR correspondente
- <severidade> <package> (<eco>) — vulnerável <vulnerable_range>, corrigido em <patched> — <url>
---
**Resumo:** <X seguros, Y a revisar, Z em hold, W alertas sem correção>. Próximo passo sugerido: <ex.: subir os 🟢 e o 🔴, fechar o PR de Spring 4, investigar o CI do #18>.
Omita seções vazias. Seja direto: o objetivo é o usuário bater o olho e saber o
que fazer.
Notas e limitações
- Read-only por design. Nunca rode
gh pr merge/review/comment, nem
gh pr edit/label. Se o usuário quiser agir, ele decide e executa.
- O ecossistema vem do branch do Dependabot (
dependabot/maven/...,
dependabot/npm_and_yarn/...). Ecossistemas fora de Maven/npm aparecem como
unknown mas ainda são listados.
- A correspondência PR↔alerta é por nome de pacote; pode haver pequenas
diferenças de nomenclatura entre ecossistemas — na dúvida, sinalize em vez de
afirmar com certeza.
- Para checar risco de quebra além da versão, vale ler o
body_excerpt (o
Dependabot inclui release notes e um "compatibility score").
1---2name: dependabot-validation3description: Dependabot Validation4---56# Dependabot Validation78Poupa o trabalho manual de auditar dependências: junta os PRs abertos do9Dependabot, o status de CI de cada um, os alertas de segurança do repositório,10e aplica regras de "até onde pode atualizar" para te dizer, por PR, **o que11subir, o que revisar e o que segurar**. É **somente leitura** — nunca faz12merge, approve, comentário ou label.1314## Pré-requisitos1516- `gh` (GitHub CLI) autenticado (`gh auth status`) e `jq` instalados.17- Acesso de leitura ao repositório. Os **alertas de segurança** exigem permissão18 extra (admin/security); sem ela, a skill segue só com os PRs e avisa.1920## Como usar21221. **Descobrir o repositório.** Use o `owner/repo` que o usuário informar. Se23 não vier nenhum e você estiver dentro de um repo git, descubra com24 `gh repo view --json nameWithOwner -q .nameWithOwner`. Em caso de dúvida,25 pergunte — não invente.26272. **Coletar os dados** (read-only):28 ```bash29 bash "$SKILL_DIR/scripts/fetch.sh" <owner/repo>30 ```31 (`$SKILL_DIR` = a pasta desta skill.) Isso imprime um JSON com32 `pull_requests[]` (cada um com `ecosystem`, `dependency`, `from_version`,33 `to_version`, `grouped`, `ci`, `labels`, `body_excerpt`) e34 `security_alerts[]` (com `severity`, `package`, `ecosystem`,35 `vulnerable_range`, `patched`). Se `security_alerts_error` não for nulo,36 mencione isso no relatório.37383. **Ler os guardrails** em `constraints.yml` (mesma pasta da skill) com a39 ferramenta Read. Cada regra tem `ecosystem`, `match`, `max_major`, `reason`.40414. **Classificar cada PR** (regras abaixo) e **cruzar com os alertas**.42435. **Emitir o relatório** no formato abaixo. Sem ações de escrita.4445## Como classificar cada PR4647Determine o **tipo de salto** comparando `from_version` → `to_version`:48muda o major = **major**; muda o minor = **minor**; senão = **patch**.49(Para PRs com `grouped: true`, não há um único par de versões — use o50`body_excerpt` para listar os pacotes do grupo e trate como **revisar**.)5152Aplique os **guardrails**: para cada regra de `constraints.yml` cujo53`ecosystem` bate com o do PR e cujo `match` é substring (case-insensitive) de54`dependency`, se o **major de `to_version` > `max_major`**, o PR é **⛔ HOLD**55(cite a `reason` da regra).5657Buckets, em ordem de prioridade:58591. **🔴 Corrige alerta de segurança** — o `package`/`ecosystem` do PR casa com60 algum `security_alerts[]` aberto e o `to_version` ≥ `patched`. Prioridade61 máxima. (Se também cruzar um guardrail, sinalize o conflito explicitamente:62 "corrige falha MAS cruzaria o teto — avaliar backport/exceção".)632. **⛔ Hold (guardrail)** — cruza um teto de versão. Não subir; explicar o porquê.643. **🟡 Revisar** — major bump (sem guardrail), OU `ci` = FAILURE, OU `grouped`,65 OU `ci` = PENDING/NONE. Explique o motivo (build vermelho? salto grande?).664. **🟢 Seguro para subir** — patch/minor, `ci` = SUCCESS, sem guardrail e sem67 alerta pendente.6869Mostre sempre, por PR: número (link), ecossistema, dependência,70`from → to` com o tipo de salto, estado do CI e o motivo da classificação.7172## Formato do relatório7374```75## Dependabot — <owner/repo> · <data>76PRs abertos: <N> · Alertas de segurança abertos: <M>77<se houver security_alerts_error: linha de aviso sobre alertas indisponíveis>7879### 🔴 Corrigem alertas de segurança (subir primeiro)80- #<n> <eco>: <dep> <from> → <to> (<salto>) · CI <✅/❌/⏳> · <severidade> — <recomendação>8182### ⛔ Hold — guardrail83- #<n> <eco>: <dep> <from> → <to> (major) — BLOQUEADO: <reason do constraints.yml>8485### 🟡 Revisar86- #<n> <eco>: <dep> <from> → <to> (<salto>) · CI <...> — <motivo: build vermelho / major / grupo>8788### 🟢 Seguro para subir89- #<n> <eco>: <dep> <from> → <to> (<salto>) · CI ✅9091### ⚠️ Alertas de segurança sem PR correspondente92- <severidade> <package> (<eco>) — vulnerável <vulnerable_range>, corrigido em <patched> — <url>9394---95**Resumo:** <X seguros, Y a revisar, Z em hold, W alertas sem correção>. Próximo passo sugerido: <ex.: subir os 🟢 e o 🔴, fechar o PR de Spring 4, investigar o CI do #18>.96```9798Omita seções vazias. Seja direto: o objetivo é o usuário bater o olho e saber o99que fazer.100101## Notas e limitações102103- **Read-only por design.** Nunca rode `gh pr merge/review/comment`, nem104 `gh pr edit`/`label`. Se o usuário quiser agir, ele decide e executa.105- O ecossistema vem do branch do Dependabot (`dependabot/maven/...`,106 `dependabot/npm_and_yarn/...`). Ecossistemas fora de Maven/npm aparecem como107 `unknown` mas ainda são listados.108- A correspondência PR↔alerta é por nome de pacote; pode haver pequenas109 diferenças de nomenclatura entre ecossistemas — na dúvida, sinalize em vez de110 afirmar com certeza.111- Para checar risco de quebra além da versão, vale ler o `body_excerpt` (o112 Dependabot inclui release notes e um "compatibility score").