reyalka/astro

Escritor de PRs do Astro

Escreva descrições de pull requests do Astro que ajudam revisores a entender rapidamente a intenção, mudanças de comportamento e validação.

Use esta skill sempre que o usuário solicitar qualquer tarefa de escrita de PR, incluindo:

• criar/abrir um pull request
• criar/abrir um rascunho de pull request
• atualizar um título de PR
• atualizar um corpo/descrição de PR
• escrever notas/resumo de PR

Princípio Central

Descreva a mudança, como funciona e por que é importante.

• Changes explica o que a correção/recurso faz.
• Testing lista qual código de teste foi adicionado ou alterado.
• Docs explica se são necessárias alterações na documentação voltada ao usuário.

Não use seções de PR como um registro de tarefas.

Regras do Título do PR

Use um título humano e amigável para revisores.

• Descreva o resultado em linguagem simples.
• Seja conciso e específico.
• Prefira uma redação que uma pessoa escreveria naturalmente em uma fila de revisão.

Não use:

• prefixos de commit convencionais em títulos de PR (fix:, feat:, docs:, etc.)
• títulos com escopo de commit (fix(cloudflare): ...)

Regras do Corpo

Use esta estrutura:

## Changes

- <Mudança de comportamento e por que é importante>
- <Detalhe de implementação e impacto>

## Testing

- <Teste novo ou alterado e o que ele cobre>
- <Por que uma asserção existente mudou>

## Docs

- <Nenhuma atualização de documentação necessária porque ...>

Changes

Foco em comportamento, abordagem de implementação e impacto.

Inclua:

• o que agora funciona que não funcionava antes
• como a correção/recurso funciona (nível útil para o revisor)
• mudanças de comportamento de confiabilidade/compatibilidade/desempenho voltadas ao usuário

Não inclua:

• "teste adicionado" ou "fixture atualizada" (pertencem em Testing)
• "changeset adicionado"
• notas de processo interno sem impacto no comportamento

Testing

Liste qual código de teste foi adicionado ou alterado e por quê. Os revisores leem esta seção para entender mudanças na cobertura de testes — não para saber que você executou uma suíte de testes.

Inclua:

• novos arquivos de teste ou casos de teste adicionados, com uma breve descrição do que cobrem
• testes existentes que foram atualizados e por que a asserção mudou

Não inclua:

• que os testes passam (o CI mostra isso; é ruído)
• quais comandos você executou
• quantos testes passaram

Docs

Explique claramente o impacto na documentação.

• Se a documentação não for necessária, diga o porquê em uma frase.
• Se a documentação for necessária, link para o PR de documentação.

Diretrizes de Concisão

Por padrão, seja breve. 1-2 marcadores por seção é normal — adicione mais apenas quando a mudança for genuinamente complexa. Um revisor examinando uma fila de PRs deve ser capaz de ler o corpo inteiro em menos de 30 segundos para um patch típico.

Muito verboso:

• Move .optional().prefault({}) para fora de z.preprocess() para a propriedade de configuração server em base.ts e relative.ts, combinando com a correção de integrations do #16531. O Zod 4.4.0 rejeita propriedades ausentes encapsuladas em z.preprocess() antes que o pré-processador ou os defaults internos possam ser executados — mover .optional().prefault({}) para fora da chamada de preprocess resolve isso. Corrige o problema da propriedade server relatado lá por @rururux.
• Adiciona manipuladores invalid_key, invalid_element e options de união discriminada a ambos os mapas de erro do Astro e DB para compatibilidade com Zod 4.4.0. O Zod 4.4.0 expõe falhas de refinamento de chaves de registro (por exemplo, nomes de variáveis de esquema de ambiente) como problemas invalid_key estruturados com erros aninhados em vez de uma mensagem plana. Os manipuladores extraem a mensagem de refinamento real para erros claros voltados ao usuário.
• Todas as mudanças são compatíveis com versões anteriores do Zod 4.3.x. Novos ramos do mapa de erro ativam apenas códigos de problema que o 4.4.0 começa a emitir.

Melhor:

• Move .optional().prefault({}) para fora de z.preprocess() para a configuração server, combinando com a correção de integrations do #16531. Corrige o problema relatado lá por @rururux.
• Adiciona manipuladores invalid_key, invalid_element e options de união discriminada a ambos os mapas de erro para compatibilidade com Zod 4.4.0.
• Compatível com versões anteriores do Zod 4.3.x.

Changesets

Cada PR que modifica um pacote requer um changeset. Apenas mudanças em examples/* são isentas.

Carregue a skill changeset para criar o arquivo de changeset e escrever a mensagem. Ela cobre criação de arquivo, formato, tipos de bump e convenções de mensagem.

Ao escrever o corpo do PR:

• Antes de postar, verifique se um changeset existe. Se o PR modificar um pacote e nenhum existir, crie-o agora usando a skill changeset — não poste o PR sem um.
• Não mencione "changeset adicionado" na seção Changes — é ruído de processo, não uma mudança de comportamento

Verificação Final Antes de Postar

• O título é amigável para revisores (não no estilo de commit)
• Os marcadores de Changes descrevem comportamento/implementação/impacto
• Testing lista código de teste adicionado/alterado, não resultados de execução de teste
• A decisão de Docs é explícita
• O arquivo de changeset existe em .changeset/ para qualquer PR que modifique pacotes — se faltar, crie-o antes de postar