mr-feedback

O que mr-feedback faz?

Busque um Merge Request do GitLab, avalie o quão pronto ele está para ser revisado e escreva um relatório de feedback em um novo arquivo markdown que pode ser copiado diretamente para uma nota do MR.

O que fazer

Julgue a prontidão para revisão. Verifique se o MR tem contexto, clareza de escopo, instruções de teste e orientação para o revisor que permitam que um revisor o analise de forma eficiente.

Por que

Um MR bem preparado sinaliza cuidado e é revisado mais rápido e melhor. O relatório deve fazer um bom MR se sentir reconhecido e dar a um mais fraco passos concretos e encorajadores para aumentar sua prontidão.

O que não fazer

Não revise ou critique o código em si e não sugira mudanças de código/lógica

Preferências

Antes de fazer qualquer outra coisa, leia reference/preferences.md (relativo a esta skill). Ele é a fonte da verdade para todo comportamento configurável – idioma de saída, tom, método de busca, ferramentas permitidas e caminho de saída. Este SKILL.md não reafirma esse valores; sempre leia-os do arquivo de preferências.

Precedência, da maior para a menor:

1. Uma instrução explícita na solicitação atual do usuário (por exemplo, "desta vez escreva em Português").
2. reference/preferences.md.
3. Instruções nesta skill.

Entradas

O usuário fornece um dos:

• Uma URL completa do MR: https://gitlab.com/<grupo>/<subgrupo>/<projeto>/-/merge_requests/<iid>
• Um caminho de projeto + iid do MR: grupo/subgrupo/projeto + 42

Extraia da URL:

• project_id = o caminho entre o host e /-/merge_requests/ (codifique como URL group%2Fsubgroup%2Fproject ao chamar ferramentas)
• mergeRequestIid = o número após /-/merge_requests/

Se algum estiver faltando ou ambíguo, pergunte antes de buscar.

Fluxo de trabalho

Use o método e as ferramentas declarados em reference/preferences.md. As etapas abaixo dizem quais informações reunir e por quê, não qual ferramenta chamar – escolha a ferramenta correspondente das preferências para cada uma.

1. Metadados do MR - título, descrição, autor, estado, branch origem/destino, flag de rascunho, labels, milestone, aprovações, status de merge.
2. Lista de arquivos alterados - caminhos + contagem de add/del; fornece escopo/tamanho sem puxar cada diff.
3. Diffs de amostra para confirmar se a descrição corresponde à realidade - em lotes de 3-5 arquivos. Use isso apenas para verificar o escopo e se os testes foram tocados – não para criticar código. Pule lockfiles, arquivos gerados e renomeações puras; amostre se o MR for enorme.
4. Commits - use o resumo de commits já incluído nos metadados do MR (etapa 1) para sinal de higiene/atomicidade (contagem de commits / resumo de adições).
5. Status de CI - estado do pipeline mais recente para o MR (passou/falhou/nenhum).
6. Avalie de acordo com a grade em reference/rubric.md.
7. Escreva o relatório em um novo arquivo (veja Saída) usando reference/report-template.md.
8. Informe ao usuário o caminho do arquivo e ofereça para refinar tom/extensão antes de copiar/colar.

Leia reference/rubric.md antes de pontuar e reference/report-template.md antes de escrever. Não invente dados – se uma busca não retornar nada para uma categoria (por exemplo, nenhum pipeline), marque como "não disponível" em vez de adivinhar.

Cada categoria da grade carrega uma Razão explicando por que ela importa para o autor. Quando você relatar uma lacuna em "Para aumentar a prontidão", sempre inclua por que ela importa para o autor – para que o feedback explique o propósito por trás de cada solicitação, não apenas a solicitação em si.

Não copie a Razão da categoria literalmente. A Razão é um contexto que cobre toda a categoria; reescreva-a para se adequar ao problema exato que você encontrou. Referencie apenas a coisa específica que está errada e nunca mencione aspectos da categoria que estão bons. Por exemplo, se a branch está atrás da master mas o pipeline está verde, explique por que estar atrás da master importa – não mencione o pipeline, já que passou. O "por que importa" deve ser verdadeiro para a lacuna específica deste MR, não uma declaração genérica sobre a categoria.

Saída

Escreva no caminho de saída declarado em reference/preferences.md, resolvendo seus placeholders e criando as pastas que o caminho precisar.

Salvaguardas

• Somente leitura. Esta skill nunca posta notas, aprova ou modifica o MR. Ela apenas escreve um arquivo markdown local. O usuário decide se vai colá-lo.
• Não inclua segredos/tokens que possam aparecer em diffs no relatório.
• Se o MR for um rascunho ou ainda não tiver diff, você ainda pode julgá-lo e gerar o relatório, mas certifique-se de ser explícito sobre isso.