Saltar al contenido
Lección 12 de 14

Patrones y Flujos de Trabajo del Mundo Real

9 min read

De Funcionalidades a Flujos de Trabajo

Has aprendido funcionalidades individuales de Claude Code a lo largo de este curso. Esta leccion te muestra como los profesionales combinan esas funcionalidades en flujos de trabajo completos que resuelven desafios reales de desarrollo. Cada patron incluye cuando usarlo, que configuracion requiere y un recorrido paso a paso.

Patron 1: Pipeline de Revision de Codigo

Cuando usarlo: Antes de fusionar cualquier pull request, especialmente en equipos sin revisores dedicados.

Configuracion: Un skill que define tus criterios de revision, mas un servidor MCP para integracion con GitHub.

Crea skills/code-review.md:

---
triggers:
  - slash_command
name: review-pr
description: Pipeline de revision de codigo integral
---

Ejecuta estas verificaciones en orden:

1. Ejecutar el linter: `npm run lint` — reportar cualquier violacion
2. Ejecutar la suite de tests: `npm test` — confirmar que todos los tests pasan
3. Verificar problemas de seguridad: `npm audit --production`
4. Revisar el diff buscando:
   - Errores de logica y casos borde
   - Manejo de errores faltante
   - Preocupaciones de rendimiento
   - Nomenclatura y legibilidad
5. Resumir hallazgos con calificaciones de severidad: critico, advertencia, informativo

Flujo de trabajo:

# En Claude Code con servidor MCP de GitHub configurado
/review-pr

# Claude ejecuta linter, tests, auditoria de seguridad, luego revisa el diff
# Salida: revision estructurada con items accionables

Este patron reemplaza la solicitud ad-hoc de "puedes mirar mi codigo" con un proceso de revision repetible y consistente que cubre la misma lista de verificacion cada vez.

Patron 2: Automatizacion de PR

Cuando usarlo: Despues de recibir feedback en un pull request que requiere multiples rondas de cambios.

Configuracion: Servidor MCP de GitHub para obtener comentarios del PR.

Flujo de trabajo:

# Obtener todos los comentarios de revision del PR
Tu: Obtiene los comentarios de revision del PR #42 y aborda cada uno.

# Claude lee cada comentario, entiende el cambio solicitado,
# hace la edicion y marca el comentario como resuelto

# Despues de abordar todos los comentarios
Tu: Ejecuta los tests para verificar que nada se rompio, luego haz push de los cambios.

Para equipos que manejan muchos PRs, envuelve esto en un skill:

---
triggers:
  - slash_command
name: pr-comments
description: Obtener y abordar todos los comentarios de revision del PR
---

1. Usa el servidor MCP de GitHub para obtener todos los comentarios de revision sin resolver del PR actual
2. Para cada comentario:
   a. Lee el comentario y entiende el cambio solicitado
   b. Haz el cambio en el archivo relevante
   c. Ejecuta los tests afectados para verificar la correccion
3. Despues de abordar todos los comentarios, ejecuta la suite completa de tests
4. Muestra un resumen de todos los cambios realizados

Patron 3: Generacion de Documentacion

Cuando usarlo: Cuando tu codebase carece de documentacion, o cuando la documentacion se ha desfasado del codigo.

Configuracion: Modo print para procesamiento por lotes.

#!/bin/bash
# generate-api-docs.sh

for file in src/api/**/*.ts; do
  module=$(basename "$file" .ts)
  echo "Documentando: $module"

  claude -p "Genera documentacion de API para este modulo. Incluye:
    - Proposito del modulo (un parrafo)
    - Todas las funciones exportadas con firmas, parametros, tipos de retorno
    - Ejemplos de uso para cada funcion
    - Casos de error y como manejarlos
    Produce como markdown." \
    --max-turns 3 \
    < "$file" > "docs/api/${module}.md"
done

Ejecuta este script periodicamente o integralo en tu pipeline CI para mantener la documentacion sincronizada con el codigo.

