El 9 de octubre, en una sola noche, cerré cuatro automatizaciones que había dejado para el lunes. No las construí yo solo ni en secuencia: las repartí entre agentes que trabajan en paralelo, y la tarea más larga tomó 458 segundos. Lo que me dijo qué automatizar y qué dejar quieto salió de una skill de Wick.
Wick es un repositorio que mantiene Ryan, de Agora Dynamics, que es amigo mío: avisado queda, y léelo con eso en mente. Está bajo licencia MIT. Aquí el repo: github.com/agoradynamics/wick. Lo cuento con mis palabras, mis fechas y lo que me falló.
Qué es Wick
Wick es un paquete que le pones a Claude Code para que deje de empezar de cero cada mañana. La idea de fondo es simple: una carpeta de archivos de texto donde queda lo que el asistente aprende de ti, tus decisiones y por qué las tomaste. Son archivos que puedes abrir, editar o borrar. No hay cuenta ni servicio de por medio.
Alrededor de esa memoria trae tres cosas más. Una colección de marcos de pensamiento para decidir mejor, un grupo de skills con nombre propio (revisar código, red team, resumir un changelog, consolidar memoria, entre otras) y un puñado de scripts de auditoría: uno que limpia datos sensibles antes de publicar, otros que miden qué tan viejo está lo que hay en la memoria o si las rutas siguen existiendo.
Del paquete uso dos piezas y sumo un método propio, y los tres me cambiaron cómo trabajo: la skill wick-automate, mi versión del observador, que registra qué herramientas uso, y la manera de seguir al repo sin perder el control de lo que entra a mi máquina. Ese último punto es lo que más vale la pena copiar.
Fuente: repositorio de Wick, Agora Dynamics, licencia MIT
Cómo lo adopto sin mirar a ciegas
No tengo permiso de escritura sobre el repo de Ryan, y no debería. Lo que hago es tener un fork privado mío y traer las versiones nuevas cuando yo quiero. Cada versión sigue el mismo camino:
- Traer lo nuevo del repo original, con etiquetas, y comparar contra él, no contra mi copia.
- Auditar antes de mezclar: caracteres Unicode escondidos, frases que parezcan instrucciones inyectadas, qué hacen los scripts nuevos y si salen a internet.
- Crear una rama de sincronización y mezclar ahí. Debe entrar limpio, sin conflictos, porque no tengo cambios propios.
- Abrir una solicitud de cambio en mi propio fork, revisarla y mezclar.
- Etiquetar la versión adoptada con fecha y comprobar que mi copia no difiere del original.
- Nunca empujar nada al repo original. El remoto está configurado para que no se pueda.
| Versión | Fecha en que la adopté | Qué traía o qué revisé |
|---|---|---|
| 1.3.0 | 26 jun 2026 | Primera adopción |
| 1.4.0 | 20 jul 2026 | La skill wick-automate oficial y el observador. Mezcla limpia: 8 archivos, 162 líneas añadidas, 6 quitadas. |
| 1.6.0 | 5 ago 2026 | Mezcla limpia, sin conflictos |
| 1.8.0 | 30 sep 2026 | 16 commits, 65 archivos. Auditoría: 0 caracteres escondidos, 2 falsos positivos del detector de inyección, scripts nuevos que solo llaman a un modelo local y a git, 4 escáneres sin hallazgos. |
Ese cuadro es aburrido a propósito. El valor de una auditoría es que cuando algo sale mal ya sabes dónde mirar, y que cuando sale bien no tienes que confiar en que sale bien. En la mezcla de la 1.4.0 mi escáner de secretos marcó 6 coincidencias; las leí una por una y eran texto de documentación que menciona las palabras "secret" o "password", sin ningún valor real. La disciplina es leer la línea antes de aprobar o de ignorar el aviso.
wick-automate: programa o skill
Esta es la pieza que me hizo poner atención a Wick. Es una skill que te ayuda a decidir si algo vale la pena automatizar y, si vale, de qué tipo. Su idea central: la tercera vez que haces algo a mano debería ser la última.
Mira tres clases de repetición y las trata distinto:
| Clase | Qué es | Ejemplo mío |
|---|---|---|
| Literal | El mismo comando N veces | Sale un alias, nada más |
| Estructural | La misma forma de tarea con otros datos | Cerrar una sesión de trabajo: resumen, devlog, memoria, commit |
| Fricción | Una tarea lenta o propensa a errores aunque sea rara | Un arreglo de enlaces de skills que se rompía |
Después decide con una cuenta honesta: el beneficio (cuántas veces, cuánto cuesta cada una) contra el costo de construirlo y mantenerlo. Y tiene una puerta que me parece lo más inteligente: la prueba de estabilidad. Si los pasos cambian cada vez que lo haces, espera. Automatizar algo que todavía estás descubriendo solo congela un error.
Lo último que hace es elegir el tipo. Un programa, que es un script que hace siempre lo mismo. O una skill, que es un procedimiento con criterio. O las dos: la skill decide qué hacer y el programa hace el trabajo mecánico.
Le añadí un paso propio, el 2.5. Antes de proponer algo nuevo, pregunta si ya existe una regla que se incumple. Si la regla se rompe cada vez que hay prisa, el problema no es disciplina sino que el camino correcto cuesta más teclas que el incorrecto. Entonces la propuesta no es una regla más fuerte, es acortar el camino correcto.
Lo que salió de usarlo
| Qué detectó | Qué construimos | Qué tan seguro estoy |
|---|---|---|
| Cerrar sesión con la misma rutina unas 6 veces en una conversación | Skill /logs (decide qué registrar) + un programa para el commit | Probado en 2 repos distintos |
| Skills copiadas en vez de enlazadas: el mismo error 3 veces en una sesión | Un modo --fix-safe: arregla solo los 2 casos sin dudas y deja lo demás a mano | Probado en un caso de prueba de 3 situaciones antes de tocar nada real |
| Dos horas para una película de 30 segundos | Un repo propio con revisiones automáticas (motion-forge, el del post de HyperFrames) | Medido: unas 2 horas la primera, unos 40 minutos la cuarta |
| Ninguna de mis 20 skills de crecimiento cubría un análisis estratégico | Una skill nueva dentro del playbook de SVDIGINET | Probada en un caso, falta uso |
El caso que mejor muestra el método es el 9 de octubre. Teníamos cuatro propuestas aprobadas y las despaché a la vez, a agentes distintos. Uno tardó 458 segundos, otro 227 y otro 56; la cuarta la construí yo. Sumadas en fila, las tres de los agentes son 741 segundos, unos 12 minutos. En paralelo esperé lo que tardó la más larga: 458 segundos, unos 7 minutos y medio. Ahorré casi 5 minutos, en teoría: no medí la versión en fila. Es poco, y lo digo porque el número honesto es ese. Lo que sí cambió fue que no quedó nada pendiente para el lunes.
Una cosa más que ayuda a ver las repeticiones sin acordarte: mi versión del observador, adaptada de la de Wick. Es un gancho que corre después de cada herramienta y anota en un archivo local, que no sube a ningún lado, qué herramienta y sobre qué. Cuando le pido a la skill que revise ese archivo, no depende de mi memoria sino de lo que hice.
El error que repetí dos veces
El 5 de agosto revisé si Ryan había publicado algo nuevo. Miré mi fork, vi que estaba igual y dije "sin cambios". Él ya había subido la 1.5.0 y la 1.6.0. Mi fork solo me dice si estoy al día conmigo mismo. El 30 de septiembre lo repetí: miré mi copia primero y mezclé antes de auditar.
Ya está en la regla de mi flujo: lo primero es comparar contra el repo original. Estos son los comandos, y cada uno es de solo lectura:
git remote -v git fetch upstream --tags git diff upstream/main --stat git log --oneline origin/main..upstream/main | wc -l
Un reporte de "no hay cambios" solo vale si el instrumento podía haber visto el cambio. Si miro mi propia copia, no podía.
Lo que no sé
- Si el observador funciona dentro de Codex. Lo conecté en el mismo formato que un gancho que sí corre, pero no lo he visto dispararse en una sesión real.
- Cuánto ahorro de verdad. Mis cifras de tiempo son por tarea, no un total del mes.
- Si mi lectura es neutral. Ryan es amigo mío y la idea de wick-automate se la propuse yo a él. Lee esto como un usuario contento, no como una reseña.
- Cuántas de las skills del paquete que no uso valen la pena. Uso dos piezas de muchas.
Revisa tu fork
Si sigues un repo ajeno con un fork, pega esto en Claude Code. Solo lee, no cambia nada:
Dime si mi fork de un repo ajeno está al día, sin cambiar nada. Corre `git remote -v` y dime cuál remoto es el mío (origin) y cuál es el original (upstream). Luego `git fetch upstream --tags` y compara contra upstream/main, no contra origin/main: dime cuántos commits me faltan y qué archivos cambian. Si no existe un remoto upstream, dímelo y para.
Si te interesa lo que cuestan mis sesiones largas con agentes, está en Claude Code compacta tus sesiones inactivas. Y el otro repo de esta serie, el que hace videos desde HTML, está en su propio post.
