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 lección te muestra cómo los profesionales combinan esas funcionalidades en flujos de trabajo completos que resuelven desafíos reales de desarrollo. Cada patrón incluye cuándo usarlo, qué configuración requiere y un recorrido paso a paso.

Patrón 1: Pipeline de Revisión de Código

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

Configuración: Un skill que define tus criterios de revisión, más un servidor MCP para integración 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 patrón reemplaza la solicitud ad-hoc de "puedes mirar mi código" con un proceso de revisión repetible y consistente que cubre la misma lista de verificación cada vez.

Patrón 2: Automatización de PR

Cuándo usarlo: Después de recibir feedback en un pull request que requiere múltiples rondas de cambios.

Configuración: 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

Patrón 3: Generación de Documentación

Cuándo usarlo: Cuando tu codebase carece de documentación, o cuando la documentación se ha desfasado del código.

Configuración: 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 periódicamente o intégralo en tu pipeline CI para mantener la documentación sincronizada con el código.

Patrón 4: Desarrollo Guiado por Tests

Cuándo usarlo: Al construir nuevas funcionalidades donde la corrección es crítica.

Configuración: 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

Patrón 5: Flujo de Trabajo de Depuración

Cuándo usarlo: Al enfrentar un bug que no es inmediatamente obvio.

Configuración: 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 sistemático: reproducir, aislar, corregir, verificar. La capacidad de Claude para ejecutar tests repetidamente y analizar patrones lo hace excepcionalmente bueno encontrando causas raíz de tests inestables.

Patrón 6: Refactorización con Seguridad

Cuándo usarlo: Al reestructurar código que funciona correctamente y debe seguir funcionando correctamente.

Configuración: Checkpoints para rollback, suite de tests para verificación.

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 patrón trata la refactorización como una serie de pasos pequeños y verificables. Cada paso es validado por la suite de tests, y cualquier fallo dispara un rollback inmediato al último 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.

Patrón 7: Coordinación Multi-Repositorio

Cuándo usarlo: Cuando un cambio abarca múltiples repositorios (servidor API, librería cliente, documentación).

Configuración: 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

Patrón 8: Migración de Base de Datos

Cuándo usarlo: Cuando necesitas cambiar un esquema de base de datos de una manera que podría romper consultas existentes.

Configuración: Modo planificación 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 más efectivos superponen múltiples funcionalidades de Claude Code:

| Funcionalidad | Rol en el Flujo de Trabajo | |---------------|---------------------------| | Skills | Definir el proceso y la lista de verificación | | Hooks | Imponer barreras de protección automáticamente | | Servidores MCP | Conectar a fuentes de datos externas | | Subagentes | Paralelizar y aislar trabajo | | Checkpoints | Habilitar rollback seguro | | Planificación | Diseñar antes de construir | | Modo print | Automatizar en CI/CD |

Un flujo de trabajo de PR de nivel producción podría usar un skill para definir el proceso de revisión, un hook para bloquear merges sin revisión, un servidor MCP para obtener datos del PR desde GitHub, un subagente para ejecutar análisis de seguridad en aislamiento y un checkpoint antes de aplicar cualquier cambio sugerido.

Anti-Patrones a Evitar

Delegar en exceso sin revisión. Darle a Claude autonomía completa en sistemas críticos sin revisar el plan primero. Siempre usa el modo planificación para cambios de alto impacto.

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

Ignorar señales de costo. Sesiones largas con pensamiento extendido en cada solicitud queman tokens rápido. Usa /cost regularmente y ajusta los niveles de esfuerzo apropiadamente.

Prompts monolíticos. Pedirle a Claude que "refactorice todo el codebase" en un solo prompt. Divide las tareas grandes en pasos enfocados y secuenciales con verificación entre cada uno.

No probar la automatización 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 teóricos -- representan los flujos de trabajo que usuarios experimentados de Claude Code han refinado a través de la práctica diaria. Comienza con los más cercanos a tus necesidades actuales y adáptalos a tu codebase y equipo específicos.