De todas las features que Anthropic ha ido añadiendo a Claude Code en los últimos meses, output styles es la que más cambia tu día a día con poco esfuerzo. Es la pieza que te deja convertir a Claude Code en un junior que pregunta antes de actuar, en un senior que solo te entrega diffs sin charla, o en un profesor que explica cada decisión técnica.
Si ya conoces el pillar técnico de Claude Code por dentro, los hooks y las skills, output styles es la última pieza para entender la capa de UX del agente: cómo se comporta y cómo se comunica contigo.
Qué son los output styles
Un output style es un conjunto de instrucciones que modifican el system prompt de Claude Code. Cambian cómo responde, no qué sabe ni qué herramientas tiene disponibles.
En la práctica:
Cambian el rol del agente (junior, senior, profesor, revisor).
Cambian el tono (verbose, terso, didáctico).
Cambian el formato de output (markdown estructurado, listas, código directo).
Mantienen las capacidades core: seguir leyendo y escribiendo archivos, ejecutar bash, usar TODO trackers, etc.
Como dice la doc oficial: output styles change how Claude responds, not what Claude knows.
Built-ins disponibles
Claude Code viene con tres estilos predefinidos:
1. Default
El system prompt original, optimizado para tareas de software engineering. Comportamiento "consultor que ejecuta": entiende la tarea, decide los pasos, te informa cuando hay decisiones importantes, ejecuta cuando puede.
Cuándo usarlo: el día a día normal de coding.
2. Explanatory
Mismo trabajo que Default pero inserta "Insights" educativos entre tareas. Si Claude descubre algo no obvio mientras edita tu código (un patrón curioso, un trade-off arquitectónico, un detalle del framework), te lo cuenta.
Cuándo usarlo: cuando estás aprendiendo un codebase nuevo o cuando quieres entender mejor lo que está pasando, no solo tener el código terminado.
3. Learning
Modo colaborativo. Claude comparte insights Y te pide que tú escribas pequeñas piezas de código dejando marcadores TODO(human) en sitios concretos. Tú llenas, él sigue.
Cuándo usarlo: tutoriales, onboarding de juniors a un repo, sesiones de pair programming donde quieres aprender escribiendo, no solo leyendo.
Activarlos
Tres formas:
/output-style # menú interactivo
/output-style explanatory # cambio directo
/output-style learning # cambio directo
/output-style default # vuelve al defaultTambién accesible desde /config → Output Style.
Crear estilos custom
La forma rápida es desde dentro de Claude Code:
/output-style:new actúa como senior reviewer: critica mi código, sugiere mejoras, no escribas tú salvo que lo pida explícitamenteClaude Code te genera un archivo Markdown en ~/.claude/output-styles/<nombre>.md con las instrucciones. A partir de ahí lo puedes:
Activar con
/output-style <nombre>.Editar a mano para refinar.
Compartir copiándolo.
Estructura del archivo
Un output style es Markdown plano. Algo así:
---
name: senior-reviewer
description: Actúa como senior reviewer; critica, no escribe salvo petición.
---
# Senior Reviewer Mode
Trabajas como un senior reviewer ácido pero útil. Tu trabajo NO es escribir código,
sino revisar el código que el usuario escriba o te enseñe y darle feedback.
## Reglas
- Por defecto, NO escribas código tú. Comenta, sugiere, critica con bullet points.
- Cuando el usuario diga "escribe esto" o "hazlo tú", entonces sí escribes.
- Cita siempre línea/archivo cuando hagas un comentario sobre código existente.
- Sé directo, sin rodeos. Sin emojis.
- Cuando veas un patrón problemático, di por qué es problemático, no solo que lo es.
- Si un cambio del usuario te parece mal, mejor dilo claro que dejarlo pasar.
## Ejemplos de mensajes que sí debes dar
- "src/auth.ts:45 — esto fuga el token al log. Cambia con un mascarado."
- "El patrón XYZ aquí es trampa, te va a explotar cuando..."Por defecto el archivo se guarda en ~/.claude/output-styles/ (user-level), pero puedes ponerlo en .claude/output-styles/ del repo para que aplique solo a ese proyecto.
Casos de uso reales
1. Code reviewer estricto
Output style "ácido pero justo" que revisa PRs sin escribir, solo critica. Bueno para sesiones de revisión de código de juniors o para revisar tus propios diffs antes de commit.
2. Pair programming pedagógico
Modo Learning con un overlay que pide al usuario implementar partes específicas. Excelente para onboarding: junior nuevo lee el repo con Claude, Claude le pide que implemente el helper que falta.
3. Junior que pregunta todo
Útil al revés: tú actúas como senior, Claude actúa como junior cauto. Un output style que siempre pregunta antes de actuar ("¿prefieres hacer esto con Promise.all o con un for-of secuencial?", "¿quieres que añada tests?"). Para gente que prefiere control granular sobre la autonomía completa de Default.
4. Documentation writer
Estilo que solo edita documentación, README y comentarios. No toca código de producto. Perfecto para sesiones tipo "una hora a documentar el módulo X".
5. Spanish output enforced
Estilo que responde siempre en español ignorando el idioma del prompt. Para equipos hispanohablantes que mezclan inglés en queries pero quieren respuestas en castellano consistentes.
---
name: castellano
description: Responde siempre en español peninsular sin tildes raras.
---
Responde SIEMPRE en español peninsular, aunque la pregunta venga en inglés.
Mantén tech terms sin traducir (API, framework, deploy).
Sin emojis. Sin frases tipo "Espero que esto ayude". Directo.6. Conservative mode (cero auto-ejecución)
Estilo que evita ejecutar nada por sí mismo. Solo escribe planes y muestra diffs propuestos; tú apruebas y ejecutas. Útil en repos críticos o entornos de producción.
Output styles vs hooks vs skills
Es fácil confundir las tres cosas:
|
Capa |
Qué cambia |
Cuándo usarla |
|---|---|---|
|
Output style |
El system prompt: rol, tono, formato |
Cuando quieres distinto comportamiento del agente |
|
Eventos: ejecuta scripts cuando pasa X |
Cuando quieres acciones automáticas (logging, validación, notificación) |
|
|
Instrucciones específicas de tarea |
Cuando quieres que Claude sepa cómo hacer una tarea concreta (deploy a Vercel, ejecutar un workflow específico) |
Combinarlos da workflows ricos:
Output style "code reviewer" + hook que loguea cada PR revisada + skill que sabe cómo abrir comentarios en GitHub.
Output style "Spanish" + skill "Levante voice" para escribir blog posts.
Limitaciones
Cosas que no resuelves con output styles:
No cambian las herramientas disponibles: si quieres que Claude no use Bash, eso se controla con permissions (sistema de permisos), no con output style.
No persisten entre sesiones a la fuerza: tienes que activarlos. Si quieres que un proyecto siempre arranque con un estilo, ponlo en
.claude/settings.jsoncon"defaultOutputStyle": "...".No sustituyen el CLAUDE.md: el
CLAUDE.mddel repo sigue siendo el sitio para conocimiento del proyecto. Output style es para comportamiento.Modelos pequeños lo ignoran más: cuanto mejor el modelo, mejor sigue las instrucciones. Sonnet 4.6 / Opus 4.7 cumplen muy bien; modelos pequeños tienden a desviarse.
Trucos avanzados
Output style con triggers contextuales
Puedes hacer que el estilo cambie sólo en ciertos archivos. Truco: pon en el .md del estilo algo como:
Si el usuario está editando archivos en /docs, entra en modo "documentation writer".
Si está en /src, entra en modo "senior reviewer".Funciona razonablemente bien con Opus 4.7. Con Sonnet, la heurística falla más a menudo.
Versionar output styles del equipo
Crear .claude/output-styles/ en el repo, commitear los .md. Cualquier miembro del equipo abre Claude Code y tiene los estilos disponibles. Útil para:
Estilo "PR-reviewer" del equipo.
Estilo "deploy-buddy" que sabe los pasos exactos del deploy de tu repo.
Estilo "incident-responder" para los oncalls.
Combinar con hooks
Hook OnUserPromptSubmit que detecta keywords y cambia output style automáticamente. Por ejemplo: si el prompt empieza con "review:" cambias a estilo reviewer; si empieza con "explain:" cambias a Explanatory.
#!/usr/bin/env bash
# .claude/hooks/auto-style.sh
PROMPT=$(cat)
if [[ "$PROMPT" == "review:"* ]]; then
echo '/output-style senior-reviewer'
elif [[ "$PROMPT" == "explain:"* ]]; then
echo '/output-style explanatory'
fiErrores comunes
Crear estilos demasiado largos: 50 líneas de instrucciones quema tokens y diluye el efecto. Mejor 10-15 líneas claras.
Estilos contradictorios: "sé verbose" + "sé conciso" no se entienden bien. Decide uno.
Olvidar el frontmatter
name: el comando/output-style <nombre>busca por ese campo.Confundir nivel user con nivel project: si el
.mdestá en.claude/del repo, solo aplica en ese repo. Si está en~/.claude/, aplica global.Esperar magia: output styles modifican el system prompt, no son magia. Si Opus no entiende tu instrucción, modelos peores la ignoran más.
Conclusión
Output styles son la forma más limpia de adaptar Claude Code a cómo trabajas tú. Empieza con los built-ins (Explanatory si quieres aprender, Learning si quieres pair programming, Default para todo lo demás), y cuando tengas claro qué cambios persistentes quieres, crea uno custom con /output-style:new.
Combinados con hooks, skills y una statusline bien montada, tienes a Claude Code a tu medida sin tocar el binario.
La doc oficial de output styles está en code.claude.com/docs/en/output-styles. La comunidad mantiene la lista awesome-claude-code-output-styles-that-i-really-like con buenas plantillas para empezar.
