duncan-buildroom/freeskills

Rede de Segurança — dois desfazeres, para você experimentar

Iniciantes constroem com timidez porque acham que um único prompt ruim estraga tudo. Não estraga. Você tem dois sistemas de desfazer separados e, uma vez configurados, pode tentar coisas que, de outra forma, evitaria. Este skill explica ambos, faz seu primeiro checkpoint real no seu projeto atual e deixa uma folha de dicas que você mantém aberta.

Configuração

Nenhuma. Este skill funciona imediatamente.

Passos

1. Diga o que eles precisam ouvir

Comece com isto, de forma clara: "Você não pode realmente quebrar nada. Existem dois botões de desfazer e, até o final disto, você terá os dois funcionando neste projeto."

Em seguida, nomeie os dois e aponte a diferença — esta é a parte em que todo mundo se confunde:

• /rewind — automático, instantâneo, de curto prazo. O Claude Code tira um instantâneo antes de cada alteração que faz. Você não configurou isto e não precisa. É para "a última coisa que você fez piorou as coisas".
• Checkpoints Git — manuais, permanentes, de longo prazo. Você diz "commit isto como um checkpoint" e aquele estado exato do projeto é salvo para sempre com um nome. É para "me leve de volta a como estava na terça-feira, quando funcionava".

Uma frase para gravar: rewind desfaz movimentos, checkpoints salvam dias.

2. Ensine /rewind corretamente

Cubra exatamente isto, nada mais:

• Digite /rewind no Claude Code. Você recebe uma lista de checkpoints recentes.
• Mais rápido: pressione Esc duas vezes com a caixa de entrada vazia. A mesma coisa.
• Escolha o ponto anterior ao momento em que as coisas deram errado. Seus arquivos voltam a esse estado.
• É automático — acontece antes de cada alteração, você peça ou não.
• O que ele não faz: é para trabalho recente nesta sessão, não para voltar dias atrás. Para isso servem os checkpoints.

Em seguida, peça para eles realmente tentarem uma vez. Diga: "Peça ao Claude para fazer uma pequena alteração sem sentido — mude um título para a palavra BANANA. Olhe para isso. Depois digite /rewind e desfaça." Fazer uma vez remove o medo permanentemente. Apenas ler sobre isso não.

3. Verifique se o Git está neste projeto

Pergunte em qual projeto estão trabalhando e obtenha o caminho da pasta. Verifique se já é um repositório Git — procure por uma pasta .git dentro dele.

Não explique o Git como um sistema de controle de versão. Explique como: "uma forma de salvar um instantâneo permanente de todo o projeto com um nome, para que você possa sempre voltar a ele."

Se não estiver configurado, você faz isso para eles. Eles dizem a palavra, você executa. Nunca entregue a um iniciante uma lista de comandos Git para digitar.

4. Crie o primeiro checkpoint deles agora mesmo

Esta é a parte que precisa realmente acontecer, não apenas ser descrita.

Peça para eles dizerem ao Claude: "Commit isto como um checkpoint chamado 'versão funcionando antes de começar a experimentar'."

Você faz o resto. Depois confirme em voz alta o que acabou de acontecer: "Esse estado do seu projeto agora está salvo permanentemente. Não importa o que você faça a seguir, você pode voltar exatamente para este ponto."

Essa frase é o objetivo principal do skill.

5. Crie o hábito do checkpoint

Dê a eles os três momentos para criar um. Três, não dez:

• Quando algo funciona. No momento em que a página carrega corretamente ou a funcionalidade faz o que deveria. Antes de tocar nela novamente.
• Antes de algo arriscado. Um redesenho grande, uma nova funcionalidade, qualquer coisa sobre a qual você não tem certeza.
• No final de cada sessão. Parte de fechar o laptop — os últimos 10 minutos de uma noite de 90 minutos são o checkpoint mais o próximo passo de uma linha para amanhã.

Diga a eles como nomear checkpoints: diga em que estado o projeto está, não o que você fez. "homepage funcionando no mobile" é melhor do que "alterações".

6. Escreva as três movimentações de recuperação

Estas são as três situações em que eles realmente estarão. Escreva-as como scripts que eles leem em voz alta.

