6 principios de prompts para mejorar la calidad de los resultados de Claude Code
================================================================================

Explica cómo comunicar de forma estructurada el contexto, el contrato de salida, la gestión de excepciones y los criterios de validación, en lugar de limitarse a pedir a Claude Code que genere código. También ofrece plantillas de prompts aplicables de inmediato al desarrollo de nuevos agentes, la incorporación de funciones y la corrección de errores.

- 1. Antes de comenzar el trabajo, reúna en un solo documento el contexto del usuario, el problema que debe resolverse, los criterios de éxito y las restricciones técnicas.
- 2. Especifique la estructura de archivos, el formato de los datos, los límites permitidos y las condiciones de finalización mediante un contrato de salida concreto.
- 3. Defina las excepciones previsibles, como fallos de API externas, resultados vacíos, datos duplicados y errores de autenticación, junto con las políticas para responder a ellas.
- 4. Divida el trabajo en las fases de revisión del plan, implementación de las funciones mínimas, pruebas automatizadas y ampliación de funciones, y compruebe los resultados en cada etapa.
- 5. En lugar de solicitar una revisión ambigua, proporcione casos de error y objetivos de mejora medibles, y valídelos mediante las condiciones finales de aceptación.

Los agentes de programación como Claude Code no son herramientas que se limitan a generar un fragmento de código, sino entornos de trabajo capaces de explorar repositorios, modificar varios archivos y ejecutar pruebas y comandos. Por tanto, la calidad del resultado depende en gran medida, más que de lo verosímil que suene el texto, de la claridad con la que se definan el alcance del trabajo y el método de validación.
Un buen prompt no es una explicación extensa, sino una especificación de trabajo ejecutable. Debe comunicar no solo qué se quiere crear, sino también por qué es necesario, qué condiciones deben cumplirse, cómo gestionar los fallos y qué debe superarse para considerar el trabajo terminado.

Lo primero que hay que distinguir: el prompt y el entorno de ejecución
La programación por vibraciones es una forma de colaboración en la que se comunica la intención mediante lenguaje natural y un agente de IA se encarga de la implementación. Sin embargo, el hecho de solicitar algo mediante lenguaje natural no garantiza la precisión del código ni la estabilidad operativa.
En un trabajo con Claude Code intervienen conjuntamente los siguientes elementos.

Elemento
Función
Qué comprobar en el prompt

Solicitud del usuario
Comunicar el objetivo y el alcance de los cambios
Propósito, prioridades, prohibiciones

Contexto del repositorio
Proporcionar la estructura y las reglas existentes
Framework, comandos de ejecución, archivos relacionados

CLAUDE.md
Proporcionar instrucciones del proyecto que se aplican repetidamente
Reglas de programación, métodos de prueba, convenciones de directorios

Permisos de herramientas
Controlar el alcance permitido para modificar archivos y ejecutar comandos
Comandos que pueden ejecutarse y operaciones que requieren confirmación previa

Conexiones externas
Acceder a API, bases de datos, servidores MCP, etc.
Método de autenticación, límites de confianza, política ante fallos

Procedimiento de validación
Determinar si el resultado cumple los requisitos
Pruebas, análisis estático, elementos de comprobación manual

Redactar bien el prompt no resuelve por sí solo todos los problemas. Por ejemplo, Claude Code puede crear código para ejecuciones programadas, pero para que una tarea se ejecute incluso cuando el ordenador está apagado se necesita un servidor independiente, un servicio de CI o un programador del sistema operativo. Del mismo modo, el envío de correos electrónicos no puede completarse sin las credenciales de autenticación y los permisos de envío de un proveedor real.

Principio 1. Explicar primero el contexto, el propósito y las restricciones
Si solo se indica el nombre del resultado, como Crea un agente de recopilación de noticias, el agente tendrá que deducir quién es el usuario, cuáles son las fuentes de datos, cuál es el entorno de ejecución y cuáles son los criterios de éxito. Incluso para un mismo recopilador de noticias, las fuentes y los criterios de clasificación que necesitan un responsable de desarrollo de negocio, un inversor y un editor de un periódico universitario son distintos.

