Tu caja de herramientas: comandos slash y la carpeta .claude/ de la A a la Z

Tu proyecto ha crecido: necesitas un mapa

En ocho capítulos, el proyecto de Lea ha acumulado skills, hooks, subagentes, archivos de ajustes y una memoria de proyecto. Todo funciona — pero si te pidieran dibujar dónde vive cada pieza, ¿sabrías hacerlo? Este capítulo te da el mapa completo. No es orden por placer: saber con precisión dónde vive cada mecanismo es saber dónde buscar cuando algo no funciona, y dónde añadir el próximo ladrillo sin romper los demás.

Hay una segunda razón, más estratégica. Si Lea contrata algún día a una asistente, o si confía su sitio a un freelance, todo lo que está bien ordenado en .claude/ y versionado en Git se transmite: la persona clona el repositorio y hereda instantáneamente las convenciones, las skills y las barreras. La carpeta .claude/ no es un detalle técnico — es el capital operativo de la marca, en forma de archivos.

La anatomía completa de la carpeta .claude/

Esta es la vista de conjunto: dos archivos de memoria en la raíz del proyecto, y una carpeta .claude/ que sirve de centro de control. La lógica transversal ya la conoces de los capítulos 2 y 8: cada pieza existe en versión compartida (commiteada en Git, para el equipo) y en versión local (gitignorada, solo para ti).

flowchart TD
  P["Raíz del proyecto"] --> M1["CLAUDE.md: instrucciones de equipo, commiteado"]
  P --> M2["CLAUDE.local.md: overrides personales, gitignorado"]
  P --> R[".claude/: el centro de control"]
  R --> S1["settings.json: permisos + config, commiteado"]
  R --> S2["settings.local.json: ajustes personales, gitignorado"]
  R --> CMD["commands/: comandos slash custom"]
  CMD --> C1["10x.md → /project:10x"]
  R --> RU["rules/: instrucciones modulares"]
  RU --> R1["code-style.md, api-conventions.md"]
  R --> SK["skills/: workflows auto-invocados"]
  SK --> K1["post/SKILL.md"]
  R --> AG["agents/: personas de subagentes"]
  AG --> A1["code-reviewer.md, security-auditor.md"]

• CLAUDE.md (raíz) — las instrucciones del proyecto, commiteadas: todo el mundo las hereda (capítulo 8).
• CLAUDE.local.md (raíz) — tus overrides personales, gitignorados: tus atajos, tus preferencias, tus rutas locales.
• .claude/settings.json — permisos y configuración compartidos con el equipo (capítulo 2).
• .claude/settings.local.json — tus permisos locales, gitignorados.
• .claude/commands/ — tus comandos slash personalizados: un archivo nombre.md se convierte en /project:nombre.
• .claude/rules/ — archivos de instrucciones modulares (estilo de código, convenciones de API…) referenciados desde CLAUDE.md.
• .claude/skills/ — los workflows auto-invocados con su SKILL.md (capítulo 3).
• .claude/agents/ — las personas de subagentes especializados (capítulo 6).

El dúo CLAUDE.md / CLAUDE.local.md merece una precisión, porque resuelve un problema real de equipo. El primero lleva la ley común: convenciones, estructura, barreras. El segundo lleva tus particularidades: «mis capturas de pantalla están en ~/Escritorio/capturas», «respóndeme en español», «uso tal alias». Sin esta separación, cada miembro del equipo contaminaría la memoria común con sus detalles personales — o peor, pisaría los de los demás en cada commit.

Las rules: dividir la ley en módulos

En el capítulo 8 te dijimos que mantuvieras CLAUDE.md corto. Pero ¿qué hacer cuando las convenciones se acumulan — estilo de escritura, convenciones de nombrado de archivos, reglas de API? La respuesta: la carpeta .claude/rules/. Cada tema se convierte en un archivo dedicado (code-style.md, api-conventions.md, testing.md), y CLAUDE.md se limita a referenciarlos. Claude carga la regla pertinente cuando el tema lo requiere.

Para Lea, eso da por ejemplo un rules/redaccion.md (las reglas de escritura detalladas que desbordaban de brand-voice.md) y un rules/publicacion.md (franjas, formatos de imágenes por plataforma, política de hashtags). El beneficio es el mismo que para cualquier código: módulos cortos y enfocados son más fáciles de mantener que un archivo monolítico — y puedes añadir más sin inflar el contexto de cada sesión.

SKILL.md: ¿contenido de referencia o contenido de tarea?