"Eu quebrei e não sei como." Não depure. Digite /rewind, ou pressione Esc duas vezes. Escolha o ponto anterior ao momento em que quebrou. Depois, peça novamente o que queria em um passo menor.

"Voltar um passo." Digite /rewind, escolha o checkpoint mais recente. Ou diga ao Claude: "Desfaça a última alteração que você fez."

"Voltar para esta manhã / para quando funcionava." Diga ao Claude: "Mostre meus checkpoints de hoje." Escolha um pelo nome. Depois: "Leve o projeto de volta ao checkpoint chamado ___ ." O rewind não alcança tão longe — para isso servem os checkpoints.

Adicione a saída de emergência: "Quero a versão antiga de volta, mas também quero manter o que fiz desde então." Diga ao Claude: "Salve o que tenho agora como um checkpoint, depois me leve de volta para ___ ." Nada se perde.

Saída — salve-a

Escreva em ~/claude-safety-net.md. Uma página, nem mais longa — isto é uma folha de dicas, não um manual.

Ela contém: a diferença em uma linha entre os dois sistemas, as movimentações do /rewind incluindo Esc-Esc, a frase exata para criar um checkpoint, os três momentos para criar checkpoint, os três scripts de recuperação palavra por palavra, a saída de emergência para manter ambos e o nome e a data do primeiro checkpoint que acabaram de criar.

Diga a eles o caminho, depois a única ação: mantenha este arquivo aberto em uma aba enquanto constroem. Diga também a verdade — agora que ambos os desfazeres estão funcionando, o movimento correto é tentar algo que antes estavam nervosos demais para tentar.

Exemplo (entrada → saída)

Entrada: "Estou trabalhando no meu site portfólio e quero tentar um layout completamente diferente, mas estou com medo de perder a versão que funciona."

Saída (salva em ~/claude-safety-net.md):

SEUS DOIS DESFAZERES
Rewind desfaz movimentos. Checkpoints salvam dias.

REWIND — instantâneo, automático
Digite /rewind, ou pressione Esc duas vezes em uma caixa de entrada vazia.
Escolha o ponto anterior ao momento em que deu errado. Os arquivos voltam.
Apenas para trabalho recente, não para voltar dias atrás.

CHECKPOINT — permanente, você o solicita
Diga: "Commit isto como um checkpoint chamado '<em>em que estado está</em>'."
Crie um quando algo funcionar, antes de algo arriscado e no final de cada sessão.

SEU PRIMEIRO CHECKPOINT
"portfolio funcionando antes do experimento de layout" — salvo em 2026-07-30.
Você sempre pode voltar exatamente a isto.

SE EU QUEBREI
Não depure. /rewind, escolha o ponto anterior ao momento em que quebrou, peça novamente em um passo menor.

VOLTAR UM PASSO
/rewind e escolha o mais recente. Ou: "Desfaça a última alteração que você fez."

VOLTAR PARA QUANDO FUNCIONAVA
"Mostre meus checkpoints de hoje."
"Leve o projeto de volta ao checkpoint chamado ___ ."

MANTER AMBAS AS VERSÕES
"Salve o que tenho agora como um checkpoint, depois me leve de volta para ___ ."

Próxima ação: vá tentar o novo layout. O antigo está salvo.

Notas / casos extremos

• A falha que isto previne é a construção tímida — iniciantes evitando a versão interessante porque estão protegendo a que funciona. O objetivo principal do checkpoint é a permissão para experimentar.
• Faça-os realmente executar o teste de rewind no Passo 2 e realmente criar o checkpoint no Passo 4. Um skill que apenas descreve redes de segurança não cria a sensação de tê-las.
• Nunca entregue a eles comandos Git brutos. Eles dizem a frase, o Claude executa. Se quiserem aprender Git direito depois, esse é um outro dia.
• Se o projeto ainda não for um repositório Git, configure-o sem fazer alarde. É um passo, não custa nada e leva 10 segundos.
• Se eles já quebraram algo agora mesmo, faça o Passo 6 primeiro e configure o resto depois. Apague o fogo, depois instale o alarme.
• Se estiverem encarando um erro e não souberem se devem usar rewind, passe para o error-decoder — ele classifica erros em ignorar, corrigir ou usar rewind.