Solicitud insuficiente
Crea un agente de recopilación de noticias sobre IA.

Solicitud mejorada
Soy responsable de desarrollo de negocio en una startup de TI.
Antes de comenzar a trabajar cada día, quiero consultar rápidamente noticias
de los sectores de la IA, la nube y las fintech que puedan influir
en las alianzas comerciales o en la estrategia de producto.

Objetivos:
- Recopilar candidatos de artículos recientes para cada palabra clave especificada.
- Eliminar artículos con la misma URL y duplicados con títulos similares.
- Clasificar el impacto como alto, medio o bajo según si es necesario
  tomar una decisión sobre el producto o una alianza en un plazo de 3 meses.
- Crear con los resultados un boletín por correo electrónico en coreano.

Restricciones:
- Mantener la versión de Python y el método de gestión de paquetes del repositorio actual.
- Antes de añadir una biblioteca nueva, explicar su necesidad y las alternativas.
- No registrar claves de API ni contraseñas de correo electrónico en el código o los registros.
- Antes del envío real del correo, generar únicamente un archivo de vista previa.

Primero, investiga la estructura del repositorio y el método de ejecución,
y después propón un plan de implementación.
No deduzcas la información desconocida del entorno; organízala como una lista de preguntas.

Una buena información de contexto contiene los cuatro elementos siguientes.

Usuario y situación de uso: quién lo utiliza, cuándo y para qué decisión

Objetivo: cuál es el problema que debe resolverse, más allá de escribir código

Restricciones: qué tecnologías, reglas de seguridad y límites de coste o tiempo deben mantenerse

No objetivos: qué funciones quedan excluidas explícitamente de este cambio

Especificar los no objetivos permite evitar que el alcance crezca indefinidamente. Por ejemplo, al establecer que en esta fase se excluyen la ejecución programada y el envío real de correos electrónicos, se pueden validar primero de forma estable la lógica de recopilación y la de clasificación.

Principio 2. Convertir el formato de salida deseado en un contrato de salida
Envíalo por correo con un formato atractivo puede interpretarse de forma distinta según la persona. En lugar de mostrar únicamente un ejemplo del formato de salida, también deben definirse los campos obligatorios, los valores permitidos, la gestión de datos ausentes y el orden de clasificación.
Asunto del correo:
[Boletín de noticias] {YYYY-MM-DD} Noticias clave de hoy

Formato de los artículos en el cuerpo:
1. {Título}
Resumen: {1~2 frases en coreano}
Impacto: {Alto|Medio|Bajo}
Motivo de la decisión: {1 frase}
Fuente: {Nombre del medio}
Enlace: {URL original}

Reglas de ordenación:
1. De mayor a menor impacto
2. Si el impacto es igual, por fecha de publicación, empezando por la más reciente

Estadísticas al final:
- Número total de artículos
- Número de artículos por nivel de impacto
- Palabras clave sin resultados de búsqueda

Restricciones:
- No inventar en el resumen cifras ni afirmaciones ausentes del original.
- Si no puede comprobarse la fecha, no estimarla y mostrar 'No se puede comprobar'.
- Excluir del boletín final los elementos que no tengan enlace.

Si el resultado debe transmitirse entre programas, conviene solicitar un esquema JSON o una definición de tipos junto con un ejemplo legible para las personas.
{
  "title": "string",
  "summary": "string",
  "impact": "high | medium | low",
  "reason": "string",
  "source": "string",
  "url": "absolute URL",
  "published_at": "ISO 8601 string | null"
}

El contrato de salida no solo incluye el formato, sino también el significado. Si no existen criterios para determinar qué significa impact: high, la sintaxis JSON puede ser correcta, pero los resultados de la clasificación pueden ser incoherentes.

