nocolasroy-fr/mr-description

Título e descrição de MR / PR

Tudo o que é escrito no MR/PR (título, descrição) e todas as perguntas feitas ao usuário estão em Francês. Diga « MR » para GitLab e « PR » para GitHub.

Argumentos (opcionais)

Conteúdo recebido: $ARGUMENTS

Argumento	Alvo
https://github.com/<proprietário>/<repositorio>/pull/<n>	PR do GitHub
https://<host>/<grupo>/<repositorio>/-/merge_requests/<iid>	MR do GitLab
#<n> / <n> sozinho	MR ou PR do repositório atual: inferir a plataforma de git remote -v
nada	MR ou PR da branch atual: inferir a plataforma de git remote -v

Se a plataforma não puder ser inferida (host auto-hospedado, vários remotes), pergunte.

Regras rígidas

• Nunca modifique o MR/PR sem confirmação explícita do título e da descrição, e depois uma autorização explícita separada para enviar.
• Nunca invente fatos (número do cartão, contexto, testes). Pergunte ou omita.
• Nenhuma menção ao Claude no conteúdo do MR/PR.

Etapas

1. Identificar e buscar o MR/PR

Resolva o alvo a partir dos argumentos (tabela acima), depois leia a referência correspondente antes de executar qualquer comando:

• references/sources/gitlab.md
• references/sources/github.md

Se o CLI (glab / gh) estiver faltando ou não autenticado, informe ao usuário (sugira ! glab auth login / ! gh auth login) em vez de adivinhar.

Recupere: título atual, descrição atual, branches de origem/destino e as alterações (diff e lista de commits), seguindo a referência. Leia o diff para entender o conteúdo real do MR/PR.

Determine:

• Nome do repositório: último segmento do caminho do projeto, em MAIÚSCULAS.
• Número do cartão: procure no título existente, nome da branch, commits e descrição (ex.: ABC-123, #123). Se nenhum for encontrado, pergunte uma vez; se o usuário disser que não há nenhum, omita os colchetes completamente.

2. Título

Padrão (mesmo em ambas as plataformas):

[<número do cartão>] <NOME DO REPOSITÓRIO> - <assunto> - breve descrição

• Colchetes e número do cartão apenas se existir um cartão.
• <NOME DO REPOSITÓRIO>: nome do repositório em maiúsculas.
• <assunto>: sempre pergunte ao usuário (sugira uma opção inferida do diff como padrão, mas não decida sozinho). Se o título atual já contiver um assunto, proponha mantê-lo.
• Breve descrição: sucinta, em francês, início em minúscula, sem ponto final.
• Se um título existente já estiver bem formado e ainda se adequar ao conteúdo do MR/PR, mantenha-o e informe. Se não se adequar mais, proponha uma versão modificada e mostre o antes/depois.

3. Descrição

Estrutura (Markdown, em Francês):

# Descrição

<Uma ou duas frases resumindo o objetivo do MR/PR.>

## Contexto

<Estado atual do código se for uma modificação; resultado esperado: restrições, objetivos, arquitetura, estratégia.>

## Alterações

- <Alteração de alto nível>
- ...

## Testes

- <Testes escritos, ou testes manuais realizados>

Orientação das seções:

• Descrição: 1–2 frases sobre o objetivo. Proponha um rascunho e peça ao usuário para validar ou corrigir.
• Contexto: descreve o estado antes (para uma modificação) e o resultado esperado (restrições, objetivos, arquitetura, estratégia). Siga ponto por ponto: submeta cada ponto ao usuário para validação e faça uma pergunta sempre que um ponto puder ser esclarecido (por que esta escolha, qual restrição, qual alternativa rejeitada). Não prossiga com suposições não validadas.
• Alterações: apenas lista de alto nível. Entre em detalhes apenas quando a alteração for exatamente sobre esse detalhe ou quando for essencial para entender o MR/PR como um todo.
• Testes: linhas gerais dos testes automatizados escritos (arquivos/áreas cobertas) e dos testes manuais realizados. Se desconhecido, pergunte; nunca afirme testes que não foram realizados.

Prefira agrupar perguntas relacionadas com AskUserQuestion (assunto, número do cartão, pontos de contexto) em vez de várias idas e vindas.

4. Descrição existente (caso de atualização)

Se o MR/PR já tiver uma descrição:

• Mostre o que mudaria, seção por seção (adicionado / modificado / removido), não apenas o novo texto.
• Preserve conteúdo útil que o usuário escreveu (links, capturas de tela, checklists, seções de template, palavras-chave de fechamento como Closes #12); mencione se algo seria descartado.
• Peça confirmação das alterações antes de prosseguir.

5. Confirmar e depois enviar

1. Apresente o título final, o MR/PR alvo (URL, branches) e a descrição completa, e peça confirmação de todos os três.
2. Somente depois, faça uma pergunta separada: autorização para enviar as modificações para a plataforma.
3. Após aprovação, escreva a descrição em um arquivo temporário/scratchpad e atualize o MR/PR com o comando da referência da plataforma. Esses comandos não estão em allowed-tools de propósito para que o usuário receba um prompt de permissão.
4. Relate o resultado e a URL do MR/PR. Se falhar, mostre o erro; não tente novamente silenciosamente.