duncan-buildroom/freeskills

Red de Seguridad — dos deshaceres, para que puedas experimentar

Los principiantes construyen con timidez porque piensan que un mal prompt lo arruina todo. No es así. Tienes dos sistemas de deshacer separados, y una vez configurados puedes probar cosas que de otro modo evitarías. Esta skill explica ambos, crea tu primer checkpoint real en tu proyecto actual y deja una hoja de trucos que mantienes abierta.

Configuración

Ninguna. Esta skill funciona de fábrica.

Pasos

1. Diles lo que necesitan escuchar

Empieza con claridad: "Realmente no puedes romper nada. Hay dos botones de deshacer, y al final de esto tendrás ambos funcionando en este proyecto."

Luego nómbralos y explica la diferencia — esta es la parte que todos confunden:

• /rewind — automático, instantáneo, a corto plazo. Claude Code toma una instantánea antes de cada cambio que hace. No lo configuraste y no tienes que hacerlo. Es para "lo último que hiciste lo empeoró".
• Git checkpoints — manuales, permanentes, a largo plazo. Dices "confirma esto como un checkpoint" y ese estado exacto del proyecto se guarda para siempre con un nombre. Es para "llévame de vuelta a cómo estaba el martes cuando funcionaba".

Una línea para fijarlo: rewind deshace movimientos, checkpoints guardan días.

2. Enseña /rewind correctamente

Cubre exactamente esto, nada más:

• Escribe /rewind en Claude Code. Obtienes una lista de checkpoints recientes.
• Más rápido: presiona Esc dos veces con la caja de entrada vacía. Lo mismo.
• Elige el punto anterior a cuando las cosas salieron mal. Tus archivos vuelven a ese estado.
• Es automático — ocurre antes de cada cambio, lo pidas o no.
• Lo que no hace: es para trabajo reciente en esta sesión, no para volver días atrás. Para eso están los checkpoints.

Luego haz que realmente lo prueben una vez. Di: "Pídele a Claude que haga un cambio pequeño y sin sentido — cambia un encabezado a la palabra BANANA. Míralo. Luego escribe /rewind y restáuralo." Hacerlo una vez elimina el miedo para siempre. Leer sobre ello no.

3. Verifica si Git está en este proyecto

Pregunta en qué proyecto están trabajando y obtén la ruta de la carpeta. Verifica si ya es un repositorio Git — busca una carpeta .git en ella.

No expliques Git como un sistema de control de versiones. Explícalo como: "una forma de guardar una instantánea permanente de todo el proyecto con un nombre, para que siempre puedas volver a ella."

Si no está configurado, lo haces tú por ellos. Ellos dicen la palabra, tú lo ejecutas. Nunca le des a un principiante una lista de comandos de Git para escribir.

4. Crea su primer checkpoint ahora mismo

Esta es la parte que realmente debe ocurrir, no solo describirse.

Diles que le digan a Claude: "Confirma esto como un checkpoint llamado 'versión funcional antes de empezar a experimentar'."

Tú haces el resto. Luego confirma en voz alta lo que acaba de pasar: "Ese estado de tu proyecto ahora está guardado permanentemente. Hagas lo que hagas después, puedes volver exactamente a esto."

Esa frase es el punto central de la skill.

5. Establece el hábito del checkpoint

Dales los tres momentos para hacer uno. Tres, no diez:

• Cuando algo funciona. En el momento en que la página carga bien o la característica hace lo que debe. Antes de tocarlo de nuevo.
• Antes de algo arriesgado. Un rediseño grande, una nueva característica, cualquier cosa de la que no estés seguro.
• Al final de cada sesión. Parte de cerrar el portátil — los últimos 10 minutos de una noche de 90 minutos son checkpoint más el siguiente paso de una línea para mañana.

Diles cómo nombrar los checkpoints: di en qué estado está el proyecto, no lo que hiciste. "página principal funcionando en móvil" es mejor que "cambios".

6. Escribe los tres movimientos de recuperación

Estas son las tres situaciones en las que realmente se encontrarán. Escríbelas como guiones que leen en voz alta.