Principio 3. Especificar las situaciones excepcionales y las políticas de recuperación
La calidad del código operativo se revela más en las rutas de fallo que en la ruta normal. El prompt debe incluir los fallos previsibles, si pueden reintentarse, las condiciones en las que debe informarse al usuario y la información que no debe registrarse.

Situación excepcional
Ejemplo de política recomendada

No hay resultados de búsqueda
Omitir esa palabra clave y registrarla en las estadísticas finales

Error temporal de red
Reintentar un número limitado de veces a intervalos determinados

Fallo de autenticación
No reintentar; detenerse de inmediato e indicar que se revise la configuración

Límite de uso de la API
Respetar las instrucciones de espera de la respuesta y prohibir los reintentos infinitos

Artículos duplicados
Eliminarlos según la URL normalizada y la similitud del título

Datos con formato incorrecto
Conservar el original y aislar únicamente el elemento afectado

Fallo en el envío del correo
Si sigue fallando tras los reintentos, emitir una notificación alternativa o registrar el estado de fallo

Éxito parcial
Informar por separado de los resultados correctos y de los elementos fallidos

La política puede solicitarse de forma concreta como se muestra a continuación.
Trata los tiempos de espera agotados de la red como errores que pueden reintentarse.
Deja un tiempo de espera entre los reintentos y, si se supera el número máximo,
marca como fallida únicamente la fuente afectada.
Detente de inmediato ante errores de autenticación y solicitudes incorrectas,
ya que repetirlas no resolverá el problema.

En todos los registros de errores, incluye la hora, la etapa del trabajo,
la fuente y el tipo de error, pero no registres la clave de API,
la dirección de correo electrónico completa, las cabeceras de autenticación
ni el texto íntegro de los artículos.
Distingue mediante el estado de finalización del proceso entre éxito total,
éxito parcial y fallo total.

Valores como reintentar tres veces o esperar 5 segundos no son respuestas universalmente correctas. Deben decidirse en el proyecto según los límites oficiales del servicio externo, la urgencia del trabajo y el riesgo de ejecuciones duplicadas. Las operaciones con efectos secundarios, como pagos o envíos de mensajes, pueden procesarse por duplicado si se reintentan automáticamente sin garantizar la idempotencia.

Principio 4. Desarrollar progresivamente siguiendo el orden de planificación, implementación mínima y validación
Si se conectan a la vez varios servicios externos y la ejecución automática, resulta difícil aislar la causa de los errores. Dividir la implementación en pequeñas unidades de validación permite comprobar las entradas y salidas de cada etapa.

Orden de trabajo recomendado

Investigar la estructura del repositorio, los archivos relacionados y los comandos de ejecución.
Pedir que se presente un plan y los archivos afectados antes de modificar el código.
Implementar la función de recopilación con una sola palabra clave y datos de muestra fijos.
Probar por separado la eliminación de duplicados y la clasificación del impacto.
Validar el correo electrónico mediante una vista previa local en lugar de enviarlo realmente.
Una vez superadas las pruebas, añadir la integración con el proveedor real y la ejecución programada.

La primera solicitud puede limitarse de la siguiente manera.
Por ahora, realiza únicamente la fase 1.
Investiga el repositorio e informa de lo siguiente:
- Punto de entrada de la aplicación actual
- Módulos y archivos de prueba relacionados
- Comandos de gestión de paquetes y pruebas utilizados
- Archivos que previsiblemente habrá que modificar
- Preguntas que deben resolverse antes de la implementación

No modifiques todavía ningún archivo.

Después de revisar el plan, se implementa reduciendo el alcance de los cambios.
Del plan aprobado, implementa únicamente la recopilación de noticias
y la eliminación de duplicados.
No añadas la clasificación, el envío de correos ni la ejecución programada.
Haz que pueda ejecutarse con datos de prueba fijos
y, al final, resume los archivos modificados y los resultados de las pruebas ejecutadas.

Si en el entorno de Claude Code puede utilizarse un modo dedicado exclusivamente a la planificación, se puede aprovechar durante las fases de exploración y diseño. Sin embargo, que el plan parezca convincente no significa que la implementación sea correcta, por lo que deben realizarse después pruebas reales y una revisión del código.