Patron 4: Desarrollo Guiado por Tests

Cuando usarlo: Al construir nuevas funcionalidades donde la correccion es critica.

Configuracion: Un skill que impone el ciclo TDD.

---
triggers:
  - slash_command
name: tdd
description: Desarrollo guiado por tests — escribe tests primero, luego implementa
---

Sigue el ciclo TDD estrictamente:

1. Pide al usuario que describa la funcionalidad o funcion
2. Escribe casos de test exhaustivos PRIMERO:
   - Tests del camino feliz
   - Casos borde (entrada vacia, null, valores limite)
   - Casos de error (entrada invalida, fallos de red)
3. Ejecuta los tests — confirma que todos FALLAN (fase roja)
4. Implementa el codigo minimo para que los tests pasen (fase verde)
5. Ejecuta los tests — confirma que todos PASAN
6. Refactoriza la implementacion para claridad y rendimiento (fase refactor)
7. Ejecuta los tests — confirma que siguen PASANDO
8. Muestra al usuario el archivo de test final y la implementacion

Flujo de trabajo:

/tdd

Tu: Necesito una funcion que valide direcciones de email. Debe soportar
    formatos estandar, rechazar falsificaciones obvias y manejar casos borde
    como plus-addressing y dominios internacionales.

# Claude escribe 12 casos de test primero, los ejecuta (todos fallan),
# luego implementa el validador, ejecuta tests (todos pasan),
# luego refactoriza para legibilidad

Patron 5: Flujo de Trabajo de Depuracion

Cuando usarlo: Al enfrentar un bug que no es inmediatamente obvio.

Configuracion: Pensamiento extendido habilitado, esfuerzo configurado en alto.

Flujo de trabajo:

1. Reproducir
   Tu: Este test esta fallando intermitentemente: tests/auth/session.test.ts
       Ejecutalo 5 veces y dime el patron.

2. Aislar
   Claude: [ejecuta test 5 veces, analiza salida]
   "El test falla cuando los tests se ejecutan en paralelo porque comparten
    una conexion a base de datos. La tabla de sesiones tiene una condicion
    de carrera en inserciones concurrentes."

3. Corregir
   Tu: Corrige la condicion de carrera. Usa bloqueo a nivel de base de datos
       o restricciones unicas en lugar de verificar-luego-insertar.

   Claude: [modifica el servicio de sesiones, agrega migracion con restriccion unica]

4. Verificar
   Tu: Ejecuta el test 20 veces para confirmar que es estable.

   Claude: [ejecuta test 20 veces — todos pasan]
   "20/20 pasaron. La correccion es estable."

La clave es el enfoque sistematico: reproducir, aislar, corregir, verificar. La capacidad de Claude para ejecutar tests repetidamente y analizar patrones lo hace excepcionalmente bueno encontrando causas raiz de tests inestables.

Patron 6: Refactorizacion con Seguridad

Cuando usarlo: Al reestructurar codigo que funciona correctamente y debe seguir funcionando correctamente.

Configuracion: Checkpoints para rollback, suite de tests para verificacion.

Flujo de trabajo:

1. Checkpoint (automatico)
2. Ejecutar suite completa de tests — linea base todos pasando
3. Refactorizar paso a paso:
   a. Extraer modulo → ejecutar tests → pasan? continuar : rewind
   b. Renombrar interfaces → ejecutar tests → pasan? continuar : rewind
   c. Reorganizar imports → ejecutar tests → pasan? continuar : rewind
4. Revision final: ejecutar suite completa + linter
5. Si todo pasa → commit
6. Si algo falla → /rewind al ultimo checkpoint bueno

Este patron trata la refactorizacion como una serie de pasos pequenos y verificables. Cada paso es validado por la suite de tests, y cualquier fallo dispara un rollback inmediato al ultimo estado bueno conocido.

Tu: Refactoriza el servicio de usuario en modulos separados: autenticacion,
    gestion de perfil y autorizacion. Despues de cada extraccion, ejecuta
    la suite de tests y solo procede si todos los tests pasan.
    Si algun test falla, retrocede e intenta un enfoque diferente.

