PR
Objetivo
Use esta skill para transformar uma branch pronta em um pull request revisavel,
com validacao local completa e documentacao suficiente para a revisao.
O padrao obrigatorio e:
- Rodar todos os testes descobertos antes de submeter.
- Nao criar nem atualizar PR se algum teste falhar.
- Notificar claramente qualquer falha de teste.
- Criar PR com titulo claro.
- Gerar changelog completo pronto para revisao.
Fluxo
- Inspecione o estado do repositorio:
git status --short --branch.
- Confirme a branch atual e a branch base:
git branch --show-current e git remote show origin.
- Leia o historico e o delta que entrara no PR:
git log --oneline <base>..HEAD,
git diff --stat <base>...HEAD e
git diff --name-status <base>...HEAD.
- Se houver alteracoes sem commit, organize commits antes de abrir o PR.
Quando a skill
commit estiver disponivel, use o fluxo dela.
- Descubra todos os comandos de teste declarados no projeto antes de rodar:
scripts de
package.json, arquivos de configuracao de test runners,
Makefile, justfile, workflows locais, scripts do repo e convencoes da
linguagem usada.
- Execute todos os testes descobertos. Inclua suites unitarias, integracao,
lint/testes estaticos e typecheck quando o projeto tratar esses comandos
como parte da validacao normal.
- Se qualquer teste falhar, interrompa o fluxo antes de push/PR. Notifique o
usuario com comando, codigo de saida, resumo da falha e proximo passo
recomendado.
- Se todos os testes passarem, faca push da branch quando necessario.
- Crie ou atualize o PR com titulo claro e corpo contendo changelog completo.
- Ao final, informe link/numero do PR, titulo, comandos de teste executados
e status final do repositorio.
Regras De Teste
- "Todos os testes" significa todos os comandos de validacao que o repositorio
expõe para a mudanca em questao.
- Nao escolha apenas um teste focado quando houver suite completa disponivel.
- Quando houver varios package managers, use o lockfile para decidir:
pnpm-lock.yaml, yarn.lock, package-lock.json ou bun.lockb.
- Em monorepos, rode os testes dos pacotes afetados e qualquer suite raiz que
agregue validacao do projeto.
- Nao ignore falhas existentes sem evidencia. Se a falha parecer preexistente,
reporte isso com o comando e a evidencia, mas ainda nao submeta sem
autorizacao explicita.
- Se nao existir comando de teste claro, explique a busca feita e bloqueie para
confirmacao antes de submeter.
Titulo Do PR
O titulo deve ser curto, claro e especifico:
- Descreva a mudanca principal, nao o processo.
- Evite
WIP, updates, misc, fix stuff, ajustes ou titulos vagos.
- Use o idioma predominante do repositorio, do historico da branch ou do pedido
do usuario.
- Nao force Conventional Commits no titulo do PR, a menos que o projeto ja use
esse padrao para PRs.
Exemplos:
Adiciona skill para commits por escopo
Corrige validacao de assinaturas no Supabase
Add scoped commit skill
Fix subscription RPC authorization
Changelog Do PR
Gere o corpo do PR como documentacao pronta para revisao. Use os commits, o
diff, os arquivos alterados e os testes executados como fonte.
Formato recomendado:
## Resumo
- ...
## Changelog
### Adicionado
- ...
### Alterado
- ...
### Corrigido
- ...
### Removido
- ...
## Validacao
- [x] `comando executado`
## Impacto
- ...
## Riscos E Observacoes
- ...
Regras:
- Remova secoes vazias ou marque como
Nao se aplica quando a ausencia for
importante para revisao.
- Inclua migracoes, variaveis de ambiente, breaking changes, mudancas de API,
comportamento de usuario, riscos e plano de rollback quando aplicavel.
- O changelog deve explicar o que mudou e por que isso importa para quem
revisa.
- Se existir template de PR no repositorio, preserve a estrutura obrigatoria do
template e encaixe o changelog nela.
- Se existir
CHANGELOG.md e a mudanca exigir registro permanente, atualize o
arquivo alem do corpo do PR.
Submissao
- Use a ferramenta disponivel no ambiente: GitHub app,
gh pr create,
gh pr edit ou equivalente do provedor.
- Prefira draft PR quando a mudanca ainda precisar de revisao humana antes de
ficar pronta para merge.
- Depois de criar ou atualizar o PR, confira se o link existe e se o corpo
contem o changelog completo.
- Nao use auto-merge sem pedido explicito.
Resposta Ao Usuario
Depois de criar ou atualizar o PR, responda de forma curta com:
- Link/numero do PR.
- Titulo criado.
- Changelog resumido em poucos bullets.
- Lista de testes executados e resultado.
- Falhas encontradas ou pendencias, se houver.
1---2name: pr3description: Use esta skill ao preparar, revisar, submeter ou criar pull requests. Exige executar todos os testes antes de submeter, bloquear e notificar falhas, criar titulo claro e gerar changelog completo pronto para revisao no corpo do PR.4---56# PR78## Objetivo910Use esta skill para transformar uma branch pronta em um pull request revisavel,11com validacao local completa e documentacao suficiente para a revisao.1213O padrao obrigatorio e:1415- Rodar todos os testes descobertos antes de submeter.16- Nao criar nem atualizar PR se algum teste falhar.17- Notificar claramente qualquer falha de teste.18- Criar PR com titulo claro.19- Gerar changelog completo pronto para revisao.2021## Fluxo22231. Inspecione o estado do repositorio:24 `git status --short --branch`.252. Confirme a branch atual e a branch base:26 `git branch --show-current` e `git remote show origin`.273. Leia o historico e o delta que entrara no PR:28 `git log --oneline <base>..HEAD`,29 `git diff --stat <base>...HEAD` e30 `git diff --name-status <base>...HEAD`.314. Se houver alteracoes sem commit, organize commits antes de abrir o PR.32 Quando a skill `commit` estiver disponivel, use o fluxo dela.335. Descubra todos os comandos de teste declarados no projeto antes de rodar:34 scripts de `package.json`, arquivos de configuracao de test runners,35 `Makefile`, `justfile`, workflows locais, scripts do repo e convencoes da36 linguagem usada.376. Execute todos os testes descobertos. Inclua suites unitarias, integracao,38 lint/testes estaticos e typecheck quando o projeto tratar esses comandos39 como parte da validacao normal.407. Se qualquer teste falhar, interrompa o fluxo antes de push/PR. Notifique o41 usuario com comando, codigo de saida, resumo da falha e proximo passo42 recomendado.438. Se todos os testes passarem, faca push da branch quando necessario.449. Crie ou atualize o PR com titulo claro e corpo contendo changelog completo.4510. Ao final, informe link/numero do PR, titulo, comandos de teste executados46 e status final do repositorio.4748## Regras De Teste4950- "Todos os testes" significa todos os comandos de validacao que o repositorio51 expõe para a mudanca em questao.52- Nao escolha apenas um teste focado quando houver suite completa disponivel.53- Quando houver varios package managers, use o lockfile para decidir:54 `pnpm-lock.yaml`, `yarn.lock`, `package-lock.json` ou `bun.lockb`.55- Em monorepos, rode os testes dos pacotes afetados e qualquer suite raiz que56 agregue validacao do projeto.57- Nao ignore falhas existentes sem evidencia. Se a falha parecer preexistente,58 reporte isso com o comando e a evidencia, mas ainda nao submeta sem59 autorizacao explicita.60- Se nao existir comando de teste claro, explique a busca feita e bloqueie para61 confirmacao antes de submeter.6263## Titulo Do PR6465O titulo deve ser curto, claro e especifico:6667- Descreva a mudanca principal, nao o processo.68- Evite `WIP`, `updates`, `misc`, `fix stuff`, `ajustes` ou titulos vagos.69- Use o idioma predominante do repositorio, do historico da branch ou do pedido70 do usuario.71- Nao force Conventional Commits no titulo do PR, a menos que o projeto ja use72 esse padrao para PRs.7374Exemplos:7576```text77Adiciona skill para commits por escopo78Corrige validacao de assinaturas no Supabase79Add scoped commit skill80Fix subscription RPC authorization81```8283## Changelog Do PR8485Gere o corpo do PR como documentacao pronta para revisao. Use os commits, o86diff, os arquivos alterados e os testes executados como fonte.8788Formato recomendado:8990```markdown91## Resumo9293- ...9495## Changelog9697### Adicionado9899- ...100101### Alterado102103- ...104105### Corrigido106107- ...108109### Removido110111- ...112113## Validacao114115- [x] `comando executado`116117## Impacto118119- ...120121## Riscos E Observacoes122123- ...124```125126Regras:127128- Remova secoes vazias ou marque como `Nao se aplica` quando a ausencia for129 importante para revisao.130- Inclua migracoes, variaveis de ambiente, breaking changes, mudancas de API,131 comportamento de usuario, riscos e plano de rollback quando aplicavel.132- O changelog deve explicar o que mudou e por que isso importa para quem133 revisa.134- Se existir template de PR no repositorio, preserve a estrutura obrigatoria do135 template e encaixe o changelog nela.136- Se existir `CHANGELOG.md` e a mudanca exigir registro permanente, atualize o137 arquivo alem do corpo do PR.138139## Submissao140141- Use a ferramenta disponivel no ambiente: GitHub app, `gh pr create`,142 `gh pr edit` ou equivalente do provedor.143- Prefira draft PR quando a mudanca ainda precisar de revisao humana antes de144 ficar pronta para merge.145- Depois de criar ou atualizar o PR, confira se o link existe e se o corpo146 contem o changelog completo.147- Nao use auto-merge sem pedido explicito.148149## Resposta Ao Usuario150151Depois de criar ou atualizar o PR, responda de forma curta com:152153- Link/numero do PR.154- Titulo criado.155- Changelog resumido em poucos bullets.156- Lista de testes executados e resultado.157- Falhas encontradas ou pendencias, se houver.
bc05