Claude Code output styles: cambia cómo te responde

Le pides a Claude Code que renombre una función. Lo hace bien. Y después te escribe cuatro párrafos: lo que va a hacer, lo que ha hecho, lo que ha comprobado y un resumen de todo lo anterior.

Al día siguiente te pasa lo contrario. Estás aprendiendo un framework nuevo, le pides una feature y te devuelve 200 líneas sin explicar ni una decisión. Funciona, pero no has aprendido nada.

Las dos veces acabas añadiendo al prompt "sé breve" o "explícame por qué". Y en el siguiente mensaje se le olvida. Para eso existen los Claude Code output styles: para que no tengas que repetirlo.

En corto: un output style es un conjunto de instrucciones que fija el rol, el tono y el formato de todas las respuestas de una sesión de Claude Code. Trae cuatro de serie además del Default (Proactive, Concise, Explanatory y Learning) y se cambian con /output-style. No sustituye a CLAUDE.md: CLAUDE.md dice qué debe saber Claude; el output style, cómo debe responderte.

¿Qué son los output styles de Claude Code?

Un output style es un conjunto de instrucciones que Claude Code envía con cada petición y que cambia cómo te responde Claude durante toda la sesión: su rol, su tono y el formato de sus respuestas.

La documentación oficial (consultada en octubre de 2026) añade un matiz que conviene leer dos veces: es una instrucción que Claude sigue, no una garantía. Si algo tiene que pasar siempre, como formatear después de cada edición, lo que buscas es un hook.

Un estilo orienta. No obliga. Esa diferencia marca todo lo demás.

Los output styles que trae Claude Code de serie

De los Claude Code output styles, el que viene activo es Default, que en realidad es no tener estilo: Claude trabaja con su system prompt estándar de ingeniería de software. Los otros cuatro mantienen esas instrucciones y añaden las suyas.

Estilo	Qué cambia	Cuándo usarlo
Proactive	Empieza a implementar en cuanto mandas la tarea y asume las decisiones rutinarias en vez de preguntar	Quieres que avance y prefieres corregir sobre la marcha
Concise	La primera frase dice qué ha pasado; sin introducción, sin narrar pasos, sin resumen final	Las respuestas por defecto te parecen largas
Explanatory	Añade bloques Insight en la conversación (no como comentarios en tus archivos) con 2 o 3 puntos sobre por qué tomó sus decisiones	Estás aterrizando en un codebase que no conoces
Learning	Además de los Insight, te deja huecos marcados con TODO(human) para que escribas tú el código	Quieres practicar mientras la tarea avanza

Concise no recorta el trabajo, solo el texto. La ingeniería es igual que en Default, y escribe completo cuando se lo pides o cuando lo necesitas para actuar con seguridad: errores, tests que fallan, avisos de seguridad y confirmaciones de acciones destructivas. Requiere Claude Code v2.1.237 o posterior.

Proactive no toca tus permisos. Tu permission mode sigue decidiendo qué se ejecuta sin preguntar.

Learning se para y espera. Cuando llega a una decisión de diseño real, como el manejo de errores o una estructura de datos, deja el hueco, te dice qué valorar y no sigue hasta que le avisas.

Cómo cambiar el output style en Claude Code

Lo más rápido es el comando:

/output-style concise

Sin argumento, /output-style lista los estilos y marca el activo. También puedes ir por /config → Output style. Las dos vías guardan la elección en .claude/settings.local.json.

A mano, el campo es outputStyle:

{
  "outputStyle": "Concise"
}

Aquí hay una trampa: en settings el valor distingue mayúsculas. "concise" no da error; te deja en Default sin avisar. El comando, en cambio, ignora mayúsculas.

Para usar un estilo en todos tus proyectos, ponlo en ~/.claude/settings.json; los settings de cada proyecto tienen prioridad. Si cambias a mitad de sesión, se aplica desde tu siguiente mensaje (desde v2.1.251; antes había que hacer /clear).

Cómo crear un output style propio