Patron 7: Coordinacion Multi-Repositorio

Cuando usarlo: Cuando un cambio abarca multiples repositorios (servidor API, libreria cliente, documentacion).

Configuracion: Subagentes en worktrees separados para cada repositorio.

Tu: Necesito agregar un nuevo endpoint de "teams" a la API, actualizar la libreria
    cliente JS para soportarlo y agregar el endpoint a la documentacion de la API.

# Claude crea subagentes:
# - Agente 1: trabaja en el repo api-server (agregar endpoint + tests)
# - Agente 2: trabaja en el repo js-client (agregar metodo cliente + tests)
# - Agente 3: trabaja en el repo api-docs (agregar documentacion del endpoint)

# Cada agente trabaja en su propio worktree, independientemente
# La sesion principal coordina y revisa todos los cambios

Patron 8: Migracion de Base de Datos

Cuando usarlo: Cuando necesitas cambiar un esquema de base de datos de una manera que podria romper consultas existentes.

Configuracion: Modo planificacion para seguridad, servidor MCP para acceso a base de datos.

Flujo de trabajo:

# Comenzar con un plan — sin cambios aun
/plan Necesito dividir la tabla "users" en "users" y "profiles".
     La migracion debe ser backwards-compatible y soportar despliegue sin downtime.

# Claude explora el codebase, encuentra todas las consultas que tocan la tabla users
# y produce un plan de migracion:
#
# Fase 1: Agregar tabla profiles, copiar datos
# Fase 2: Actualizar consultas para leer de profiles
# Fase 3: Agregar triggers para escritura dual durante la transicion
# Fase 4: Eliminar columnas obsoletas despues de verificacion

# Revisar y aprobar el plan, luego ejecutar fase por fase

Combinando Funcionalidades

Los flujos de trabajo mas efectivos superponen multiples funcionalidades de Claude Code:

| Funcionalidad | Rol en el Flujo de Trabajo | |---------------|---------------------------| | Skills | Definir el proceso y la lista de verificacion | | Hooks | Imponer barreras de proteccion automaticamente | | Servidores MCP | Conectar a fuentes de datos externas | | Subagentes | Paralelizar y aislar trabajo | | Checkpoints | Habilitar rollback seguro | | Planificacion | Disenar antes de construir | | Modo print | Automatizar en CI/CD |

Un flujo de trabajo de PR de nivel produccion podria usar un skill para definir el proceso de revision, un hook para bloquear merges sin revision, un servidor MCP para obtener datos del PR desde GitHub, un subagente para ejecutar analisis de seguridad en aislamiento y un checkpoint antes de aplicar cualquier cambio sugerido.

Anti-Patrones a Evitar

Delegar en exceso sin revision. Darle a Claude autonomia completa en sistemas criticos sin revisar el plan primero. Siempre usa el modo planificacion para cambios de alto impacto.

Omitir checkpoints en operaciones arriesgadas. Si no lo harias sin un Git stash, no lo hagas sin un checkpoint.

Ignorar senales de costo. Sesiones largas con pensamiento extendido en cada solicitud queman tokens rapido. Usa /cost regularmente y ajusta los niveles de esfuerzo apropiadamente.

Prompts monoliticos. Pedirle a Claude que "refactorice todo el codebase" en un solo prompt. Divide las tareas grandes en pasos enfocados y secuenciales con verificacion entre cada uno.

No probar la automatizacion en aislamiento. Desplegar un pipeline CI con pasos de Claude Code sin probar los comandos exactos localmente primero. Siempre verifica con claude -p antes de comprometerte con un flujo de trabajo.

Estos patrones no son teoricos -- representan los flujos de trabajo que usuarios experimentados de Claude Code han refinado a traves de la practica diaria. Comienza con los mas cercanos a tus necesidades actuales y adaptalos a tu codebase y equipo especificos.