Principio 5. Comunicar los comentarios mediante casos de fallo y cifras
El resultado no es bueno, el rendimiento es lento o la clasificación es incorrecta no permiten decidir fácilmente la dirección de la corrección. Es necesario comunicar el estado actual, el estado esperado, la entrada con la que se reproduce el problema y el intervalo de cambios aceptable.

Solicitud para modificar la longitud
Actualmente, el cuerpo del correo se genera con unos 3,000 caracteres.
Quiero reducirlo a como máximo 500 caracteres para poder leerlo rápidamente
en un dispositivo móvil.
Limita el resumen de cada artículo a 1~2 frases y conserva el motivo de la decisión.
Vincula la URL original al título y elimina la línea de enlace independiente.
Mantén las estadísticas al final.

Solicitud para modificar los criterios de clasificación
De los 10 elementos de los datos de prueba, 8 se clasificaron como 'Alto'.
Clasifica como 'Bajo' las perspectivas tecnológicas a largo plazo
y las presentaciones generales de productos.
Clasifica como 'Alto' únicamente cuando existan pruebas concretas de que,
en un plazo de 3 meses, será necesario cambiar decisiones sobre precios,
hoja de ruta del producto, respuesta regulatoria o alianzas.

En los casos adjuntos, las respuestas correctas son Alto para A y B, y Bajo para C.
Modifica las reglas de clasificación y añade estos casos como pruebas de regresión.

Solicitud para modificar el rendimiento
El tiempo medio de ejecución con la misma entrada de muestra es actualmente
de unos 45 segundos.
El objetivo es que sea de como máximo 30 segundos en el mismo entorno.
Primero, mide el tiempo de cada etapa y muestra el cuello de botella.
No elimines la precisión de los resultados ni la gestión de errores;
compara el efecto y el riesgo de las alternativas de mejora
y aplica primero el cambio más pequeño.

Las cifras de rendimiento solo pueden compararse cuando el entorno de medición y los datos de entrada son los mismos. No debe concluirse que hubo una mejora basándose únicamente en el resultado de una ejecución; también deben fijarse el método de medición, la muestra y el estado de la caché.

Principio 6. Utilizar plantillas de prompt según el tipo de trabajo

Plantilla para crear un agente nuevo
[Función y situación]
Soy {profesión/función} y quiero resolver {situación problemática}.
Este resultado será utilizado por {usuario o sistema posterior}.

[Objetivo]
{Resultado que debe alcanzarse y criterios de éxito}

[Desencadenante de ejecución]
{Ejecución manual, evento, hora programada, etc.}

[Entrada]
- Fuente de datos: {archivo/API/base de datos}
- Campos obligatorios: {lista de campos}
- Método de autenticación: {variable de entorno o método de gestión de secretos}

[Lógica de procesamiento]
1. {Etapa 1}
2. {Etapa 2}
3. {Etapa 3}

[Contrato de salida]
{Formato de archivo, esquema, plantilla, reglas de ordenación y datos ausentes}

[Gestión de excepciones]
{Políticas para resultados vacíos, tiempos de espera agotados,
errores de autenticación y fallos parciales}

[Restricciones y no objetivos]
- Tecnologías que deben mantenerse: {elemento}
- Prohibiciones: {elemento}
- Funciones excluidas de este trabajo: {elemento}

[Validación]
- Pruebas que deben superarse: {elemento}
- Contenido que debe incluir el informe de finalización:
  archivos modificados, comandos ejecutados, resultados de las pruebas y riesgos restantes

Primero, investiga el repositorio y presenta un plan de implementación.
No deduzcas la información desconocida; haz preguntas.

Plantilla para añadir una función existente
Añade {nueva función} al {nombre del agente o módulo} existente.
La función nueva debe ejecutarse después de {etapa existente A}
y antes de {etapa existente B}.

Lógica detallada:
- {Condiciones y reglas de procesamiento}
- {Formato de entrada y salida}
- {Comportamiento en caso de fallo}

