Workflows con Claude Code: configuración, plan mode y CI/CD

Escenario Code Generation with Claude Code. Una desarrolladora nueva entra en el equipo, clona el repositorio, abre Claude Code y empieza a trabajar. A la semana, sus pull requests no siguen las convenciones de tests que el resto aplica sin pensar. Nadie entiende por qué: «Claude ya sabe cómo hacemos los tests». Lo sabe en el portátil de quien lo configuró, porque esas instrucciones estaban en su ~/.claude/CLAUDE.md personal, no en el del proyecto.

Ese tipo de fallo, dónde vive cada pieza de configuración y a quién le llega, es la mitad del dominio 3, Claude Code Configuration & Workflows (20 %, unas 12 preguntas). La otra mitad es cómo se trabaja: plan mode o ejecución directa, cómo iterar con Claude y cómo meterlo en un pipeline de CI/CD. Lo vas a ver con dos escenarios del banco: el de generación de código y Claude Code for Continuous Integration.

Dónde vive cada cosa (3.1, 3.2 y 3.3)

Si solo te llevas una idea de esta lección, que sea este mapa. Pulsa cada casilla:

Los matices que el examen pregunta:

• Diagnosticar la jerarquía. Si alguien no recibe unas instrucciones, lo primero es comprobar si están a nivel de usuario en vez de proyecto. El comando /memory lista los archivos de memoria (CLAUDE.md de usuario y de proyecto, entre otros) y te deja abrirlos; /context muestra cuáles se han cargado en la sesión actual.
• Modularidad. Un CLAUDE.md enorme se parte en archivos temáticos dentro de .claude/rules/, o se usa @import (en la doc, la sintaxis es @ruta) para que cada paquete incluya solo los estándares que le tocan.
• Reglas por ruta frente a CLAUDE.md de carpeta. Si una convención afecta a archivos repartidos por todo el código, como los tests que viven junto a cada componente, un CLAUDE.md por carpeta no escala. Una regla con paths y un patrón glob sí:

---
paths:
  - "**/*.test.tsx"
---
# Convenciones de tests
- Un describe por componente; nombres de test en español.
- Usa los fixtures de tests/fixtures, nunca datos inventados.

• Skill o CLAUDE.md. Lo que debe estar siempre presente (estándares universales) va en CLAUDE.md. Un flujo de trabajo concreto que se usa a demanda (preparar una release, analizar el código) es una skill.

Del frontmatter de las skills, la guía cita tres campos:

• context: fork ejecuta la skill en un subagente aislado. Ideal para lo que genera mucha salida (un análisis de todo el código) o contexto exploratorio (una lluvia de ideas): el resultado vuelve resumido y no ensucia la conversación principal.
• allowed-tools: la guía lo presenta como la forma de limitar qué herramientas usa la skill. En la documentación actual, allowed-tools concede permiso sin preguntar a las herramientas listadas mientras la skill está activa, y el campo que retira herramientas es disallowed-tools. Si en el examen la opción es «configurar allowed-tools para acotar las herramientas de la skill», es la respuesta que espera la guía.
• argument-hint: el texto de ayuda que ves al autocompletar, como [número-de-issue], para recordar qué parámetros pide la skill.

Plan mode o ejecución directa (3.4)

Una decisión que el examen plantea una y otra vez. En plan mode, Claude lee y explora el código y propone un plan, pero no edita nada hasta que lo apruebas. Lo activas con Shift+Tab durante la sesión (la barra de estado muestra ⏸ plan mode on) o arrancando con --permission-mode plan.

Para las fases de descubrimiento largas, Claude Code tiene el subagente integrado Explore: busca y lee en un contexto aparte y devuelve un resumen, de modo que la conversación principal no se agota con salida de exploración. Es la versión práctica de lo que viste en el dominio 1: aislar lo verboso en un subagente.

Iterar con Claude (3.5)

Cuando el resultado no es el que quieres, la guía propone cuatro técnicas, cada una para un problema distinto:

• Ejemplos concretos de entrada y salida. Si la descripción en prosa se interpreta de forma inconsistente, 2 o 3 ejemplos concretos comunican la transformación mejor que otro párrafo. Por ejemplo: cómo debe quedar un código de material de SAP con ceros a la izquierda tras la migración.
• Tests primero. Escribe la batería de tests (comportamiento esperado, casos límite, rendimiento) antes de implementar, y luego itera compartiendo con Claude los fallos.
• El patrón entrevista. En un dominio que no dominas, pide a Claude que te haga preguntas antes de implementar: saldrán cosas como la invalidación de caché o los modos de fallo que no habías previsto.
• Todo junto o de uno en uno. Si los problemas interactúan entre sí, descríbelos todos en un mensaje detallado. Si son independientes, corrígelos por separado.

Claude Code en CI/CD (3.6)

Cambiamos al escenario Claude Code for Continuous Integration. En un pipeline no hay nadie para contestar preguntas, así que Claude Code tiene que ejecutarse sin modo interactivo. Eso lo hace la opción -p (o --print): procesa el prompt, escribe el resultado y termina. Sin ella, el trabajo se queda colgado esperando entrada.

# # -p: sin modo interactivo. <esquema> = tu JSON Schema de hallazgos, en una línea
$ claude -p 'Revisa el diff de esta PR y lista los problemas' --output-format json --json-schema '<esquema>' | jq '.structured_output'
{ hallazgos: [ { archivo: src/pedidos.ts, linea: 42, severidad: alta, problema: … } ] }
# # En CI, acota permisos: herramientas preaprobadas y el resto denegado sin preguntar
$ claude -p 'Ejecuta los tests y resume los fallos' --allowedTools 'Bash(npm test *),Read' --permission-mode dontAsk

Además de las opciones de la CLI, la guía insiste en el contexto que recibe Claude en CI:

• CLAUDE.md es el canal para dar a Claude Code en CI el contexto del proyecto: estándares de testing, fixtures disponibles, qué se considera un test valioso y criterios de revisión. Documentarlo mejora la calidad y reduce los tests de poco valor.
• Pasa los tests existentes cuando pidas generar tests nuevos, para que no proponga escenarios ya cubiertos.
• Al volver a revisar tras nuevos commits, incluye los hallazgos anteriores e indica que informe solo de lo nuevo o de lo que sigue sin resolver. Si no, la PR se llena de comentarios duplicados.
• Revisor independiente. La misma sesión que generó el código es peor revisándolo: conserva el razonamiento con el que lo escribió y tiende a no cuestionarlo. Una instancia separada, sin ese contexto, detecta más.

Si usas GitHub, la integración oficial es la GitHub Action de Claude Code (anthropics/claude-code-action), que se puede instalar desde Claude Code con /install-github-app. Tienes los detalles en la documentación de GitHub Actions y en la de modo no interactivo.

Para el examen

Siguiente paso

Próxima lección: Prompt engineering en producción: criterios explícitos, few-shot, salida estructurada con JSON Schema, validación con reintentos y Batch API (dominio 4).