Output styles: cómo Claude comunica

Módulo 4 · Configuración y personalización · Lección 5 de 5

Al terminar esta lección sabrás configurar un output style que se ajuste a cómo trabaja tu equipo y reconocerás cuándo conviene escribir uno propio.

Cambia cómo Claude te habla.

Dos palancas distintas

CLAUDE.md es lo que Claude sabe. Los output styles son cómo Claude comunica.

Ambos dan forma al comportamiento de Claude en una sesión, pero operan sobre cosas distintas. Tener clara esta distinción te ayuda a aconsejar a los clientes sobre cuál usar.

CLAUDE.md da a Claude memoria del proyecto: arquitectura, convenciones, comandos de compilación y estándares del equipo. Se inyecta una vez en el system prompt, al inicio de la sesión, y le indica lo que necesita saber sobre el código base. Los output styles modifican el system prompt para cambiar el tono y el formato de la comunicación, no el conocimiento. Afectan a cómo presenta Claude su trabajo: cuánta explicación añade, si ejecuta de forma proactiva o espera instrucciones explícitas, si deja marcadores TODO para que el desarrollador los complete. Un equipo puede tener ambos: un CLAUDE.md que codifica el contexto del proyecto y un output style que se ajusta a cómo quiere trabajar ese equipo.

flowchart LR
    A["CLAUDE.md"] --> B["Lo que Claude SABE: arquitectura, convenciones, comandos"]
    C["Output style"] --> D["Cómo COMUNICA Claude: tono, formato, proactividad"]
    B --> E["System prompt al inicio de la sesión"]
    D --> E

Restricción de inicio de sesión

Los output styles modifican el system prompt al inicio de la sesión. Cambiar el estilo a mitad de sesión no tiene efecto. Los cambios se aplican después de /clear o en una sesión nueva.

Estilos integrados

Cuatro opciones. Default para la mayoría. Cada uno de los demás encaja con una fase concreta de la activación.

Configúralo con /config dentro de la sesión (se guarda en settings.local.json), o establece "outputStyle": "Explanatory" directamente en cualquier archivo de configuración en el ámbito adecuado.

Estilo	Comportamiento
Explanatory	Añade secciones «Insights» que explican las decisiones de implementación y los patrones del código base. Es la opción adecuada para una fase de adopción, cuando los ingenieros necesitan entender lo que hace Claude y no solo aceptar el resultado.
Proactive	Ejecuta de inmediato y hace suposiciones razonables en lugar de preguntar. Es más rápido y autónomo que Default, pero sigue mostrando avisos de permiso para las acciones de consecuencias.
Learning	Modo colaborativo. Explica el razonamiento y coloca marcadores TODO(human) en los puntos de decisión clave, para que los desarrolladores completen las piezas críticas en lugar de aceptarlo todo en bloque.

El cuarto: Default

Modo de ingeniería estándar: eficiente, preciso, sin comentarios adicionales. Déjalo así salvo que haya un motivo concreto para cambiarlo. La mayoría de los equipos de producción no necesitan otro estilo una vez superada la fase inicial de adopción.

Estilos personalizados

Cuando ninguno de los integrados encaja, escribe el tuyo.

Un estilo de salida personalizado es un archivo Markdown con frontmatter YAML, guardado en .claude/output-styles/ a nivel de proyecto, de usuario o gestionado.

keep-coding-instructions: true

Conserva las instrucciones de ingeniería integradas de Claude (cómo acotar los cambios, verificar el trabajo y escribir comentarios) y añade tu formato de comunicación encima. Úsalo para estilos como «siempre empieza con un diagrama» o «estructura toda la salida como artefactos listos para el cliente, con encabezados, recomendaciones y próximos pasos».

keep-coding-instructions: false (valor por defecto)

Se eliminan las instrucciones de ingeniería integradas de Claude. Úsalo cuando Claude no esté haciendo ingeniería de software en absoluto: un asistente de escritura, un analista de datos o un formateador de requisitos. El valor por defecto es false, así que si omites el flag se elimina por completo el contexto de ingeniería.

flowchart TD
    A["Output style personalizado (.claude/output-styles/)"] --> B{"keep-coding-instructions"}
    B -- "true" --> C["Se mantienen las instrucciones de ingeniería integradas y se añade tu formato encima"]
    B -- "false (por defecto)" --> D["Se eliminan las instrucciones de ingeniería: solo tu estilo"]