Ahora que has escrito varias skills, tomemos altura. Un archivo SKILL.md puede contener cualquier instrucción, pero en la práctica existen dos grandes tipos — y distinguirlos te ayudará a escribir skills más nítidas. El contenido de referencia añade conocimientos que Claude aplica a tu trabajo en curso: contexto de negocio, historia de la empresa, matices de tu base de datos, guías de estilo. El contenido de tarea da instrucciones paso a paso para una acción precisa: generar código, crear slides, redactar un documento.

Una skill de referencia se parece a una ficha que Claude mantiene a la vista mientras trabaja:

---
name: contexto-marca
description: Conocimientos sobre la marca de Lea (posicionamiento, gamas, clientela). Usar para toda redacción o decisión de producto.
---

# La marca
- Cosméticos bio, fabricación francesa, certificada Ecocert.
- Posicionamiento: accesible y pedagógica, nunca culpabilizadora.

# Las gamas
- Hidratación (best-seller: crema de karité), Solar (nuevo), Esenciales.

# La clientela
- Mujeres de 25-45 años, sensibles a la composición, compran primero en línea.

# Matices importantes
- Nunca prometer un resultado dermatológico (restricción legal).
- «Natural» está prohibido: demasiado vago, preferir «certificado bio».

Una skill de tarea, en cambio, es un procedimiento: etapas ordenadas, criterios de salida, formatos impuestos. Tu /post del capítulo 3 es una. Aquí va otra, más corta, para ver bien el contraste:

---
name: newsletter
description: Redacta la newsletter semanal en el formato de la casa. Usar cuando el usuario pide la newsletter.
---

# Etapas
1. Lee el journal de los posts de la semana (logs/posts.md).
2. Selecciona los 3 posts con más engagement.
3. Redacta: una intro de 2 frases, los 3 posts resumidos, un CTA hacia la tienda.
4. Aplica brand-voice.md.
5. Escribe el resultado en newsletters/AAAA-MM-DD.md y pide validación.

# Criterios de salida
- Menos de 300 palabras. Un solo CTA. Ninguna palabra prohibida.

Muchas buenas skills mezclan los dos — un procedimiento que se apoya en conocimientos — pero ten siempre claro cuál domina. Si no logras escribir las «Etapas», probablemente es una skill de referencia que se ignora: separa el conocimiento (referencia) de la acción (tarea), y haz que una referencie a la otra. Es exactamente lo que hicimos en el capítulo 4 con brand-voice.md.

Los «comandos secretos»: la verdad detrás del mito

Quizá te hayas cruzado con esos visuales virales: «los códigos secretos de Claude — /godmode, /10x, /devil…». Aclaremos las cosas: no son comandos nativos. Escribe /devil en una instalación virgen y no pasará nada. Pero la idea detrás del mito es excelente, y ahora tienes todo el bagaje para entenderla: son comandos slash personalizados que cualquiera puede crear en .claude/commands/ — prompts reutilizables a los que se les da un nombre.

El mecanismo es de una simplicidad desarmante: un archivo Markdown .claude/commands/10x.md se convierte en el comando /project:10x. El contenido del archivo es el prompt enviado a Claude, y la palabra clave $ARGUMENTS se reemplaza por lo que escribas después del comando. Sin YAML obligatorio, sin estructura impuesta: es el más ligero de los mecanismos de extensión.

# Crear la carpeta de comandos del proyecto
mkdir -p .claude/commands

# Cada archivo se convierte en un comando:
#   .claude/commands/10x.md      -->  /project:10x
#   .claude/commands/devil.md    -->  /project:devil

# Los comandos personales viven en tu carpeta de usuario:
#   ~/.claude/commands/brief.md  -->  /user:brief

Construye tu biblioteca: los 9 comandos de Lea

Esta es la biblioteca que Lea se ha construido, archivo por archivo. No los copies a ciegas: lee cada prompt, entiende lo que restringe, y adáptalo a tu práctica. /10x — su favorito para potenciar los ganchos de Twitter antes de publicar:

---
description: Reescribe un texto para hacerlo 10x más contundente
---

Reescribe este texto para hacerlo 10x más contundente:
- corta cada palabra que no aporte sentido
- empieza por la idea más fuerte, no por el contexto
- una idea por frase, voz activa
- mantén mi tono (brand-voice.md), no inventes ningún hecho
- propón 3 variantes, de la más sobria a la más audaz

Texto: $ARGUMENTS

/brief — la respuesta más corta posible, cero relleno. Lea lo usa cuando quiere un dato, no una exposición:

Responde a la siguiente pregunta de la forma más corta posible.
Sin introducción, sin advertencias, sin resumen final.
Si la respuesta cabe en una palabra o una cifra, da una palabra o una cifra.

Pregunta: $ARGUMENTS

/explainlikeim5 — la explicación ultra simple. Valioso cuando un proveedor le envía jerga técnica:

Explica el siguiente concepto como a un niño de 5 años:
- una analogía de la vida cotidiana
- frases cortas, nada de jerga
- termina con «en una frase: ...»
- luego añade el nivel superior: la misma explicación para un adulto curioso, en 3 frases

Concepto: $ARGUMENTS

/devil — el abogado del diablo en versión seria: un «steelman», es decir, la mejor defensa posible de la posición opuesta, no una caricatura. Lea lo lanza sistemáticamente antes de publicar un post comprometido sobre ecología — mejor descubrir la objeción en su terminal que en los comentarios:

---
description: Steelman de la posición opuesta, para probar un argumento antes de publicar
---

Juega al abogado del diablo sobre la siguiente posición.
Construye el STEELMAN de la posición opuesta: su versión más fuerte,
la más honesta, defendida por alguien inteligente y de buena fe.
- 3 contraargumentos sólidos, ordenados del más fuerte al más débil
- para cada uno: cómo podría responderle honestamente
- termina con: lo que debería matizar en mi posición inicial

Mi posición: $ARGUMENTS

/critique — encuentra los fallos y propone mejoras concretas, sin complacencia:

Critica el siguiente trabajo sin ninguna complacencia:
- 5 fallos precisos, ordenados por gravedad (bloqueante / importante / detalle)
- para cada fallo: una corrección concreta, no un consejo vago
- lo que está bien y hay que conservar (2 puntos máximo)
- veredicto final: publicable tal cual, sí o no, y por qué

Trabajo a criticar: $ARGUMENTS

/pitch — el pitch de 30 segundos, cliente o inversor. Lea lo usa para preparar sus reuniones con tiendas y sus solicitudes de financiación:

Transforma lo siguiente en un pitch de 30 segundos (75 palabras máximo):
- estructura: problema vivido, solución, prueba, llamada a la acción
- ningún superlativo vacío (líder, único, revolucionario)
- una frase gancho que cree curiosidad desde el primer segundo
- da 2 versiones: una para un cliente, una para un inversor

Tema: $ARGUMENTS

/compare — el análisis lado a lado en tabla, para decidir rápido entre dos opciones (dos herramientas de programación de posts, dos proveedores de embalajes…):

Compara las siguientes opciones lado a lado:
- tabla: criterios en filas, opciones en columnas
- criterios impuestos: coste, tiempo de puesta en marcha, riesgos, reversibilidad
- añade los criterios específicos del tema
- bajo la tabla: tu recomendación en 2 frases, con la condición
  que la haría inclinarse hacia la otra opción

Opciones: $ARGUMENTS

/scout — el explorador: riesgos y puntos ciegos de un plan, antes de comprometerse:

---
description: Detecta los riesgos y puntos ciegos de un plan antes de comprometerse
---

Analiza este plan como un explorador prudente:
- 5 riesgos concretos, con para cada uno: probabilidad (baja/media/alta),
  impacto, y señal de alerta temprana a vigilar
- 3 puntos ciegos: las preguntas que no me estoy haciendo y debería
- el escenario de fracaso más probable, contado en 3 frases
- las 2 protecciones más baratas a implementar desde ahora

Plan: $ARGUMENTS

/teacher — el modo mentor: Claude no ejecuta, enseña, pregunta y debate. Lea lo usa para ganar competencia en lugar de solo delegar:

Pasa a modo mentor sobre el siguiente tema.
NO hagas el trabajo por mí:
- explica el concepto clave partiendo de lo que probablemente ya sé
- hazme una pregunta a la vez para verificar mi comprensión
- cuando me equivoque, no des la respuesta: guíame hacia ella
- termina la sesión con 3 puntos a retener y un ejercicio para hacer sola

Tema: $ARGUMENTS

¿Comando slash o skill: cómo elegir?

La pregunta a hacerse: «¿es un golpe de sello o un proceso?» Un golpe de sello — una transformación aplicada a un texto que proporcionas — hace un comando slash perfecto. Un proceso — varias etapas, archivos que leer y escribir, validaciones — merece una skill. Y los dos se combinan: Lea lanza /project:devil sobre un borrador producido por /post, luego /project:10x sobre el gancho elegido. La caja de herramientas no reemplaza a la fábrica; la equipa.

La rutina de Lea, versión equipada

Concretamente, así es ahora una publicación comprometida en casa de Lea: /post genera el borrador en su voz; /project:devil prueba el argumento y revela la objeción más fuerte; ella matiza una frase; /project:10x propone tres ganchos más contundentes; ella elige uno; el quality gate lo verifica todo; publicación. Cuatro comandos, cinco minutos, y un post más sólido que lo que escribía en una hora — porque cada eslabón codifica una experiencia que ya no tiene que movilizar de cabeza.