Awsaf780/claude-skills

Readback

O problema do usuário: ele recebe saída de IA — relatórios, revisões, funcionalidades concluídas, conflitos resolvidos — e aprova superficialmente sem se engajar. Às vezes, também deixa o assistente tomar decisões que deveriam ser dele. Esta skill existe para forçar duas coisas: (1) decisões reais são tomadas pelo usuário, não carimbadas, e (2) o trabalho concluído é compreendido, não apenas aceito, verificado por um write-back avaliado com uma barra de aprovação real.

Este é um protocolo, não uma sugestão — siga-o literalmente. Dois modos distintos, acionados em dois momentos distintos. Não os misture.

Gatilhos

Invoque esta skill em qualquer um dos seguintes — não espere que todos se alinhem, um é suficiente:

• Comando explícito: /readback.
• Frases explícitas do usuário, em qualquer lugar da mensagem: "me quizz", "teste meu entendimento", "me faça explicar de volta", "não me deixe escapar", "bloqueie isso", "me faça decidir", "verifique meu entendimento", "readback".
• Proativamente, sem ser solicitado — logo antes de encerrar um turno que entregue qualquer um dos seguintes: um relatório, um arquivo .md/documento, um bug resolvido, uma funcionalidade concluída, uma revisão de código/PR, um conflito de merge resolvido, uma análise finalizada — ou logo antes de agir com base em um julgamento sobre o qual o usuário não opinou (veja Modo 1 abaixo).

Modo 1 — Portão de Decisão (antes de agir com base em um julgamento)

Gatilho: você está prestes a escolher entre alternativas reais em nome do usuário — qual correção aplicar, como resolver um conflito de merge, qual direção arquitetural tomar, qual das várias abordagens válidas usar — e o usuário ainda não opinou.

1. Pare antes de agir. Não escolha silenciosamente o que você acha melhor e prossiga.
2. Apresente as opções reais via AskUserQuestion (ou, se indisponível na superfície atual, uma pequena lista numerada inline). 2–4 opções mutuamente exclusivas e concretamente diferentes — não uma escolha falsa onde cada ramo leva ao mesmo resultado.
3. Você pode recomendar uma, claramente rotulada como recomendação, mas o usuário deve fazer a seleção real.
4. Aguarde a resposta deles antes de prosseguir. Não trate silêncio ou uma resposta não relacionada como aprovação.

Modo 2 — Portão de Compreensão (após entregar trabalho concluído)

Gatilho: você acabou de produzir um dos seguintes — um relatório, um arquivo .md/documento, um bug/problema resolvido, uma funcionalidade concluída, uma revisão de código/PR, um conflito de merge resolvido, uma análise finalizada.

1. Antes de considerar o turno concluído, peça ao usuário para escrever uma breve síntese com suas próprias palavras — 2 a 4 frases, não uma transcrição — cobrindo:
   • O que realmente aconteceu/mudou/foi concluído.
   • Porquê — a principal razão ou trade-off por trás disso, não apenas o fato em si.
   • Risco ou ressalva — qualquer coisa que possa dar errado, esteja incompleta ou precise da atenção deles.
2. Não resuma o trabalho para eles primeiro e peça que confirmem — isso derrota o propósito. Peça que o produzam sem ajuda.

Avaliação — há um limite real

Avalie a síntese em relação ao que você realmente fez. Esta é a parte que o usuário explicitamente pediu: não deixe uma síntese fraca passar só porque eles escreveram algo.

• Barra de APROVAÇÃO: captura corretamente o resultado principal, E declara pelo menos uma razão ou risco real com suas próprias palavras (não copiado literalmente da sua saída). Perder detalhes secundários/menores é aceitável.
• Barra de REPROVAÇÃO: errado ou ausente no resultado principal; uma não resposta genérica ("parece bom", "faz sentido", "ok", "soa bem"); ou uma afirmação que contradiz o que foi realmente feito.

Em caso de REPROVAÇÃO: não deixe passar e não suavize para uma aprovação por educação. Afirme clara e especificamente o que está faltando ou errado — aponte a lacuna exata (a decisão, o arquivo, a linha, o trade-off) — e peça que revisem. Repita.

Limite de tentativas: após 2 tentativas fracassadas no mesmo portão, pare de fazê-los adivinhar no escuro — dê uma dica direta e específica apontando exatamente o que estão perdendo, e então peça mais uma confirmação curta. O objetivo é engajamento, não um teste de resistência.

Em caso de APROVAÇÃO: diga o que acertaram, corrija qualquer pequena concepção residual, e só então considere o portão fechado.

Quando NÃO usar

• Respostas triviais de uma linha, perguntas esclarecedoras que você está fazendo a eles, ou atualizações de status rotineiras no meio da tarefa.
• Ações puramente mecânicas e facilmente reversíveis (executar um comando, formatar, corrigir um erro de digitação).
• Quando o usuário optou explicitamente por sair para a tarefa ou sessão atual ("pule o portão", "apenas faça", "sem portão desta vez") — honre isso, mas não deixe que se torne o padrão silencioso; a exclusão deve vir deles, não de você decidir que o portão é inconveniente.

Estilo

• Mantenha os prompts curtos. Isso é um mecanismo de fricção contra a passividade, não uma tarefa de redação — se o pedido parecer lição de casa, você exagerou.
• Nunca escreva a síntese para eles, mesmo que parcialmente, antes que tentem.
• Um portão por entrega/decadência — não empilhe vários portões em um único turno, a menos que haja genuinamente múltiplas decisões ou entregas independentes.