Tres patrones que aparecen en engagements de GSI: un estilo de documentos del engagement que estructura toda la salida como artefactos listos para el cliente, con encabezados estructurados y próximos pasos; un estilo de revisión de seguridad que formatea cada hallazgo con severidad, ruta del archivo, número de línea y corrección recomendada; y un modo de onboarding que añade comentarios explicativos para los desarrolladores junior que se incorporan a mitad del engagement. Los tres usan keep-coding-instructions: true.

Comprueba tu comprensión

Simulación: Activación en Hartfield Engineering

Tres decisiones sobre el estilo de salida durante una activación real de Claude Code de 3 días. Elegir bien el estilo en cada fase cambia si el equipo adopta Claude o simplemente lo tolera. ¿Qué tan bien lees la situación?

Decisión 1 de 3 · Día 1

Los ingenieros de Hartfield dominan el código, pero interrumpen constantemente para preguntar por qué Claude tomó decisiones de arquitectura concretas. Las preguntas están ralentizando la sesión. ¿Qué output style configuras para el día 1?

• A. Explanatory: Claude añade secciones «Insights» que explican cada decisión automáticamente.
• B. Learning: modo colaborativo con razonamiento y marcadores TODO en los puntos de decisión.
• C. Default: modo de ingeniería estándar, sin comentarios adicionales.

Ver respuesta

• A · 2 puntos (mejor opción). +2 · Decisión acertada. El estilo Explanatory añade secciones «Insights» automáticamente y muestra el razonamiento detrás de cada decisión sin que los ingenieros tengan que pedirlo. Así se atiende la brecha de confianza desde el origen.
• B · 1 punto (parcial). +1 · Dirección correcta. El modo Learning sí añade explicaciones, pero los marcadores TODO generan fricción en una activación del primer día centrada en el impulso. Explanatory encaja mejor.
• C · 0 puntos. +0 · Lectura equivocada. Default es eficiente, pero no hace nada por los ingenieros que preguntan «por qué». Las interrupciones continuarán y el ritmo de la sesión seguirá lento. El problema es una brecha de comunicación, no de capacidad.

Decisión 2 de 3 · Día tres

En dos días el equipo ha ganado confianza real con Claude. Te diriges a la entrega final antes del traspaso. Los comentarios que ayudaron el día 1 ya son un lastre. ¿Cómo reconfiguras para el impulso de productividad del día 3?

• A. Cambiar a Default: modo de ingeniería limpio, sin comentarios. Deja que Claude trabaje a plena velocidad con un equipo que ya confía en él.
• B. Cambiar a Proactive: ejecución más autónoma que asume el contexto en lugar de preguntar.
• C. Mantener Explanatory: conservar los comentarios que el equipo ha estado usando.

Ver respuesta

• A · 2 puntos (mejor opción). +2 · Correcta. Default es la opción limpia para un equipo seguro de sí mismo: sin sobrecarga de comentarios y con precisión de ingeniería completa. Este es exactamente el momento en que Explanatory deja de ayudar y empieza a generar ruido.
• B · 1 punto (parcial). +1 · Razonable, pero se excede. Proactive hace a Claude más autónomo, pero en el día de la entrega eso significa más acciones de consecuencias sin avisos. Default es el movimiento más seguro y limpio para un equipo que ya conoce Claude.
• C · 0 puntos. +0 · Lectura errónea de la fase. Mantener Explanatory el día 3 frena activamente a un equipo que está listo para despegar. El output style es un control que se ajusta, no algo que se configura una vez y se olvida. Reconfigurarlo según la fase forma parte del trabajo del consultor.

Decisión 3 de 3 · Cierre del engagement

El líder técnico de Hartfield pide una forma de que Claude produzca siempre la salida en su formato de documentación interna: encabezados estructurados, recomendaciones y viñetas de próximos pasos. Quieren que esto persista para todo el equipo. ¿Cuál es el mecanismo correcto?

• A. Output style personalizado con keep-coding-instructions: true: añadir un archivo de estilo Markdown a .claude/output-styles/ en el repositorio del proyecto.
• B. Añadir instrucciones de formato a CLAUDE.md: incluir la especificación de formato en el archivo de memoria del proyecto.
• C. Pedir al equipo que incluya el formato en cada prompt: documentar la especificación y formar al equipo para usarla en cada sesión.

Ver respuesta

