4. Skills y slash commands — qué repetición vale la pena colapsar en una línea

Esta es la parte 4 de la serie Alice Way. Las partes 2 Diseño de persona y 3 Sistema de memoria cubrieron dónde se inscribe la mente y dónde se mantiene. Este artículo cubre la capa siguiente: cómo comprimir los movimientos repetidos de la mente en una sola línea.

0. Un skill condensa el movimiento mental repetido en una línea

Hay dos tipos de contenido en la mente del operador. Un tipo es "qué necesito decidir ahora mismo." El otro es "qué procedimiento despliega esa decisión." El primero cambia cada vez. El segundo a menudo es el mismo.

Si el mismo procedimiento se repite cada día y se explica al colaborador con las mismas palabras cada día, ese procedimiento ya se ha solidificado en un patrón mental. Un movimiento solidificado merece un nombre de una línea.

Los skills y slash commands son ese nombre. Condensan un movimiento mental recurrente en una invocación de una sola palabra. Los nombres existen para que el mismo procedimiento no tenga que desarrollarse en lenguaje cada vez.

Este artículo es una colección de criterios para qué repeticiones merecen ese nombre, y cómo diseñar esos nombres.

El mecanismo de "skill" en sí está tomado del sistema Skill de Anthropic Claude Code. Este artículo es un registro de cómo se usa ese mecanismo, no una invención del mismo.

1. Criterios de promoción — qué repeticiones se convierten en skills

No todo procedimiento diario debería convertirse en un skill. Solo los que pasan todos estos cinco obtienen un nombre de una línea.

1.1 ¿Ha repetido al menos dos veces?

Una vez es una coincidencia. Dos veces es un patrón. El mismo procedimiento tiene que haberse ejecutado al menos dos veces para calificar.

Este criterio es el más simple pero el más frecuentemente violado. Bloquea el impulso de "probablemente haré esto mucho, voy a crear un skill por anticipado." La repetición futura es una suposición; la repetición pasada es un hecho. Solo se promueve sobre la base de hechos.

1.2 ¿Están claramente definidos el inicio y el fin?

Un skill necesita condiciones de inicio y fin inequívocas. "Entrar en un proyecto," "cerrar una sesión," "construir después de lint" — tienen bordes claros. "Escribir código" no los tiene, en ninguna dirección, y no se convierte en un skill.

Sin bordes claros, el colaborador no sabe dónde detenerse tras la llamada. Un skill con un final borroso obliga al operador a detenerlo manualmente cada vez.

1.3 ¿Es decidible el momento de invocación?

La invocación viene en dos sabores. Consciente del operador (slash commands) o impulsada por el sistema (hooks — siguiente artículo). De cualquier manera, el momento de invocación tiene que ser decidible.

"Depende del momento" no es un skill. Eso devuelve el juicio al colaborador en cada ocasión, y ese juicio en sí mismo consume atención fresca.

1.4 ¿Toma la misma entrada (o solo args simples)?

La entrada tiene que ser simple. Sin argumentos, o uno o dos argumentos cortos. Muchos argumentos convierten su relleno en un nuevo procedimiento propio, y los ahorros desaparecen.

1.5 ¿Puede verificarse el resultado de forma consistente?

Después de ejecutar, el skill debería permitir que el colaborador auto-verifique el resultado. Señales como "éxito," "fallo," "precondición faltante" deben ser claras.

Un skill cuyos resultados no se pueden verificar obliga al operador a comprobar manualmente cada vez. La mitad del beneficio desaparece en ese punto.

2. Skills · slash commands · funciones — separar roles

Los tres reducen la repetición, pero juegan roles distintos.

Un skill es la definición de procedimiento compartida que tanto los slash commands como los hooks pueden invocar. El mismo procedimiento /verify puede escribirlo el operador directamente o dispararse automáticamente mediante un hook justo antes de un reporte de "listo." Ambas rutas apuntan al mismo skill.

Si esta división no es limpia, toda automatización acaba convertida en función y la conciencia de contexto del colaborador queda sin uso, o todo se convierte en slash command y el operador tiene que invocar cada paso manualmente.

3. Skills en rotación real — el efecto acumulado

Un subconjunto de los skills que invoco cada día.

3.1 /start <proyecto> — entrar en un proyecto

Entrar en el proyecto nombrado, cargar automáticamente README.md · CLAUDE.md · HANDOFF.md · PLAN.md, luego reportar el estado actual de git y el handoff de la sesión anterior en una sola vista. Detenerse y esperar la siguiente instrucción del operador.

Sin este skill, cada entrada requiere que el operador dicte "ir a esa carpeta, leer el README, leer el HANDOFF, verificar git status, mostrarme el último mensaje de commit." Todo eso condensado en una sola palabra.

3.2 /session-end — cerrar la sesión

Escribir el log de trabajo, actualizar HANDOFF.md (el handoff de la siguiente sesión que el sistema carga automáticamente), commit, push — todo en un movimiento. Sin tener que deletrear "resume el día de hoy en history.md, escribe lo que necesita la siguiente sesión en HANDOFF, commit, push."

3.3 /verify — el bucle de verificación

Después de cambios de código, ejecuta lint · build · test · revisiones de seguridad · revisión de diff automáticamente. Un reporte de "listo" no puede salir hasta que pase. Se cubre en detalle más adelante en la serie.

3.4 /council — análisis paralelo de cuatro perspectivas

Para decisiones genuinamente ambiguas, ejecuta las perspectivas de arquitecto · escéptico · pragmatista · crítico en paralelo y sintetiza los resultados. Este patrón está adaptado del enfoque de crítica multiperspectiva de Andrej Karpathy para el razonamiento LLM.

