En Claude Code, hooks, slash commands y skills se entienden mejor preguntando quién dispara la acción. Usa un slash command cuando la persona debe decidir explícitamente el momento. Usa una skill cuando Claude necesita cargar un método reusable, referencias, ejemplos, scripts o una checklist. Usa un hook cuando un evento del ciclo de vida debe ejecutar algo siempre, sin depender de que el modelo lo recuerde.
Según la documentación de Claude Code revisada el 1 de junio de 2026, hay un matiz importante: los custom commands se han integrado en skills, pero los archivos existentes en .claude/commands/ siguen funcionando. La pregunta práctica ya no es “qué carpeta antigua uso”, sino “quién debe iniciar esto, qué tan determinista debe ser y qué debe pasar si Claude lo olvida”.
Tabla rápida de elección
| Si el workflow necesita... | Empieza con | Dónde suele vivir | No lo uses para |
|---|---|---|---|
| timing explícito, argumentos e intención humana | Slash command o user-invoked skill | comandos / integrados, /skill-name, legacy .claude/commands/*.md | guardrails que deben ejecutarse aunque nadie escriba el comando |
| método reusable, referencias, checklist, scripts o plantillas | Skill | .claude/skills/ | un prompt de una sola vez o enforcement duro |
| reacción automática a eventos, validación, logs o bloqueo estrecho | Hook | hooks en settings que llaman command, HTTP, prompt o agent handler | juicio amplio, revisión subjetiva o memoria de largo plazo |
La regla corta es esta: slash command controla timing, skill controla method y hook controla certainty. Un command es un botón visible para la persona. Una skill es un paquete de forma de trabajo. Un hook es una regla atada a un evento.
El error común es llamar automatización a todo. Sí, las tres superficies reducen repetición, pero fallan de manera distinta. Un command puede olvidarse. Una skill puede cargarse cuando no corresponde o no cargarse cuando sí corresponde. Un hook puede dispararse demasiado, agregar latencia o bloquear trabajo válido. Diseña primero el modo de fallo y luego el archivo.
Slash Commands son para timing explícito
Un slash command encaja cuando lo importante es que una persona elija el momento. Escribes / al inicio del mensaje, eliges el comando y, si hace falta, pasas argumentos. Sirve para control de sesión, iniciar una review, preparar una release checklist, resumir estado o pedir un plan antes de ejecutar.
La razón fuerte para mantener un workflow como command es el control de efectos secundarios. Si la acción puede desplegar, borrar, publicar, gastar dinero, tocar producción, reescribir muchos archivos o llamar un servicio externo, el arranque humano forma parte del modelo de seguridad. El método puede estar en una skill, pero el inicio debe seguir visible.
Que los custom commands se hayan integrado en skills no significa que la superficie / haya dejado de importar. Significa que muchas personalizaciones nuevas se empaquetan mejor como skills, con metadata, archivos de apoyo, ejemplos, scripts y controles de herramientas. Los viejos .claude/commands/*.md pueden quedarse si hacen una tarea pequeña y estable.
El patrón limpio es: comandos integrados para controlar la sesión, user-invoked skills para workflows reusables, y legacy command files solo cuando ya son simples y no necesitan el contrato más rico de una skill. Si no puedes explicar por qué el momento debe elegirlo una persona, probablemente no necesitas otro command.
Skills llevan método reusable
Una skill sirve cuando Claude necesita una forma repetible de trabajar. La unidad útil no es “un prompt que me gusta”, sino un método con instrucciones, referencias, ejemplos, scripts, plantillas y límites. SKILL.md es la entrada, y los archivos cercanos cargan el contexto sin inflar siempre las instrucciones del proyecto.
Conviene crear una skill para review de PR con la misma evidencia, auditorías de migración, documentación de API con formato fijo, localización con source truth pack, QA de navegador o cualquier proceso donde explicar el método cada vez sea tedioso o arriesgado. Si es una instrucción corta y única, todavía no merece ser skill.
También importa cómo se invoca. Algunas skills pueden estar disponibles para que Claude las cargue cuando el contexto encaja. Otras deben ser directas. Si una skill toca producción, cuesta dinero, contacta un sistema externo o modifica muchos archivos, hazla user-invoked. Así el método es reusable, pero el inicio sigue siendo humano.
Si ya decidiste instalar o diseñar skills, el siguiente paso puede ser /es/posts/claude-code-best-skills. Pero si lo que falta es acceso externo, no lo fuerces dentro de una skill. Una skill enseña cómo trabajar con GitHub, un navegador, una base de datos o deploy; no concede acceso por sí sola. Para eso mira MCP o permisos de herramientas.
Hooks aplican eventos e invariantes
Un hook encaja cuando el evento debe disparar la acción siempre. Es automatización de lifecycle: antes o después de tool use, al iniciar sesión, en notificaciones, alrededor de compaction u otros eventos configurados. El handler puede ser command, HTTP request, prompt o agent, según el tipo de hook y la documentación vigente.
Los buenos hooks son estrechos: ejecutar formatter después de editar, registrar un log, bloquear un patrón de shell peligroso, validar una ruta protegida, inyectar un contexto pequeño al inicio o enviar una notificación. La regla debe poder explicarse en un mensaje corto de éxito o fallo.
No pongas juicio amplio en hooks. “¿Esta review es suficientemente buena?” pertenece a una skill, subagent o workflow explícito. “¿Este comando intenta borrar un directorio protegido?” sí puede ser hook. Cuanto más automática es la superficie, más estrecho debe ser el criterio.
Empieza observando y registrando antes de bloquear. Una mala skill consume contexto o guía mal la tarea. Un mal hook se mete en todas las sesiones, añade ruido y puede impedir trabajo legítimo. El enforcement llega después de que la señal sea estable.
Combina capas solo si cada una tiene trabajo propio
Las configuraciones fuertes pueden combinar command, skill y hook, pero no porque más capas sea mejor. La composición sirve cuando cada capa elimina una ambigüedad distinta.
| Workflow | El command posee | La skill posee | El hook posee |
|---|---|---|---|
| release checklist | la persona inicia /release-checklist | pasos, evidencia, rollback y formato | bloqueo estrecho para branch o environment incorrecto |
| code review | persona o Claude inicia la revisión | método, severidad y reporte | formatter o log capture después de tool use |
| deploy prep | la persona inicia /deploy-plan | checklist y orden de verificación | validación determinista de branch, env o approval |
La mala versión es vaga: command repite la skill, la skill intenta hacer enforcement y el hook pide juicio sutil. La buena versión se explica en una frase: el command elige el momento, la skill enseña el método, el hook aplica un invariant. Si no puedes decir el trabajo de cada capa, elimina una.
Stop rules antes de añadir otra extensión
No pongas juicio matizado en hooks. Un hook puede validar rutas, patrones de comando o payloads de evento. La calidad de una review, una decisión de arquitectura o una evaluación de producto pertenecen a una skill o a una revisión explícita.
No auto-dispares skills destructivas. Publish, deploy, delete, billing, production changes y rewrites grandes deben mantener un paso humano. El método puede estar empaquetado, pero el inicio no debe ser invisible.
No conviertas prompts de una sola vez en skills. Una skill se justifica cuando el workflow se repite y gana con referencias, ejemplos, scripts o plantillas.
No uses una lista de commands como estrategia. /help, /skills, /hooks y /context son útiles, pero el diseño se decide por la capa que falta: timing, method, enforcement, access o runtime ownership. Si falta acceso externo, mira /es/posts/claude-code-best-mcp-servers. Si falta ejecución recurrente, mira /es/posts/routines-in-claude-code.
No uses hooks como memoria. Una regla que debe verse antes de trabajar pertenece a project instructions o memory surface. Un hook procesa eventos; no debe ser un documento de políticas oculto.
Checklist de diseño
Antes de construir, responde en orden. ¿Quién dispara el trabajo: humano, Claude o runtime event? ¿Es una acción única o un método reusable? ¿Debe correr automáticamente o bajo demanda? ¿La regla se puede comprobar de forma determinista? ¿Puede causar efectos secundarios, costes o cambios en producción? ¿Falta acceso externo? ¿Un compañero entendería por qué existe esta capa?
Si la respuesta apunta a explicit timing, empieza con slash command o user-invoked skill. Si apunta a method, escribe una skill. Si apunta a deterministic event handling, configura un hook. Si apunta a external access, usa MCP o permisos de herramientas. Si apunta a unattended runtime, decide primero dónde vivirá el proceso.
Una configuración mantenible se explica así: “este command inicia el workflow, esta skill contiene el método y este hook protege un invariant”. Si la explicación se alarga, probablemente no añadiste seguridad; añadiste complejidad.
FAQ
¿Slash commands y skills son ahora lo mismo?
No exactamente. Los custom commands se han integrado en skills, y una skill puede invocarse como /skill-name. Pero slash command sigue siendo la superficie visible de invocación. Command es timing; skill es packaging.
¿Debo migrar todos los .claude/commands a skills?
No. Migra cuando el workflow necesita archivos de apoyo, metadata, dynamic context, tool controls o mejor discoverability. Un command pequeño y estable puede quedarse.
¿Hooks son más confiables que skills?
Son más deterministas, no mejores para todo. Un hook se dispara en su evento configurado, por eso sirve para logs, formatters, notificaciones y guards estrechos. Una skill es mejor para método, contexto, ejemplos y checklist.
¿Qué inspecciono antes de añadir otra superficie?
Mira /help o la referencia de comandos, /skills, /hooks y /context. Si después no puedes nombrar la capa que falta, no añadas otra extensión todavía.
¿Dónde van las reglas de proyecto?
Las reglas amplias y siempre visibles van en CLAUDE.md o memory surface. Los procedimientos repetibles van en skills. Las restricciones de evento van en hooks. No escondas toda la política del repo dentro de un hook.
Resumen corto
Elige por quién dispara la acción. Slash commands para timing humano explícito. Skills para método reusable. Hooks para lifecycle events deterministas. Combínalos solo si cada capa tiene un trabajo distinto. Si el problema real es acceso externo o ejecución recurrente, resuélvelo en la capa correcta antes de crear más archivos .claude.