• A · 2 puntos (mejor opción). +2 · El mejor mecanismo. Un output style personalizado con keep-coding-instructions: true persiste entre sesiones, se aplica a todo el equipo a través del repositorio del proyecto y mantiene intactas todas las instrucciones de ingeniería. Es la herramienta adecuada.
• B · 1 punto (parcial). +1 · Funciona, pero de forma imprecisa. CLAUDE.md puede incluir indicaciones de formato, pero está diseñado para la memoria del proyecto, no para el formato de comunicación. Es menos fiable para imponer una estructura de salida de forma consistente. Los output styles personalizados son el mecanismo creado para ese fin.
• C · 0 puntos. +0 · No escala. Pedir al equipo que incluya instrucciones de formato en cada prompt es una experiencia de uso muy deficiente, no sobrevivirá a la rotación del equipo y no durará más que el engagement. Es la capa equivocada por completo.

Ver cierre de la simulación

• 6 puntos · Configuración precisa. Relacionaste el output style con la fase de activación y elegiste el mecanismo correcto para un formato persistente. Esa precisión se traduce en un engagement más fluido y en un traspaso más útil.
• 3–5 puntos · Dirección correcta. Leíste bien las fases, pero se te escapó al menos un detalle del mecanismo. Repasa cuándo usar output styles personalizados frente a CLAUDE.md y cuándo la fase exige cambiar de modo.
• 0–2 puntos · Revisa la lógica de las fases. La selección del output style afecta a si los equipos adoptan Claude o solo lo toleran. Cada decisión errónea aquí tiene una consecuencia real en la calidad del engagement y en la confianza del cliente.

Artefacto del curso

Contribución de la lección 5: CLAUDE.md + catálogo de slash commands

En las cinco lecciones has construido la pila de configuración completa para un engagement de Claude Code: un mapa de decisión de ámbitos (4.1), un CLAUDE.md a nivel de proyecto (4.2), un esqueleto de settings.json con reglas de permisos (4.3) y un comando slash con frontmatter y $ARGUMENTS (4.4). Esta lección añade la pieza final: la selección del output style para el contexto de la activación.

1. Decide el output style adecuado para tu engagement de ejemplo. Si es una activación en fase de adopción con ingenieros nuevos en Claude Code, usa Explanatory. Si es un equipo orientado a la productividad que ya confía en Claude, déjalo en Default.
2. Si el cliente necesita un formato personalizado (documentos listos para el cliente, hallazgos de seguridad o modo onboarding), escribe un archivo de estilo sencillo y añádelo a .claude/output-styles/. Incluye keep-coding-instructions: true salvo que el caso de uso sea completamente no técnico.
3. Revisa el conjunto completo: mapa de decisión de ámbitos, CLAUDE.md, settings.json con reglas de permisos, comando slash y output style. Es el entregable de configuración que entregas al cliente al cierre del engagement.

Con el CLAUDE.md redactado y un comando slash en el catálogo, este cliente tiene todo lo necesario para incorporar a sus desarrolladores de forma consistente y replicar la configuración en cualquier repositorio que traiga al engagement.

Práctica

Pruébalo

Escribe un CLAUDE.md y un comando slash personalizado para un repositorio de ejemplo. El CLAUDE.md debe incluir el contexto del proyecto, los estándares de código y al menos una instrucción de flujo de trabajo. El comando slash debe resolver algo que de otro modo escribirías más de dos veces. Dale una descripción, acota sus herramientas permitidas y colócalo en .claude/commands/.

Ideas clave

Ya puedes configurar un entorno de cliente de principio a fin. Ahora configúralo bien.

La configuración es donde se decide la calidad del engagement, no durante el despliegue. Un CLAUDE.md bien acotado, un settings.json claro, unos cuantos comandos slash reutilizables y el output style adecuado para el equipo son la diferencia entre una activación que se sostiene y una que necesita acompañamiento constante.

• CLAUDE.md define lo que Claude sabe del proyecto; el output style define cómo se comunica.
• Los output styles se aplican al inicio de la sesión: los cambios requieren /clear o una sesión nueva.
• Explanatory ayuda durante la adopción, Learning añade marcadores TODO(human) y Default es el valor adecuado para la mayoría de los equipos de producción.
• Un estilo personalizado se guarda en .claude/output-styles/; con keep-coding-instructions: true conservas las instrucciones de ingeniería de Claude y añades tu formato.
• Los estilos personalizados permiten fijar formatos de salida (documentación para el cliente, hallazgos de seguridad, modo onboarding) como artefactos de entrega.

El siguiente curso es Extensibilidad: el curso 5 explica cómo ampliar Claude Code más allá de sus valores por defecto con servidores MCP, herramientas personalizadas y las integraciones que convierten un entorno configurado en una plataforma totalmente capaz.

Siguiente: Servidores MCP: ticketing, logs de errores y sistemas internos