Condiciones que deben mantenerse:
- No modificar la interfaz pública ni el formato de configuración existentes.
- Mantener todas las pruebas existentes.
- No modificar archivos que no estén relacionados.

Primero, explica el alcance del impacto y el riesgo de regresión.
Después, añade pruebas que conserven el comportamiento existente e implementa la función.

Plantilla para corregir un error
Reproduce el siguiente error y corrige su causa raíz.

Mensaje de error completo:
{Mensaje de error y seguimiento de pila del que se han eliminado
los datos secretos y la información personal}

Condiciones en las que se produce:
- Comando de ejecución: {comando}
- Entrada: {entrada mínima de reproducción}
- Entorno: {sistema operativo, runtime, versiones relacionadas}
- Momento en que se produce: {en qué etapa}

Comportamiento esperado:
{Resultado que debería aparecer si funcionara correctamente}

Comportamiento real:
{Resultado observado actualmente}

Solicitud:
1. Primero, reproduce el error.
2. Explica la causa basándote en pruebas.
3. Corrígelo con el menor alcance posible.
4. Añade una prueba de regresión que evite el mismo error.
5. Informa de las pruebas ejecutadas y de los riesgos restantes.

Al pegar mensajes de error, deben eliminarse los datos sensibles, como claves de API, tokens de sesión, datos de clientes y direcciones internas.

Ejemplo completo: solicitud de un agente de boletines de noticias
El siguiente ejemplo combina los seis principios en una sola solicitud.
Soy responsable de desarrollo de negocio en una startup de SaaS.
Quiero consultar cada día únicamente las noticias sobre cambios en los mercados
de la IA, la nube y las fintech que puedan modificar decisiones
sobre productos o alianzas en un plazo de 3 meses.

Investiga el repositorio actual y diseña una herramienta de boletines de noticias.
En la primera fase, implementa únicamente la función de leer un JSON de muestra,
eliminar duplicados, clasificar el impacto y crear un archivo HTML de vista previa.
La búsqueda web, el envío real de correos electrónicos y la ejecución programada
quedan excluidos de esta fase.

Campos de entrada:
- title, url, source, published_at, body

Reglas de procesamiento:
- Si las URL normalizadas son iguales, se consideran duplicados.
- Aunque las URL sean distintas, si los títulos son similares,
  se marcan como posibles duplicados.
- Clasifica como impacto 'Alto' únicamente los artículos que requieran
  un cambio concreto en un plazo de 3 meses respecto a precios,
  respuesta regulatoria, hoja de ruta del producto o decisiones sobre alianzas.
- Si no hay pruebas suficientes, no supongas una calificación alta.

Salida:
- Mostrar el título, un resumen de 1~2 frases, el impacto,
  el motivo de la decisión, la fuente y la URL.
- Ordenar de mayor a menor impacto.
- Mostrar al final el número total, el número de duplicados eliminados
  y el número de elementos por nivel.

Gestión de excepciones:
- No excluir los elementos sin campos obligatorios;
  registrarlos en una lista de errores independiente.
- No estimar las fechas incorrectas y mantenerlas como null.
- No dejar en los registros el cuerpo íntegro de los artículos
  ni la información de autenticación.

Validación:
- Probar entradas normales, entradas vacías, URL duplicadas,
  fechas incorrectas y ausencia de campos obligatorios.
- Si existen pruebas anteriores, todas deben superarse.

Orden de trabajo:
1. Investigar la estructura del repositorio y los archivos relacionados.
2. Presentar los archivos que se modificarán y el plan de pruebas.
3. No modificar el código antes de que yo revise el plan.
4. Tras la aprobación, implementar la función mínima e informar
   de los resultados de las pruebas.

Esta solicitud no exige desplegar de una sola vez todas las funciones en el entorno operativo. Su alcance es limitado y define conjuntamente el significado de la salida, la gestión de fallos y los elementos de prueba, lo que facilita evaluar el resultado.