3.5 El efecto acumulado

Cada uno de estos no es un gran invento por sí solo. Pero cuando unos 30 nombres de una línea se invocan diariamente, el tiempo que el operador gasta desarrollando procedimientos en lenguaje casi desaparece. La mente del operador solo tiene que enfocarse en "qué necesito decidir ahora mismo"; los nombres se encargan de "cómo desarrollo la decisión."

4. Principios de diseño — lo que sigo al construir un skill

Lo que encontré para el diseño de skills.

4.1 Idempotente

Llamar con los mismos args dos veces debería producir el mismo resultado, o al menos no romper nada. Un skill no idempotente obliga al operador a preguntarse "¿es seguro llamar a esto ahora?" en cada ocasión. Eso es un tributo de atención fresca.

4.2 Falla rápido

Si las precondiciones no se cumplen, el skill se detiene en la primera línea con un mensaje claro. "Este directorio no es un repositorio git. Ejecuta git init e inténtalo de nuevo." Los skills que se ejecutan a medias y dejan el sistema en un estado intermedio son los más peligrosos.

4.3 Salida corta

Cuando el skill termina, la salida debe ser breve: "OK: pushed 3 files", una línea. Los logs detallados solo bajo demanda, detrás de una opción. La salida larga obliga al colaborador a resumirla cada vez y al operador a releerla.

4.4 Declarar efectos secundarios

Si el skill cambia estado externo — escribe archivos, realiza llamadas de red, hace push — ese hecho se declara al principio de la definición del skill: "Este skill hace push a origin." El operador debe saberlo antes de invocarlo.

4.5 Responsabilidad única

Un skill hace una cosa. No añadir "y también instalar dependencias" dentro de /start. Eso es un skill separado. Cuando se rompe la responsabilidad única, el nombre deja de describir la acción.

5. Cuando los skills se acumulan — el efecto de red

El valor de un skill único es el tiempo ahorrado. Pero cuando se acumulan 30 skills, ocurre algo más grande. Los skills empiezan a llamarse entre sí.

Por ejemplo:

• /session-end internamente llama a /verify — los cambios no verificados no se hacen push
• /start refresca automáticamente el índice de memoria
• /council propone invocar /btw (procesamiento de cola de decisiones) después de una decisión

Cuando cada skill puede llamar a otros a través de una interfaz bien definida, la mente del operador opera en una unidad más grande. Una única decisión de "cerrar el trabajo de hoy" se desarrolla internamente en 7 u 8 llamadas a skills. El operador no tiene que ser consciente de esas 7 u 8.

Ese es el valor real de un conjunto acumulado de skills. El tiempo ahorrado es un efecto secundario; la mente que puede operar en una unidad más grande es la esencia.

6. Qué no convertir en skill — trampas

El reverso de los criterios de promoción. Los siguientes pierden dinero como skills.

6.1 Procedimientos que probablemente solo se ejecutarán una vez

"Esta migración se ejecuta una vez, voy a escribir un script." Eso no debería convertirse en un skill. Los procedimientos de una sola vez simplemente se ejecutan una vez y desaparecen. Como skill se convierten en mantenimiento, y seis meses después estás tratando de recordar qué eran.

6.2 Cosas con alta dependencia del contexto

"Revisa este código" no puede ser un skill porque cada invocación necesita contexto diferente. Si tomas el contexto como argumentos, terminas deletreándolo cada vez, y el beneficio desaparece.

6.3 Externalizar la mente misma

"Dime qué debería decidir" no es un skill. Eso externaliza la mente del operador, y entonces el operador deja de ser el dueño de la decisión.

Un skill asiste la mente del operador; no la reemplaza.

6.4 Procedimientos que cambian demasiado a menudo

Un skill, una vez definido, debería mantenerse durante días. Los procedimientos que cambian semanalmente no se solidifican. Si los solidificas, se rompen la semana siguiente.

7. Patrón de evolución — cómo se pulen los skills

El ciclo de vida natural que he observado para un skill.

1. Repetición detectada: el mismo procedimiento se deletrea dos veces o más → candidato
2. Documentación manual: listar los pasos en un README o nota → seguible a mano
3. Convertir en skill: una vez que los pasos son estables, condensar en un slash command o definición de skill
4. Pulido en vuelo: los casos borde encontrados en uso real se corrigen
5. Llamable externamente: limpiar la interfaz para que otros skills puedan llamarlo
6. Promover o degradar: muy usado → agregar un disparador de auto-disparo en la persona (siguiente artículo sobre hooks) / sin uso → degradar a externo o eliminar

Los skills que no pasan por este ciclo no duran. Son fáciles de crear y difíciles de mantener, por lo que la selección natural es necesaria.

Descarga — el skill /verify

El bucle de verificación de siete pasos de la parte 7 como un único archivo de skill slash command. Un ejemplo de condensar un procedimiento repetido en una invocación de una línea — sustituye tus propios comandos de build/test.

shasum -a 256 verify.md
# expected: 8cabf33a2711a0501ee3f65f630bc49868a710cfa973910b7c33e253091dea12

8. Comprimido en un principio

El núcleo del diseño de skills y slash commands se resume en una oración.

"Solo dar un nombre de una línea a los movimientos mentales recurrentes. Deletrear todo lo demás."

Cuando esto se cumple, el conjunto de skills se convierte en un acelerador para la mente del operador. Cuando se rompe — skills hechos demasiado pronto, o demasiado complejos — se convierten en una sobrecarga en la que el operador tiene que pensar cada vez.

El siguiente artículo cubre la otra mitad que se combina con los skills: hooks y automatización, es decir, los procedimientos que el sistema dispara automáticamente sin que el operador tenga que invocarlos.