edição-de-prosa

---

name: edição-de-prosa description: Cortar e modelar trabalhos escritos: docs, runbooks, READMEs, relatórios, prompts e instruções para modelos. Use ao editar ou revisar prosa, quando um rascunho estiver inchado ou cheio de rodeios, ou antes de publicar trabalhos escritos.

Edição de prosa

Assume verdade absoluta. Trata das palavras e da forma, não dos fatos. NOTES.md ao lado deste arquivo contém exemplos trabalhados.

O teste

Cada frase diz ao leitor o que fazer, o que esperar ou o que acontece se errar; corte aquela que não fizer nada disso. Concisão não é brevidade: nunca corte substância para atingir um comprimento, corte o andaime em torno dela.

Corte

• Prefácios desnecessários. Coloque a substância na primeira frase.
• Reafirmação. Diga uma vez, no melhor lugar.
• Transições de preenchimento ("vale notar que", "como mencionado acima", "a fim de").
• Editorialização que não muda comportamento ("sem glamour mas importante").
• Quantificação vaga ("uma parcela surpreendente"). Dê a verdadeira razão pela qual funciona, ou corte a afirmação.
• Rodeios que evitam compromisso. Declare a incerteza real de forma clara, com os critérios de decisão.
• Citações em bloco para ênfase. Mantenha-as apenas para avisos que mudam o que alguém faz.

Corte o que marca o texto como gerado

Um modelo escolhe o que se encaixa no maior número de leitores; um escritor escolhe para um leitor e um assunto. Procure a estrutura primeiro, porque os hábitos de palavras mudam a cada modelo. Uma frase só fica se der a este leitor algo que ele não tem.

• Encenação em vez de afirmação. "Não X mas Y" quando ninguém disse X, um fechamento de uma linha que repete o ponto, uma preparação antes do ponto, um ditado que soa profundo e não afirma nada. Afirme o fato.
• Ritmo por regra. Tríades e travessões em toda parte, aberturas de frase repetidas, qualificadores empilhados. Use três itens quando houver três.
• Inflação. Fatos comuns chamados de cruciais ou robustos, linguagem de vendas, autoridades não nomeadas, sufixos "-ção" implicando significado. Diga o que faz, ou corte.
• Formatação por regra. Negrito em cada item e um título em cada pensamento, onde a ênfase ou estrutura não significa nada.
• Sobras de rascunho. Invólucros de chat, avisos de limitação de conhecimento, um título repetido como primeira frase, texto sobre o documento em vez de seu assunto.
• O leitor errado. Reexplicar o que já sabem, fazendo a decisão chegar por último.

Mantenha o que o escritor quis dizer e não acrescente nada para substituir o que cortou. Um contraste real, uma verdadeira lista de três ou uma fonte citada fica; um marcador conta apenas quando não acrescenta nada.

Protegido: o porquê nunca é supérfluo

Mantenha uma frase que explique por que (esta ordem, esta ferramenta, esta verificação primeiro, esta etapa não pode ser pulada) embora não emita instrução: a razão permite que o leitor lide com o caso que o documento não previu e veja quando o procedimento não se aplica mais. Dê a razão onde não for óbvia, acima de tudo para regras de segurança e conformidade, onde a intenção é o que permite que alguém aplique a regra onde nenhuma cobre. Quando uma frase carrega floreio e uma razão, reescreva-a para manter a razão. O teste é "o leitor ficaria pior nisso sem ela".

Corte estrutura não merecida

Adicione níveis, tabelas, matrizes, títulos aninhados ou ramificações apenas onde o trabalho precisar deles, não porque parecem rigorosos. Pergunte: o trabalho realmente se ramifica aqui (se todo leitor segue o mesmo caminho, é uma lista)? Esta etapa é necessária ou só parece completa? Se o procedimento tem quatro etapas, escreva quatro: um procedimento de quatro etapas seguido na primeira leitura é melhor do que um correto de nove etapas que é folheado. Armadilhas, armadilhas de sequência e o porquê permanecem.

Instruções que um modelo carrega

Folhas de regras, skills, arquivos de função e prompts são pagos em tokens toda vez que são carregados, e o leitor é um modelo que precisa da regra, não da história dela. Precifique-os por quando carregam (D28):

• Toda sessão (folhas de regras, descrições de skill e função): apenas a regra. Uma descrição diz o que a skill cobre e quando carregá-la, em menos de 300 caracteres; tools/check.py aplica os orçamentos.
• Em uso (um corpo de skill ou função): a regra mais uma cláusula de razão. Apenas uma falha concreta onde a regra pareceria opcional sem ela, sem datas, contagens ou nomes de projeto.
• Sob demanda (NOTES.md, EVIDENCE*.md): os incidentes, números, datas e fontes. O corpo aponta para lá.

Escreva no imperativo. Não reafirme uma regra que outro arquivo carregado contém; aponte para ela pelo nome. Um requisito fixado em docs/REQUIREMENTS.tsv se move com sua reescrita, nunca silenciosamente.

Forma de um procedimento

Propósito → Quando usar → Antes de começar → Etapas → Verificar → Se não funcionar → Escalar

• Nunca omita Verificar: é a parte mais frequentemente pulada e mais valiosa.
• Uma ação por etapa. Nomeie os elementos da UI exatamente. Dê o caminho completo.
• Sinalize etapas irreversíveis antes da etapa, não depois.
• Escreva para um estranho competente: conhece o domínio, nunca viu este ambiente.
• Títulos nomeiam algo que alguém pesquisaria. Sem datas, versões ou "v2".

Tom

• Linguagem clara, frases curtas.
• Não suavize restrições com dentes (perda, rescisão, perda de dados, responsabilidade pessoal): diga isso claramente.
• Vincule a documentação do fornecedor em vez de copiá-la, e documente apenas o que é específico para como você trabalha: uma reimpressão fica desatualizada na chegada.