Cómo estructurar patrones de indicaciones para Claude Code

Patrones de indicaciones, memoria, estructura del proyecto, subagentes, habilidades para Claude Code

Tiempo estimado de lectura: 5 min

Introducción

Patrones de indicaciones, memoria, estructura del proyecto, subagentes y habilidades para Claude Code son los cinco pilares que determinan si un agente CLI acelera tu ingeniería o genera deuda técnica silenciosa. Si no defines cómo hablarle, qué puede recordar, cómo está organizado el repo, cómo se subdividen las tareas y qué permisos tiene, Claude actúa a ciegas. Aquí tienes una guía práctica y accionable para poner orden.

Resumen rápido (lectores con prisa)

Claude Code es un operador que modifica código y ejecuta shells; requiere prompts deterministas, una memoria persistente en raíz (p. ej. CLAUDE.md), una estructura de repo modular, subagentes/orquestación para QA y control estricto de habilidades. Usa TDD y sandboxes antes de delegar cambios en producción.

Claude Code como operador

Claude Code no es un chatbot; es un operador que puede leer y modificar tu código, ejecutar shells y (en previews) automatizar UIs. La diferencia clave: requiere prompts estructurados, memoria explícita del proyecto, una arquitectura de repositorio que el agente pueda razonar, subagentes u orquestadores para tareas auxiliares y un control estricto de habilidades (tool use). Documentación útil: docs.anthropic — Claude Code y, para orquestación, n8n. Para novedades y previews (p. ej. Computer Use) revisa releasebot.dev.

1) Patrones de indicaciones — cómo pedirle cosas a Claude Code

No escribas prompts vagos. Usa plantillas deterministas:

Patrón Contexto‑Restricción‑Acción

– Contexto: qué módulo, stack, rama. (“Servicio payments — Node.js/TS — branch feat/rate-limit”)

– Restricción: reglas innegociables. (“No tocar DB schema; no añadir deps externas”)

– Acción: objetivo con criterio verificable. (“Implementa rate limiting y añade tests que cubran 429; PR con test passing en CI es criterio de éxito”)

Prompt de TDD (Test-Driven Prompting)

– Paso 1: “Escribe el test que debería fallar”

– Paso 2: pedir ejecución del test

– Paso 3: solicitar la implementación hasta que los tests pasen

Ejemplo de prompt (compacto):

“Contexto: /services/payments, Node 18, TS. Restricción: no tocar migraciones. Acción: añade rate limiter en /api/charge; escribe tests unitarios y de integración; criterio: pipeline CI verde. Empieza por crear tests que fallen.”

2) Memoria — cómo mantener contexto útil y persistente

Claude Code construye su contexto leyendo el repo; no tiene intuición humana. Dos mecanismos clave:

• Memoria de sesión (corto plazo): archivos abiertos y árbol activo. Evita saturarla con monorepos gigantes; abre solo lo necesario.
• Memoria persistente (largo plazo): un archivo en la raíz que Claude lee siempre. Recomendación práctica:

– CLAUDE.md o .clauderc con:

• Convenciones de estilo y nomenclatura
• Comandos claves (tests, build, dev)
• ADRs esenciales
• Dependencias permitidas/prohibidas
• Checklists de seguridad y compliance

Este archivo convierte normas humanas en reglas ejecutables por el agente y reduce ambigüedad.

3) Estructura del proyecto — diseño para agentes

Diseña el repo pensando en unidades pequeñas y autocontenidas:

• Modularidad: archivos <300 líneas, responsabilidades únicas.
• Rutas semánticas: /auth/use-cases/login.ts en vez de /utils/helper9.ts.
• Tipado estricto: TypeScript/Rust/Go ayudan al agente a validar cambios antes de ejecutarlos.
• Tests como contrato: TDD + coverage mínimo hacen al agente predecible.

Si el repo es un monolito acoplado, prioriza una fase de refactor (extract module) manual antes de delegar en agentes.

4) Subagentes y orquestación — dividir para no perder contexto

Claude Code aún no gestiona subagentes complejos de forma nativa. La práctica efectiva es orquestar subagentes externos:

– Usa n8n o un orquestador propio para:

• Ejecutar análisis estático en entornos aislados
• Lanzar pipelines de seguridad y escaneo de dependencias
• Devolver reportes al CLI para que Claude actúe sobre ellos

Patrón típico:

1. Claude genera un PR provisional.
2. n8n ejecuta linters, SCA y tests en una VM sandbox.
3. Resultado vuelve al CLI; Claude corrige y reitera.

Así evitas que un único agente cargue demasiado contexto o tome decisiones incompletas.

5) Habilidades (Tool Use) — permisos y límites

Define explícitamente qué puede ejecutar el agente. Habilidades críticas:

• Bash Execution: npm test, git, docker-compose — imprescindible para feedback real.
• File System Access: lectura/escritura de archivos.
• Semantic Search / Repo Index: para referencias cruzadas antes de modificar.
• (Preview) Computer Use: interacción con UIs nativas — potente, frágil y debe usarse solo en sandboxes.

Regla de oro: nunca habilites habilidades destructivas en máquinas con credenciales reales. Usa contenedores o VMs aisladas.

Checklist mínimo de adopción antes de delegar tareas

1. CLAUDE.md en raíz con políticas y comandos.
2. Tests automatizados que sirvan de contrato.
3. Entorno sandbox (Docker/VM) para ejecución.
4. CI que valide PRs generados por el agente.
5. Orquestador (n8n o similar) para subagentes de QA/security.
6. Prompts basados en Contexto‑Restricción‑Acción y TDD.

Conclusión

Patrones de indicaciones, memoria, estructura del proyecto, subagentes y habilidades para Claude Code no son conceptos teóricos: son requisitos operativos. Implementados juntos, convierten a Claude en un multiplicador de capacidad. Si fallas en cualquiera, el agente acelera errores, no entrega. Empieza por documentar: CLAUDE.md, tests firmes y sandboxes. Luego automatiza, orquesta y vigila. Esto no acaba aquí: quien domine estas cinco piezas tendrá ventaja real al escalar agentes en ingeniería.

Dominicode Labs

Para equipos que integran automatización y orquestación de subagentes como parte de su plataforma de ingeniería, una continuación natural es explorar herramientas y patrones documentados en Dominicode Labs. La referencia ayuda a unir prácticas de prompts, memoria y sandboxes con flujos de trabajo reproducibles.

FAQ

• ¿Qué es Claude Code y en qué se diferencia de un chatbot?
• ¿Qué debe contener un archivo CLAUDE.md?
• ¿Cuándo debo usar subagentes u orquestadores?
• ¿Qué habilidades del agente debo deshabilitar en producción?
• ¿Cómo aplicar TDD con Claude Code?
• ¿Por qué modularizar archivos en <300 líneas?
• ¿Qué papel juega CI en el flujo con agentes?

¿Qué es Claude Code y en qué se diferencia de un chatbot?

Claude Code es un operador diseñado para leer y modificar repositorios, ejecutar comandos de shell y automatizar tareas. A diferencia de un chatbot, espera prompts estructurados y tiene habilidades (tool use) que deben definirse y limitarse explícitamente.

¿Qué debe contener un archivo CLAUDE.md?

Debe incluir convenciones de estilo, comandos claves (tests/build/dev), ADRs importantes, dependencias permitidas/prohibidas y checklists de seguridad. Su propósito es convertir reglas humanas en referencia legible por el agente.

¿Cuándo debo usar subagentes u orquestadores?

Úsalos cuando el pipeline requiera aislamiento (análisis estático, SCA, pruebas en sandbox) o cuando el agente principal necesite retroalimentación externa antes de cometer cambios. Orquestadores como n8n facilitan este patrón.

¿Qué habilidades del agente debo deshabilitar en producción?

Deshabilita cualquier ejecución con acceso a credenciales reales o capacidad destructiva directa sobre entornos de producción. Mantén ejecución de bash y acceso a filesystem solo en contenedores/VMs aisladas.

¿Cómo aplicar TDD con Claude Code?

Sigue el patrón: pide primero tests que fallen, ejecuta tests en sandbox, luego solicita la implementación hasta que los tests pasen. Define criterios de éxito claros (por ejemplo, pipeline CI verde) en el prompt.

¿Por qué modularizar archivos en <300 líneas?

Archivos pequeños y responsabilidades únicas facilitan que el agente razone sobre cambios y reduzcan el riesgo de efectos colaterales imprevistos.

¿Qué papel juega CI en el flujo con agentes?

CI actúa como guardián: valida PRs generados por el agente, ejecuta tests y linters y evita que cambios automatizados lleguen a producción sin verificación.