"Lo rompí y no sé cómo." No depures. Escribe /rewind, o presiona Esc dos veces. Elige el punto anterior a que se rompiera. Luego vuelve a pedir lo que querías en un paso más pequeño.

"Volver un paso atrás." Escribe /rewind, elige el checkpoint más reciente. O dile a Claude: "Deshaz el último cambio que hiciste."

"Volver a esta mañana / a cuando funcionaba." Dile a Claude: "Muéstrame mis checkpoints de hoy." Elige uno por nombre. Luego: "Lleva el proyecto de vuelta al checkpoint llamado ___." Rewind no alcanzará tan lejos — para eso están los checkpoints.

Añade la escapatoria: "Quiero recuperar la versión anterior pero también quiero conservar lo que hice desde entonces." Dile a Claude: "Guarda lo que tengo ahora como un checkpoint, luego llévame de vuelta a ___." Nada se pierde.

Salida — guárdala

Escribe en ~/claude-safety-net.md. Una página, no más larga — esto es una hoja de trucos, no un manual.

Contiene: la diferencia en una línea entre los dos sistemas, los movimientos de /rewind incluyendo Esc-Esc, la frase exacta para hacer un checkpoint, los tres momentos para hacer checkpoint, los tres guiones de recuperación palabra por palabra, la escapatoria para conservar ambos, y el nombre y la fecha del primer checkpoint que acaban de hacer.

Diles la ruta, luego la única acción: mantén este archivo abierto en una pestaña mientras construyes. También diles la verdad — ahora que ambos deshaceres funcionan, el movimiento correcto es ir a probar algo que antes tenían demasiado miedo de probar.

Ejemplo (entrada → salida)

Entrada: "Estoy trabajando en mi sitio portafolio y quiero probar un diseño completamente diferente pero tengo miedo de perder la versión que funciona."

Salida (guardada en ~/claude-safety-net.md):

TUS DOS DESHACERES
Rewind deshace movimientos. Checkpoints guardan días.

REWIND — instantáneo, automático
Escribe /rewind, o presiona Esc dos veces en una caja de entrada vacía.
Elige el punto anterior a que saliera mal. Los archivos vuelven.
Solo para trabajo reciente, no para volver días atrás.

CHECKPOINT — permanente, tú lo pides
Di: "Confirma esto como un checkpoint llamado '<en qué estado está>'."
Haz uno cuando algo funciona, antes de algo arriesgado, y al final
de cada sesión.

TU PRIMER CHECKPOINT
"portafolio funcionando antes del experimento de diseño" — guardado 2026-07-30.
Siempre puedes volver exactamente a esto.

SI LO ROMPÍ
No depures. /rewind, elige el punto anterior a que se rompiera, vuelve a pedir más pequeño.

VOLVER UN PASO ATRÁS
/rewind y elige el más reciente. O: "Deshaz el último cambio que hiciste."

VOLVER A CUANDO FUNCIONABA
"Muéstrame mis checkpoints de hoy."
"Lleva el proyecto de vuelta al checkpoint llamado ___."

CONSERVAR AMBAS VERSIONES
"Guarda lo que tengo ahora como un checkpoint, luego llévame de vuelta a ___."

Siguiente acción: ve a probar el nuevo diseño. El anterior está guardado.

Notas / casos límite

• El fallo que esto previene es construir con timidez — principiantes que evitan la versión interesante porque protegen la que funciona. El punto central del checkpoint es el permiso para experimentar.
• Haz que realmente hagan la prueba de rewind en el Paso 2 y que realmente creen el checkpoint en el Paso 4. Una skill que solo describe redes de seguridad no crea la sensación de tener una.
• Nunca les des comandos de Git en bruto. Ellos dicen la frase, Claude la ejecuta. Si quieren aprender Git correctamente después, ese es otro día.
• Si el proyecto no es un repositorio Git todavía, configúralo sin darle importancia. Es un paso, no cuesta nada y toma 10 segundos.
• Si ya han roto algo en este momento, haz primero el Paso 6 y configura el resto después. Apaga el fuego, luego instala la alarma.
• Si están mirando un error y no saben si rebobinar, deriva a error-decoder — clasifica errores en ignorar, corregir o rebobinar.