Criterios de calidad fáciles de pasar por alto si solo se usa el prompt
Muchas guías de programación por vibraciones se centran en redactar instrucciones más detalladas. Sin embargo, los elementos adicionales que determinan la calidad real son la capacidad de validación, el control de cambios, la observabilidad y los límites de seguridad.

1. Convertir los criterios de aceptación en pruebas
En lugar de Haz que funcione bien, deben proporcionarse pares de entradas y salidas esperadas. Los casos de clasificación importantes deben conservarse como pruebas de regresión para comprobar que los resultados se mantengan también en cambios posteriores.

2. No utilizar la autoevaluación del agente como prueba definitiva
Que el agente diga He terminado no es lo mismo que haber superado las pruebas. Se le debe pedir que informe de los comandos ejecutados, los resultados de las pruebas, los archivos modificados y los riesgos no resueltos, y una persona debe revisar el diff.

3. Minimizar los permisos y la información secreta
No deben proporcionarse de una sola vez directorios innecesarios, bases de datos de producción ni credenciales de despliegue. Las claves de API no deben introducirse directamente en el prompt o el repositorio; deben utilizarse variables de entorno o un sistema aprobado de gestión de secretos. No deben concederse permisos de acceso a repositorios sensibles a servidores MCP o scripts de origen desconocido.

4. Exigir código observable
En los trabajos automatizados debe conservarse la información necesaria para localizar la causa de los fallos, como el estado de cada etapa, los errores estructurados, el tiempo de ejecución y el número de elementos procesados. Por el contrario, la información de autenticación y los datos personales deben eliminarse de los registros.

5. Hacer que los cambios puedan revertirse
No deben mezclarse refactorizaciones no relacionadas y funciones adicionales en un mismo cambio. Revisar el diff en unidades pequeñas y registrarlo en el control de versiones facilita aislar y revertir los cambios incorrectos.

Consejos para gestionar proyectos con Claude Code

Registrar en CLAUDE.md las reglas recurrentes del proyecto de forma breve y concreta.
Proporcionar los comandos de compilación, pruebas y lint en una forma que pueda ejecutarse realmente.
No incluir en CLAUDE.md información secreta, registros de errores puntuales ni documentos de referencia extensos.
Antes de realizar cambios a gran escala, pedir que se investiguen los archivos relacionados y sus dependencias.
Al añadir un paquete nuevo, revisar su necesidad, licencia y riesgos de mantenimiento.
No aprobar automáticamente comandos peligrosos de eliminación, despliegue o modificación de datos.
Antes de conectar una API externa o MCP, comprobar adónde se transmiten los datos.
Al finalizar, pedir un resumen de los archivos modificados, los comandos ejecutados, los resultados de las pruebas y las limitaciones restantes.

Lista de comprobación previa al envío

 ¿Se han explicado el usuario y la situación de uso?
 ¿Se han separado los objetivos y los no objetivos?
 ¿Se han especificado las tecnologías existentes y el alcance que no debe modificarse?
 ¿Se han definido los datos de entrada y el formato de salida?
 ¿Se ha explicado el significado de los valores de clasificación y de estado?
 ¿Existen políticas para resultados vacíos, fallos de autenticación, tiempos de espera agotados y fallos parciales?
 ¿Se han separado la planificación y la implementación por etapas?
 ¿Existen pruebas para casos normales, límite y de fallo?
 ¿Se excluyen la información secreta y los datos personales del prompt y los registros?
 ¿Se han solicitado un diff para revisión humana y pruebas de ejecución?

La clave de un buen prompt para Claude Code no consiste en escribir instrucciones largas. Consiste en reducir lo que el agente debe deducir y hacer posible que un tercero también pueda reproducir y determinar si el resultado es correcto.