Un output style propio es un archivo Markdown: frontmatter con metadatos y, debajo, las instrucciones. Puede vivir en ~/.claude/output-styles/ (usuario), en .claude/output-styles/ (proyecto) o en el directorio de managed settings (política gestionada).

El nombre del archivo es el nombre del estilo, salvo que pongas name. Los cuatro campos son opcionales:

Campo	Para qué sirve	Por defecto
name	Nombre en el selector de /config	El nombre del archivo
description	Descripción en el selector	—
keep-coding-instructions	Con true, conserva las instrucciones de ingeniería de software de Claude Code junto a tu estilo	false
force-for-plugin	Solo en plugins: activa el estilo al habilitar el plugin	false

El campo que más importa es keep-coding-instructions. Si lo omites, tu estilo deja fuera la parte del system prompt que le dice a Claude cómo acotar cambios, escribir comentarios y verificar su trabajo. Para un estilo de developer, casi siempre lo quieres en true. Y ojo con las erratas: un campo mal escrito se ignora sin error.

Un ejemplo útil: un estilo para aprender un framework nuevo

Concise ya cubre "resultado primero, sin narrar". No tiene sentido reescribirlo. Un estilo propio aporta donde ninguno de serie llega: traducir lo nuevo a lo que ya sabes.

Supón que vienes de React y te toca un proyecto en Angular. Explanatory te explica las decisiones, pero no sabe de dónde vienes. Este estilo sí:

---
name: desde-react
description: Explica Angular comparándolo con lo que ya sé de React
keep-coding-instructions: true
---

Soy un developer con experiencia en React que está aprendiendo Angular.

Cuando escribas o modifiques código Angular, termina la respuesta con un
bloque "En React sería" de 2 o 3 puntos que relacione el concepto usado
con su equivalente en React (por ejemplo, signals frente a useState,
inyección de dependencias frente a context).

Si no existe un equivalente razonable, dilo en una frase y explica la
diferencia de modelo mental. No inventes equivalencias forzadas.

No expliques fundamentos de JavaScript ni de TypeScript.

Guárdalo como ~/.claude/output-styles/desde-react.md y actívalo con /output-style desde-react o desde /config. Si lo creas con Claude Code abierto en la terminal, reinícialo: los archivos de estilo se leen al arrancar.

Fíjate en que no dice nada del proyecto: ni comandos, ni estructura, ni convenciones. Eso va en otro sitio.

Output style vs CLAUDE.md vs skill vs system prompt

Un output style controla cómo responde Claude; CLAUDE.md, lo que sabe del proyecto; una skill, cómo hace un tipo de tarea; y --append-system-prompt, una instrucción puntual para una ejecución.

Si ya tienes un CLAUDE.md bien montado, la tentación es meterle "sé breve" y olvidarte. Funciona a medias, porque mezclas dos cosas distintas: lo que Claude sabe del proyecto y cómo te habla.

	Output style	CLAUDE.md	Skill	--append-system-prompt
Qué controla	Tono, formato y rol de todas las respuestas	Lo que Claude debe saber del proyecto	Instrucciones para un tipo de tarea	Una adición a las instrucciones
Cuándo se carga	En cada petición de la sesión	Siempre, sea cual sea el estilo	Al invocarla o cuando la tarea encaja	Al arrancar con el flag
Ejemplo típico	"Resultado primero, sin resumen"	"Tests con bun test, nada de any"	Checklist de release	Una regla puntual para un script
Limitación o riesgo	Sin keep-coding-instructions: true, pierde las instrucciones de ingeniería	Si metes tono aquí, mezclas contexto y forma	No afecta a respuestas ajenas a su tarea	Solo vive en esa ejecución

Mi regla: CLAUDE.md para el qué, output style para el cómo, skill para el cuándo. Y lo que tiene que pasar sin excepción, en un hook. La documentación insiste en que estas piezas se combinan.

Si una tarea necesita su propio procedimiento, no la metas en el estilo: crea una skill. El estilo moldea todas las respuestas, también las que no tienen nada que ver con esa tarea.

Este reparto entre contexto, forma y procedimiento es lo que trabajamos en el curso Construye con IA: de la idea al producto con Claude Code, porque es lo que hace que el agente se comporte igual el lunes que el viernes.

