Revisão de Escrita Técnica

Transforme um documento técnico em inglês de "compreensível" para "publicável". Revise apenas — nunca reescreva o conteúdo. Sinalize suspeitas de erros factuais; não os corrija silenciosamente.

Quando Usar

• Use quando o usuário pedir para revisar, polir ou analisar um documento técnico em inglês, README ou rascunho de blog.
• Use quando a consistência de terminologia ou jargões precisar ser verificada em um documento.

Fluxo de Trabalho

1. Leia primeiro o tom: Leia o documento inteiro e identifique seu tipo (tutorial / referência de API / post de blog / README). Tutoriais toleram uma voz conversacional; referências de API devem ser precisas.
2. Crie uma lista de terminologia: Procure por termos-chave (por exemplo, "callback" vs "callback function", "sign in" vs "log in") e verifique se um conceito é nomeado de várias maneiras. Padronize a forma mais frequente e anote-a na lista de verificação.
3. Verifique parágrafo por parágrafo, mas apenas para estas seis categorias — não se desvie para "este parágrafo está bem escrito":
   • Erros de digitação e ortografia: letras trocadas, palavras duplicadas ("o o"), pares comumente confundidos ("affect/effect", "its/it's", "complement/compliment").
   • Gramática: concordância sujeito-verbo, consistência de tempo verbal dentro de um procedimento, modificadores pendentes, falta de artigos antes de substantivos contáveis singulares.
   • Pontuação: uso consistente de vírgula serial (Oxford); hifens em adjetivos compostos ("ferramenta de linha de comando"); sem espaços duplos após pontos finais; uso consistente de travessões (em dashes) vs. parênteses.
   • Código em linha e nomes próprios: código em linha, comandos, nomes de arquivos e caminhos entre crases; nomes próprios em sua capitalização oficial (GitHub, não github; JavaScript, não Javascript).
   • Estilo de frase: prefira voz ativa ("O sistema chama a função" em vez de "A função é chamada pelo sistema"); corte palavras de preenchimento ("basicamente", "simplesmente", "apenas", "muito"); uma ideia por frase.
   • Estrutura: títulos em forma paralela; listas usam itens paralelos; etapas em um procedimento são imperativas e numeradas; acrônimos são expandidos no primeiro uso.
4. Gere a lista de verificação: liste os itens como "Original → Sugestão → Motivo", com números de linha ou citações curtas. Marque itens incertos com [verify] em vez de forçar uma alteração.
5. Conclua com estatísticas: N itens no total, dos quais erros de digitação x, gramática y, terminologia z, estilo w — para que o autor veja a distribuição rapidamente.

Regras

• Corrija a linguagem, não os fatos. Um erro factual suspeito se torna [verify] This contradicts the usual definition — please confirm, nunca uma "correção" silenciosa.
• Não reescreva parágrafos inteiros. Mesmo um parágrafo prolixo recebe apenas frases específicas e corrigíveis sinalizadas; mantenha a voz do autor.
• Apenas uma passagem. Não fique "polindo mais uma rodada" — o entregável é uma lista de verificação "sem defeitos", não um texto perfeito.

Exemplo Mínimo

Trecho de entrada:

This function will be called by the system after the data is ready, you can use it to basically handle the registration of the callback, the timeout is 5 s, examples on github can be referenced.

Lista de verificação de saída:

1. [Style] "will be called by the system" → "the system calls" (passive → active)
2. [Style] "basically handle" → "handle" (cut filler word)
3. [Terminology] "callback" — if written elsewhere as "callback function", unify on one form (most frequent wins)
4. [Grammar] run-on sentence: split after "ready." into two sentences
5. [Proper noun] "github" → "GitHub" (official casing)

Statistics: 5 items — style 2, terminology 1, grammar 1, proper noun 1.

Limitações

• Realiza revisões; não reescreve. Voz, estrutura e argumento são preservados, de modo que um documento mal argumentado continua mal argumentado após a revisão.
• As alegações técnicas em si estão fora do escopo: uma declaração incerta é deixada intacta em vez de ser "corrigida" silenciosamente para um fato diferente.
• A consistência da terminologia é julgada com base no uso dominante do próprio documento, não contra um glossário externo, a menos que o usuário forneça um.
• Apenas a revisão em inglês é reivindicada. Outras línguas, qualidade de tradução e revisão de localização estão fora desta habilidade.

Anti-padrões

• ❌ Transformar revisão em reescrita: desmontar um parágrafo de modo que a voz e a estrutura do autor se percam.
• ❌ "Correções" alucinadas: alterar uma declaração técnica incerta como se fosse um erro de digitação, introduzindo um erro factual.
• ❌ Verificações apenas de erros de digitação: terminologia inconsistente e estrutura descuidada são os verdadeiros defeitos em documentos técnicos.

…