FAQ
Q. ¿Cuanto más largo sea el prompt de Claude Code, mejor?
A. Más que la longitud, lo importante es que la información necesaria para la tarea esté incluida de forma estructurada. Conviene especificar claramente el contexto, el objetivo, las restricciones, el contrato de salida, el manejo de excepciones y los criterios de finalización, pero eliminar las explicaciones irrelevantes y las instrucciones redundantes.
Q. ¿No se le puede pedir que cree el programa completo desde el principio?
A. Es posible si se trata de una herramienta pequeña e independiente, pero es más seguro desarrollar por etapas las tareas que combinan una API externa, una base de datos, correo electrónico y ejecución programada. Si primero se revisan el repositorio y el plan, y después se amplía en el orden de funcionalidad mínima, pruebas e integración externa, resulta más fácil aislar las causas de los fallos.
Q. ¿Se pueden omitir las pruebas si se utiliza Plan Mode?
A. No. El modo de planificación es útil para revisar la estructura y el enfoque antes de realizar cambios, pero no demuestra la corrección del código real. Después de la implementación, deben realizarse por separado pruebas automatizadas, análisis estático, revisión de los cambios y las comprobaciones manuales necesarias.
Q. ¿Qué se debe escribir en CLAUDE.md?
A. Es apropiado incluir instrucciones que se repiten en distintas tareas, como la estructura del proyecto, las normas de codificación, los comandos de compilación y prueba, y las áreas que no deben modificarse. Es mejor no incluir claves de API, contraseñas, información personal, descripciones de tareas puntuales ni materiales de referencia excesivamente extensos.
Q. ¿Qué información se debe proporcionar al solicitar la corrección de un error?
A. Se deben proporcionar conjuntamente el mensaje de error y el seguimiento de la pila sin información sensible, el comando de ejecución, los datos mínimos para reproducir el problema, el entorno pertinente, el comportamiento real y el comportamiento esperado. También conviene solicitar una explicación de la causa, una corrección de alcance mínimo, pruebas de regresión y los resultados de la ejecución.
Q. ¿Se puede proporcionar una clave de API a Claude Code mediante un prompt?
A. Por principio, no se deben escribir claves de API reales directamente en el prompt ni en el código fuente. Se deben utilizar variables de entorno aprobadas o sistemas de gestión de secretos, y evitar que las credenciales queden expuestas también en los registros y los resultados de las pruebas.
Q. ¿Es obligatorio indicar en el prompt el número de reintentos y el tiempo de espera?
A. En la automatización operativa es importante distinguir entre los errores que permiten reintentos y los que requieren una interrupción inmediata. Sin embargo, el número concreto de reintentos y el tiempo de espera deben decidirse tras comprobar las limitaciones del servicio externo, la urgencia de la tarea y el riesgo de procesamiento duplicado; no se deben reintentar incondicionalmente todos los errores.
Q. ¿Cómo se determina si el código generado está completo?
A. Se determina en función de los criterios de aceptación definidos previamente. Se debe comprobar si se han superado las pruebas de las funciones obligatorias y los casos excepcionales, los comandos ejecutados, los archivos modificados y el cumplimiento de las restricciones de rendimiento o seguridad, y una persona debe revisar los cambios del código.

Sources
- Descripción general de Claude Code: https://docs.anthropic.com/en/docs/claude-code/overview
- Claude Code: mejores prácticas para la programación agéntica: https://www.anthropic.com/engineering/claude-code-best-practices
- Repositorio de GitHub de Anthropic Claude Code: https://github.com/anthropics/claude-code

Images
- Desarrollador trabajando frente a un monitor grande con código y un diagrama de flujo: https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTExNTQsInB1ciI6ImJsb2JfaWQifX0=--9f2d2e2c8a61fc294a6019e4807ece297f36e85a/ai-4caeb237.webp
- Portátil con editor de código conectado a requisitos, tablas, errores, versiones y gráficos de rendimiento: https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTExNjAsInB1ciI6ImJsb2JfaWQifX0=--285d7ecdc8209e07e0fc4eb68085cd8a304b9a81/ai-062b34c5.webp

---
Category: Tutorial
Source: https://injoys.com/es/articles/claude-code-prompt-six-principles-and-templates
License: cc_by
Translation-Status: reviewed