Límites de los output styles

1. Nada lo hace cumplir. En el issue #92175 de anthropics/claude-code un usuario describe que, con un estilo propio de brevedad estricta, el modelo se desvía en turnos largos con muchas herramientas: vuelven los encabezados y las respuestas se alargan. Su solución tiene tres capas: el estilo, un hook UserPromptSubmit que le recuerda las reglas en cada turno y un hook Stop con un validador en Python que bloquea la respuesta si incumple el formato. Ni recordárselo en cada turno bastó; lo que funcionó fue validar. Si el formato te importa de verdad, ese es el camino.

2. Tu estilo podría pesar menos que uno de serie. En el issue #88189 se reporta que los estilos de serie como Concise traen un recordatorio propio que se repite tras cada turno. En el mismo hilo, otro usuario comprobó que los estilos propios también reciben uno, con la misma frecuencia pero genérico: "Remember to follow the specific guidelines for this style." Hoy no puedes definir el tuyo desde el frontmatter. El issue sigue abierto y la documentación no lo menciona, así que tómalo como un reporte, no como un hecho.

3. Los subagentes no lo heredan. Aplica a la conversación principal y a los forks. El resto de subagentes arrancan con su propio system prompt.

4. keep-coding-instructions no siempre tiene efecto. Con el system prompt reducido, ese campo no hace nada. La documentación indica poner CLAUDE_CODE_SIMPLE_SYSTEM_PROMPT a 0 para forzar el prompt completo.

Por dónde empezar hoy

La forma más barata de probar los Claude Code output styles es con uno de serie. No crees un estilo propio el primer día. Prueba /output-style concise una semana de trabajo normal. Si no echas nada de menos, guárdalo en ~/.claude/settings.json y listo.

Cuando estés aprendiendo algo nuevo, cambia a Learning solo en esas sesiones. Y cuando te pilles repitiendo la misma instrucción de formato tres prompts seguidos, ese es el momento de escribir tu archivo en .claude/output-styles/.

Para ver cómo encaja con el resto del flujo, en esta guía para usar Claude Code a diario tienes los comandos y hábitos que lo rodean. Y si quieres separar especificación, contexto y revisión del código que genera el agente, el workshop SDD + Agentic Engineering va justo de eso.

Preguntas frecuentes

¿Cuáles son los output styles de serie de Claude Code?

Además del Default, que es no tener estilo, trae cuatro: Proactive, Concise, Explanatory y Learning. Todos mantienen las instrucciones de ingeniería del Default y añaden las suyas.

¿Cómo cambio el output style en Claude Code?

Con /output-style <nombre> o desde /config → Output style; ambas guardan el cambio en .claude/settings.local.json. También puedes escribir el campo outputStyle en settings, respetando mayúsculas: Concise, no concise.

¿Dónde se guardan los output styles personalizados?

En ~/.claude/output-styles/ para todos tus proyectos o en .claude/output-styles/ para uno concreto (se cargan todas las .claude/output-styles/ que haya entre el directorio de trabajo y la raíz del repo; si dos definen un estilo con el mismo nombre, gana la más cercana al directorio de trabajo). Los plugins también pueden incluirlos en una carpeta output-styles/.

¿Un output style sustituye a CLAUDE.md?

No. CLAUDE.md contiene lo que Claude debe saber de tu proyecto y se carga sea cual sea el estilo. El output style solo cambia cómo responde. Lo normal es usar los dos (así combino CLAUDE.md y memoria en mi flujo).

¿Por qué Claude Code ignora mi output style?

Revisa que outputStyle coincida en mayúsculas con el nombre, que hayas reiniciado tras crear o editar el archivo y que el YAML del frontmatter sea válido: si no se puede leer, el estilo carga con el nombre del archivo pero sin ningún campo, así que pierdes keep-coding-instructions sin aviso (claude --debug muestra el error). Si todo está bien y aun así se desvía, recuerda que es una instrucción: para garantizarlo necesitas un hook.

---

Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.