Indicaciones de Claude Code: 25 indicaciones listas para copiar y cómo escribir las tuyas propias

Los clientes que utilicen un cupón caducado reciben un error 500 al finalizar la compra. Revisa @src/checkout/coupons.ts y sus pruebas. El comportamiento esperado es que aparezca un mensaje de «cupón no válido» sin que se cree un pedido. Escribe una prueba que falle y que reproduzca el error; a continuación, corrígelo sin modificar el comportamiento de los cupones válidos. Ejecuta [comando de prueba de pago] y muestra los resultados antes y después. Si no puedes reproducir el error, informa de lo que has comprobado antes de modificar la implementación.

Añade un selector de fechas a [ruta del formulario de reserva]. Sigue las convenciones de componentes y validación de @src/components/TimeSelect.tsx. Los usuarios deben poder seleccionar [fechas permitidas], mientras que [las fechas no disponibles] deben permanecer desactivadas. No añadas bibliotecas. Ejecuta [comando de prueba de componentes] y [comando de comprobación de tipos], e informa de cualquier criterio que no cubran dichas comprobaciones.

Divide el archivo @src/reports/export.py en funciones más pequeñas, conservando sus entradas, el formato de salida y el comportamiento ante errores. Ejecuta [comando de prueba de exportación] antes de la edición y notifica cualquier fallo existente. Tras la refactorización, vuelve a ejecutar las pruebas y muestra ambos resultados. No modifiques la interfaz pública ni los archivos no relacionados.

«Claude comprueba cada uno de los cambios que incorporo a claude.ai/code mediante la extensión de Claude para Chrome. Abre un navegador, comprueba la interfaz de usuario y repite el proceso hasta que el código funciona y la experiencia de usuario es satisfactoria. »

Examina el archivo README, la configuración del proyecto y la estructura de directorios de nivel superior de este repositorio. Sigue las referencias solo en la medida en que sean necesarias para explicar: qué hace la aplicación; sus puntos de entrada principales y componentes clave; dónde se encuentran las pruebas y qué comandos define el repositorio para ejecutarlas. Cita las rutas de los archivos que respalden tu explicación. Distingue el comportamiento documentado de tus propias deducciones y señala cualquier aspecto que no puedas determinar. No leas archivos secretos ni de entorno, no revises las dependencias instaladas ni modifiques ningún archivo. Termina indicando los tres archivos que deberías leer primero y por qué.

Revisa el historial de Git de [archivo, función o clase], centrándote en [comportamiento o cuestión de diseño]. Identifica las confirmaciones que introdujeron o modificaron sustancialmente este comportamiento. Para cada confirmación relevante, indica su hash, resumir el cambio y explica cualquier justificación documentada en el mensaje de la confirmación o en la discusión enlazada a la que puedas acceder. Etiqueta las razones deducidas como «inferencias». Si el historial no explica una decisión, indícalo. No modifiques archivos ni el historial de Git.

Rastrea lo que ocurre cuando se produce [una acción del usuario o un evento del sistema], comenzando en [una ruta, un controlador o una carpeta conocidos]. Sigue las llamadas relevantes a través de la validación, la lógica de negocio y cualquier escritura en la base de datos o solicitud externa. Lista los archivos y las funciones en orden de ejecución, con referencias de línea cuando sea posible. Explica las principales rutas de fallo e identifica las pruebas existentes que cubren el flujo. Marca cualquier conexión que no puedas confirmar a partir del código. No ejecutes el flujo, no llames a servicios externos ni realices ediciones en archivos.

Planifica cómo implementar [función] en [área del repositorio]. El comportamiento esperado es [requisitos], y estas áreas deben permanecer inalteradas: [restricciones]. Examina el código pertinente y las pruebas existentes. Identifica los archivos que deben modificarse, el orden de implementación y cualquier riesgo de compatibilidad o de migración de datos. Correlaciona cada requisito con una prueba propuesta u otro paso de verificación. Enumera por separado las cuestiones sin resolver y las suposiciones. No implementes la función todavía. Envíame el plan para que lo revise.

Quiero crear [breve descripción] para [usuarios y caso de uso]. Lee primero [archivos o requisitos relevantes] y, a continuación, utiliza AskUserQuestion para aclarar las decisiones que podrían afectar de manera significativa a la implementación. Céntrate en los casos extremos, el manejo de datos, los permisos, el comportamiento esperado de la interfaz de usuario y las compensaciones. No hagas preguntas cuya respuesta ya se encuentre en el contexto proporcionado. Una vez resueltas las decisiones clave, redacta un borrador de especificación que abarque los requisitos, los criterios de aceptación, las restricciones y lo que queda fuera del alcance. Señala cualquier suposición pendiente. Muéstrame la especificación antes de guardarla en [ruta de la especificación] y no sobrescribas ningún archivo existente sin autorización.

Evalúa el impacto de cambiar [función, componente o interfaz] de [comportamiento actual] a [comportamiento propuesto]. Busca en [el ámbito del repositorio o del directorio] su definición, las llamadas directas, las importaciones y las pruebas relacionadas. Crea una lista de los archivos que probablemente necesiten cambios y explica cómo podría verse afectado cada uno, con referencias a los archivos y las líneas cuando sea posible. Señala las llamadas resueltas dinámicamente, los consumidores externos u otras dependencias que no puedas verificar. Identifica cualquier cuestión de compatibilidad que requiera una respuesta antes de la implementación. No modifiques los archivos; envía la evaluación de impacto y espera a que la revise.

Añade [función] a [archivo o página] con este comportamiento: [criterios de aceptación]. Examina la [implementación existente] y sigue sus convenciones a la hora de capturar datos, gestionar errores y organizar componentes. Utiliza únicamente bibliotecas que ya estén instaladas en el proyecto. Mantén los cambios dentro del [alcance] y conserva el [comportamiento existente o la interfaz pública]. Añade o actualiza pruebas para los criterios de aceptación. Ejecuta el [comando de prueba] y el [comando de comprobación de tipos o lint], y a continuación informa de los archivos modificados, los resultados y cualquier comprobación que no hayas podido completar. Si el patrón existente entra en conflicto con un requisito, explica el conflicto antes de continuar.

Implementa [nombre de la función] en [archivo] para cumplir con [requisitos]. Cubre el [caso normal], el [caso límite] y el [comportamiento ante entradas no válidas]. Ejecuta primero el [comando de prueba pertinente] y realiza la elaboración de informes sobre cualquier fallo existente. Escribe pruebas para el comportamiento solicitado y, a continuación, ejecútalas antes de la implementación. Confirma que las nuevas pruebas fallan por el motivo esperado. Implementa la función y vuelve a ejecutar las pruebas. No debilites las aserciones, no te saltes pruebas ni cambies el comportamiento esperado para que pasen. Si los requisitos entran en conflicto con las pruebas existentes, detente y explica el conflicto. Muestra los resultados antes y después.

Implementa el diseño adjunto en [componente o página], utilizando los componentes y estilos existentes del proyecto. Mantén [el comportamiento requerido] y evita cambios fuera del [alcance]. Utiliza [el navegador configurado o la herramienta de captura de pantalla] para capturar [la ruta local] con [las dimensiones de la ventana de visualización] y [los datos de prueba y el estado de la interfaz de usuario]. Si la herramienta o la aplicación no están disponibles, indica lo que se necesita en lugar de limitarte a afirmar que se ha realizado una comprobación visual. Compara la captura con la referencia, centrándote en [el diseño, el espaciado, la tipografía u otros criterios de aceptación]. Realiza hasta [número] rondas de correcciones y, a continuación, informa de las diferencias restantes. No modifiques la imagen de referencia. Ejecuta [las pruebas de componentes pertinentes] y [el comando de comprobación de tipos o de compilación]. Incluye la captura de pantalla y los resultados reales de la comprobación en tu resumen.

Los usuarios experimentan [síntoma] cuando [desencadenante o entrada]. El comportamiento esperado es [resultado esperado]. Empieza por inspeccionar [carpeta, función o flujo] y las pruebas relacionadas. Crea una prueba fallida que reproduzca el comportamiento notificado. Si no puedes reproducirlo, explica qué has comprobado y qué información falta antes de modificar la implementación. Una vez reproducido, corrige la causa sin alterar [el comportamiento que debe permanecer intacto]. Ejecuta la nueva prueba y [comando de prueba relacionado]. Muestra el fallo antes de la corrección, los resultados posteriores y cualquier fallo restante.

El [comando de compilación] falla en [entorno local o de CI] con este resultado: [registro de errores depurado]. Revisa el código y la configuración pertinentes para identificar la causa. Comprueba si hay diferencias en el entorno o en las dependencias si el fallo no se reproduce localmente. Realiza el cambio más pequeño posible que solucione la causa. No desactives las comprobaciones, suprima errores, te saltes pruebas ni relajes los ajustes del compilador simplemente para conseguir que la compilación pase. Vuelve a ejecutar la compilación tras el cambio. Si sigue fallando tras [número] intentos de corrección, detente e informa de lo que has intentado, del error actual y del siguiente paso de diagnóstico. Resumir la causa y incluye el resultado real de la compilación.

Ayúdame a delimitar un error antes de proponer una solución. Comportamiento observado: [qué ocurre] Comportamiento esperado: [qué debería ocurrir] Cuándo ocurre: [condiciones o frecuencia] Lo que he probado: [pasos y resultados] Haz una pregunta cada vez, eligiendo aquella que mejor distinga entre las posibles causas. No repitas preguntas que ya hayan sido respondidas con la información facilitada. Una vez que haya pruebas suficientes, resume la explicación más probable, lo que sigue siendo incierto y la prueba más sencilla que podría confirmarla o descartarla. No realices ediciones en los archivos todavía.

Utiliza un subagente para revisar [las diferencias o la rama comparada con la base] frente al [plan aprobado o el archivo de requisitos]. Si faltan requisitos o estos son ambiguos, informa de ello antes de evaluar la integridad. Comprueba si se ha implementado cada requisito, si los casos límite relevantes cuentan con pruebas y si algún cambio queda fuera del alcance acordado. Examina el código circundante cuando sea necesario para comprender la diferencia. Informa de los problemas de corrección y de los requisitos no cumplidos con referencias a archivos y líneas, su impacto y las pruebas que respaldan cada hallazgo. Separa los problemas confirmados de las cuestiones sin resolver. No inventes hallazgos para cumplir una cuota ni incluyas preferencias de estilo que no tengan relación. No realices ediciones en archivos.

Revisa [archivos o diferencias] en busca de riesgos de inyección, comprobaciones de autorización ausentes, secretos expuestos y un manejo inseguro de las entradas del usuario. Inspecciona las llamadas relevantes y la lógica de validación antes de elaborar un informe sobre un problema. Para cada problema, identifica el archivo y las líneas afectadas, las condiciones necesarias para que se produzca, el impacto probable y una solución sugerida. Distingue entre una ruta vulnerable confirmada y una posible incidencia que requiera más pruebas. No reproduzcas valores confidenciales en el informe, no modifiques archivos ni realices pruebas en servicios en producción. Indica qué áreas has revisado y qué queda fuera del alcance.

Resumir cómo has verificado la modificación completada con respecto a los [criterios de aceptación]. Para cada criterio, enumera la comprobación realizada, el comando exacto (si procede) y el resultado observado. Incluye la salida relevante, ocultando los datos confidenciales y sensibles. Identifica por separado cualquier fallo preexistente. Distingue claramente entre las comprobaciones que han pasado, las que han fallado y las que no se han ejecutado. Explica cualquier comprobación omitida o cualquier límite en la cobertura. No describas el cambio completo como verificado si quedan criterios sin comprobar.

Reestructura [archivo o módulo] con la [meta específica, como dividir una función grande o eliminar llamadas de retorno anidadas]. Conserva su interfaz pública, los valores de retorno, el comportamiento ante errores y los efectos secundarios. Ejecuta [el comando de prueba pertinente] antes de la edición para establecer una referencia. Si falla, informa de los fallos antes de continuar. Identifica cualquier comportamiento que las pruebas existentes no cubran y añade pruebas específicas donde sea necesario. Realiza la reestructuración sin cambios ajenos al objetivo ni nuevas dependencias. No debilites las aserciones existentes para adaptarlas a la implementación. Vuelve a ejecutar las pruebas y [comando de comprobación de tipos o lint]. Muestra los resultados antes y después, resume los cambios estructurales y señala cualquier comportamiento que no hayas podido verificar.

Busca usos de [API o biblioteca antigua] dentro del [ámbito del directorio], excluyendo los archivos generados y de terceros. Lista los archivos afectados y cualquier configuración compartida o dependencia que la migración pueda afectar. Propone tres archivos representativos para una migración piloto a [nueva API o versión], utilizando [la guía de migración o un ejemplo existente]. Explica por qué los has seleccionado y señala cualquier cambio de comportamiento necesario. Espera a mi aprobación antes de realizar ediciones. Una vez aprobada, migra únicamente los archivos piloto y las dependencias compartidas que se hayan aprobado explícitamente. Ejecuta [las pruebas pertinentes] y [el comando de compilación o de comprobación de tipos]. No amplíes la migración a otros archivos. Informa de las diferencias, los resultados de las pruebas, los problemas de compatibilidad y cualquier cambio necesario en el enfoque de la migración. Detente para realizar una revisión antes de continuar con los archivos restantes.

Revisa la rama actual, el estado de Git y las diferencias de [función o corrección]. Identifica los archivos que pertenecen a este cambio y elabora una lista por separado de los archivos no relacionados o no controlados. Redacta un mensaje de commit siguiendo el formato de los últimos 10 commits. Prepara una descripción de la solicitud de validación que incluya qué ha cambiado, por qué, las pruebas que se han ejecutado realmente y cualquier limitación restante. Muestra la lista de archivos propuesta, el mensaje de commit y la descripción de la solicitud de incorporación de cambios antes de preparar o publicar nada. Espera a mi aprobación. Tras la aprobación, prepara únicamente los archivos acordados, realiza el commit en [rama de características], envía a [remoto] y abre una solicitud de validación contra [rama base]. No modifiques commits existentes, no realices envíos forzados ni combinaciones. Envía el hash del commit y el enlace a la solicitud de validación.

Redacta una sección README para [módulo] dirigida a [lector, como un ingeniero de backend que se incorpore al proyecto]. Incluye los requisitos previos, la configuración, los tres comandos que más utilizarán y los errores comunes que tienen compatibilidad con el código o con la documentación existente. Verifica los nombres de los comandos y las opciones comparándolos con [los scripts del paquete, el Makefile, la ayuda de la CLI o la configuración de CI]. Señala cualquier elemento que no puedas confirmar. Prueba los comandos locales seguros en [entorno de pruebas], si está disponible. Antes de ejecutar comandos que instalen dependencias, eliminen archivos, migren datos, realicen implementaciones o accedan a servicios externos, explica sus efectos y solicita autorización. Distingue claramente los comandos que has ejecutado con éxito de los que solo has comprobado con respecto a la configuración o la documentación. Muestra la sección README propuesta antes de realizar la edición de [ruta de la documentación] y conserva el contenido no relacionado.

Revisa [ruta a CLAUDE.md] comparándola con la estructura, los scripts y las convenciones actuales del repositorio. No realices edición en el archivo todavía. Identifica instrucciones obsoletas, duplicados, contradicciones y reglas que puedan deducirse de forma fiable a partir del código. Explica cada eliminación propuesta en lugar de suprimir comandos únicamente para acortar el archivo. Sugiere comandos de compilación o prueba que falten solo cuando puedas verificarlos en los scripts del proyecto, un Makefile, la configuración de CI o la documentación existente. Cita la fuente de cada adición. Envía un diff propuesto que preserve las restricciones importantes del proyecto. Marca las instrucciones específicas de una tarea que encajarían mejor en una habilidad o en una regla con ámbito de ruta, y espera a que se aprueben antes de aplicar los cambios.

Propón un gancho de comando de Claude Code que ejecute [comando del formateador existente] tras realizar cambios de «Editar» o «Escribir» en [patrones de archivo]. Revisa primero los ajustes existentes en claude/settings.json y la configuración del formateador. Utiliza la configuración PostToolUse adecuada para la versión instalada de Claude Code. Formatea solo el archivo afectado, gestiona las rutas de forma segura y excluye [archivos generados u otras rutas excluidas]. No instales dependencias ni sustituyas los hooks existentes. Muestra las diferencias entre los ajustes propuestos y explica cómo se notificarán los errores del formateador. Espera a que se apruebe antes de aplicarlo. Tras la aprobación, pruébalo con un archivo temporal del proyecto e informa del resultado. Indica qué rutas de edición cubre y cuáles no, incluyendo los cambios realizados mediante comandos de shell.

Consulta [herramienta] –help y la ayuda de los subcomandos relevantes para [tarea]. No instales la herramienta si falta; en su lugar, informa de ese requisito previo. Propón los comandos exactos necesarios para completar la tarea. Explica sus entradas, salidas y si escriben en archivos, modifican recursos remotos o utilizan credenciales. Incluye una opción de simulación si la herramienta la documenta. Señala cualquier configuración o permiso que falte y pide aclaraciones en lugar de adivinar nombres de recursos o destinos. Espera a recibir la aprobación antes de ejecutar los comandos de la tarea. Tras la aprobación, ejecuta únicamente los comandos acordados e informa de sus resultados reales, incluyendo cualquier error o paso incompleto.

Compara [invoices.csv] y [pagos.csv] utilizando [el ID de la factura o la clave de coincidencia]. No modifiques los archivos de origen. Aplica estas reglas: [moneda y tolerancia de redondeo], [asignación de pagos parciales] y [gestión de devoluciones, créditos y pagos en exceso]. Si falta una regla o una coincidencia es ambigua, márcala en lugar de asignar el pago automáticamente. Conserva los ID de las filas de origen. Para cada factura, muestra el importe facturado, los pagos aplicados y el saldo restante. Informa de los ID duplicados, las facturas sin emparejar, los pagos sin emparejar y los saldos fuera de la tolerancia. Concilia los totales de las facturas y los pagos por separado. contabiliza cada fila de origen sin contar dos veces; si un pago se divide entre varias facturas, muestra cada asignación y confirma que las asignaciones no superan el importe del pago. Guarda los resultados en [nuevas rutas de salida] y resume las excepciones que requieran revisión.

Escribe un script que resuma [export.csv] desde [fecha de inicio y hora, ambas incluidas] hasta [fecha de finalización, ambas excluidas], utilizando [zona horaria] y [columna de fecha]. Agrupa los registros según [reglas de categoría] y calcula [métricas requeridas]. Gestiona los ID duplicados y los valores que faltan de acuerdo con [reglas]. No modifiques el archivo de entrada. Ejecuta el script en [archivo de entrada exacto]. Indica el número de filas incluidas y excluidas, los totales por categoría y los registros que no se han podido clasificar. Compara los resultados de [tres categorías] con los recuentos verificados de forma independiente en [archivo de referencia]. Si dichos recuentos no están disponibles, indica que la validación independiente sigue pendiente. Muestra las discrepancias y guarda el informe en [nueva ruta de salida].

Lee [los archivos o la carpeta especificados] y redacta un [tipo y extensión del documento] dirigido a [público destinatario], que aborde [preguntas o temas]. Respalda cada afirmación factual con el nombre del archivo y una referencia a la página, sección o línea, cuando sea posible. Distingue las citas directas de las paráfrasis, y no trates una propuesta o un documento obsoleto como una decisión actual confirmada. Señala las fuentes contradictorias, la información que falte y las afirmaciones que no puedas verificar. No rellenes los huecos con suposiciones ni realices ediciones en los archivos originales. Entrega el borrador con sus referencias y una breve lista de cuestiones sin resolver para el revisor.

Para adaptar una plantilla, sustituye sus marcadores de posición por los datos de tu proyecto y decide qué debe hacer Claude antes de realizar los cambios. Sigue estos pasos para preparar la solicitud y revisar el resultado.

Para un cambio pequeño y bien definido, puedes pedirle a Claude que lo implemente directamente. En el caso de código desconocido, cambios que afecten a varios archivos o requisitos sin resolver, empieza por elaborar un plan.

Pulsa Mayús+Tab hasta que aparezca el modo Plan, o inicia Claude Code con el comando claude --permission-mode plan. En este modo, Claude puede inspeccionar archivos y ejecutar comandos de solo lectura sin realizar edición en tu código fuente. Revisa los archivos, las dependencias y las pruebas propuestos antes de aprobar la implementación. Pulsa Ctrl+G para abrir el plan propuesto en tu editor.

Proporciona a Claude la información necesaria para comprender la tarea: una referencia de archivo, un registro de errores depurado, una captura de pantalla o un documento de requisitos. Utiliza @ seguido de la ruta del archivo para incluir su contenido.

Elige el conjunto más reducido posible de fuentes. Incluir un registro o un directorio completo puede añadir material irrelevante y restar contexto. Elimina las credenciales y los datos confidenciales antes del uso compartido de los registros, y comprueba que Claude dispone de las herramientas necesarias para recuperar cualquier URL de documentación que le facilites.

Por ejemplo, «cat error.log | claude -p "Explica este error"» envía un registro mediante una solicitud no interactiva. Úsalo solo después de comprobar el contenido del archivo. Este es el valor práctico de la IA contextual: proporcionar al modelo información relevante para la tarea.

Al añadir una función, identifica un componente o una función similar en el repositorio. Indica a Claude qué convenciones debe seguir, como el cliente de la API, la lógica de validación, la gestión de errores o la estructura de pruebas.

«Sigue cómo @src/widgets/Weather.tsx captura y almacena datos en caché» proporciona a Claude una referencia concreta. Indica también cualquier diferencia que requiera la nueva función para que no copie un comportamiento que ya no sea adecuado. Estas convenciones deben reflejar el flujo de trabajo de desarrollo de software de tu equipo.

Para cambios en el código, especifica el comando de prueba, compilación o lint correspondiente y el comportamiento que debe comprobar. Para la investigación, solicita referencias de archivos o ID de confirmación. Para el trabajo en la interfaz de usuario, proporciona una imagen de referencia y una forma configurada de capturar la implementación en la misma ventana gráfica.

Pídele a Claude que te informe de lo que ha comprobado realmente, incluyendo los fallos y las comprobaciones omitidas. Comprueba si las pruebas demuestran que se cumple el requisito; el hecho de que la compilación se haya superado no garantiza que todos los comportamientos solicitados funcionen.

Para tareas más largas, Claude Code también ofrece una condición /goal y «hooks» de parada. El evaluador de metas valora las pruebas que surgen en la conversación, en lugar de inspeccionar archivos de forma independiente o ejecutar pruebas. Un «hook» de parada configurado puede bloquear la finalización, pero tiene límites en cuanto al bloqueo repetido. Ninguno de los dos sustituye a las pruebas adecuadas ni a la revisión humana.

Si las correcciones repetidas no resuelven un problema, detente e identifica qué aspecto de la solicitud original no quedó claro. Guarda los hallazgos útiles, el estado actual de Git y el trabajo pendiente antes de borrar la conversación.

La guía de buenas prácticas de Anthropic recomienda empezar de cero tras dos correcciones fallidas sobre el mismo problema. Utiliza /clear y, a continuación, proporciona una indicación revisada que incluya lo que has aprendido. Borrar la conversación no deshace los cambios realizados en los archivos.

Pulsa Esc para interrumpir una respuesta en ejecución. Con la indicación de entrada vacía, pulsa Esc dos veces para abrir el menú de rebobinado y elige qué restaurar. El rebobinado no deshace todos los efectos externos, así que utiliza puntos de control de Git y procedimientos de recuperación independientes para los cambios en bases de datos o servicios remotos.

Guarda las directrices para todo el proyecto en CLAUDE.md, los procedimientos repetibles en «skills» y las instrucciones para archivos concretos en reglas con ámbito de ruta. Utiliza «hooks» para acciones vinculadas a eventos específicos, como ejecutar un formateador tras una edición.

Elige en función de cuándo debe aplicarse la instrucción:

Los requisitos de una función suelen pertenecer a la indicación de la tarea o a la especificación correspondiente, más que al archivo CLAUDE.md. Añadir instrucciones temporales a un archivo que abarca todo el proyecto hace que resulten más difíciles de distinguir de las convenciones que deben aplicarse en todo el repositorio.

Por ejemplo, mantén el comando de prueba del proyecto en CLAUDE.md, incluye las convenciones específicas de cada componente en una regla con ámbito de ruta y guarda un procedimiento de revisión recurrente como una «skill». Revisa estos archivos cuando cambien los comandos o las convenciones, tal y como harías con el resto de la documentación del proyecto.

Las indicaciones, el archivo CLAUDE.md y las habilidades guían el comportamiento de Claude; no garantizan que se siga una instrucción. Los hooks pueden ejecutar comprobaciones en eventos configurados, pero su fiabilidad depende del tipo de hook y de su implementación.

Un gancho de comando ejecuta un script. Un gancho de indicación o de agente se basa en el juicio de un modelo. Tal y como explica la guía de buenas prácticas de Anthropic: «Un gancho de indicación o de agente pide a otro modelo que decida, por lo que tampoco es determinista». Para una regla que deba aplicarse, utiliza controles de permisos adecuados y prueba el comando o gancho HTTP correspondiente, incluyendo cómo gestiona los fallos.

Los subagentes personalizados son otra forma de organizar el trabajo recurrente. Define un especialista en claude/agents/ cuando se necesite un rol de revisión específico o un ámbito de herramientas concreto, en lugar de añadir cada instrucción especializada a la sesión principal. Estas guías sobre el mejor modelo de Claude para el trabajo y los tipos de agentes de IA proporcionan contexto adicional.

Si tu equipo gestiona indicaciones en varios productos de IA, echa un vistazo a estas herramientas de ingeniería de indicaciones para gestionar bibliotecas más allá de Claude Code.

Cuando una sesión produce un resultado incompleto o inadecuado, comprueba si la solicitud dejó sin resolver decisiones importantes. Estos cinco errores pueden dificultar el diagnóstico y la revisión del trabajo.

La indicación «Investiga el repositorio» ofrece a Claude muy poca orientación sobre qué archivos son relevantes o cuándo debe detenerse. Es posible que recibas un resumen general sin una respuesta al problema que motivó la solicitud.

Nombra el comportamiento o la decisión que necesitas comprender, identifica una ubicación inicial y define el resultado esperado. Por ejemplo: «Rastrea cómo este punto final comprueba los permisos y cita las funciones relevantes». Si utilizas subagentes, formula a cada uno una pregunta delimitada en lugar de delegarles la misma búsqueda sin restricciones.

Al alternar entre una función, un error no relacionado y una solicitud de documentación, la conversación acaba conteniendo un contexto que puede no ser aplicable a la tarea actual. Las referencias como «ese archivo» o «el enfoque anterior» se vuelven ambiguas.

Utiliza sesiones independientes para tareas no relacionadas. Si varias sesiones van a realizar la edición del repositorio, utiliza árboles de trabajo de Git independientes para que no modifiquen el mismo directorio de trabajo. A modo de breve pregunta al margen, el comando /btw de Claude Code mantiene el intercambio fuera del historial principal de la conversación.

Una compilación puede superarse aunque una función se comporte de forma incorrecta. Un conjunto de pruebas puede superarse porque nunca se ha probado la entrada que da error. Pedirle a Claude que «ejecute las pruebas» no aclara qué requisito verifican dichas pruebas.

Correlaciona los criterios de aceptación con comprobaciones específicas. Para la corrección de un error, solicita pruebas de que la prueba de reproducción falló antes del cambio y se superó después. Mantén visibles los criterios no comprobados, en lugar de considerar que un comando que ha tenido un intento correcto sirve como verificación de todo el cambio.

Un archivo CLAUDE.md en constante expansión puede contener comandos obsoletos, reglas duplicadas e instrucciones que contradigan los requisitos específicos de cada tarea. Añadir una redacción más contundente no resuelve esos conflictos.

Revisa el archivo comparándolo con el repositorio actual. Elimina las directrices obsoletas, aclara las reglas contradictorias y traslada las instrucciones de aplicación limitada a reglas o habilidades con ámbito de ruta. Si es necesario hacer cumplir un requisito, configura y prueba los controles adecuados en lugar de recurrir a recordatorios repetidos.

Una revisión puede detectar a la vez defectos reales, posibles problemas y sugerencias opcionales de refactorización. Aplicar todas las sugerencias puede ampliar el alcance del cambio sin mejorar el comportamiento deseado.

Pide pruebas y analiza el impacto de cada hallazgo. Prioriza los problemas de corrección y los requisitos no cumplidos, investiga las afirmaciones dudosas y mantén las mejoras no relacionadas fuera de la comparación actual. Un revisor debe ser capaz de informar de que no hay hallazgos que requieran acción cuando las pruebas respalden esa conclusión.

Para adaptar una plantilla, sustituye sus marcadores de posición por los datos de tu proyecto y decide qué debe hacer Claude antes de realizar los cambios. Sigue estos pasos para preparar la solicitud y revisar el resultado.

Para un cambio pequeño y bien definido, puedes pedirle a Claude que lo implemente directamente. En el caso de código desconocido, cambios que afecten a varios archivos o requisitos sin resolver, empieza por elaborar un plan.

Pulsa Mayús+Tab hasta que aparezca el modo Plan, o inicia Claude Code con el comando claude --permission-mode plan. En este modo, Claude puede inspeccionar archivos y ejecutar comandos de solo lectura sin realizar edición en tu código fuente. Revisa los archivos, las dependencias y las pruebas propuestos antes de aprobar la implementación. Pulsa Ctrl+G para abrir el plan propuesto en tu editor.

Proporciona a Claude la información necesaria para comprender la tarea: una referencia de archivo, un registro de errores depurado, una captura de pantalla o un documento de requisitos. Utiliza @ seguido de la ruta del archivo para incluir su contenido.

Elige el conjunto más reducido posible de fuentes. Incluir un registro o un directorio completo puede añadir material irrelevante y restar contexto. Elimina las credenciales y los datos confidenciales antes del uso compartido de los registros, y comprueba que Claude dispone de las herramientas necesarias para recuperar cualquier URL de documentación que le facilites.

Por ejemplo, «cat error.log | claude -p "Explica este error"» envía un registro mediante una solicitud no interactiva. Úsalo solo después de comprobar el contenido del archivo. Este es el valor práctico de la IA contextual: proporcionar al modelo información relevante para la tarea.

Al añadir una función, identifica un componente o una función similar en el repositorio. Indica a Claude qué convenciones debe seguir, como el cliente de la API, la lógica de validación, la gestión de errores o la estructura de pruebas.

«Sigue cómo @src/widgets/Weather.tsx captura y almacena datos en caché» proporciona a Claude una referencia concreta. Indica también cualquier diferencia que requiera la nueva función para que no copie un comportamiento que ya no sea adecuado. Estas convenciones deben reflejar el flujo de trabajo de desarrollo de software de tu equipo.

Para cambios en el código, especifica el comando de prueba, compilación o lint correspondiente y el comportamiento que debe comprobar. Para la investigación, solicita referencias de archivos o ID de confirmación. Para el trabajo en la interfaz de usuario, proporciona una imagen de referencia y una forma configurada de capturar la implementación en la misma ventana gráfica.

Pídele a Claude que te informe de lo que ha comprobado realmente, incluyendo los fallos y las comprobaciones omitidas. Comprueba si las pruebas demuestran que se cumple el requisito; el hecho de que la compilación se haya superado no garantiza que todos los comportamientos solicitados funcionen.

Para tareas más largas, Claude Code también ofrece una condición /goal y «hooks» de parada. El evaluador de metas valora las pruebas que surgen en la conversación, en lugar de inspeccionar archivos de forma independiente o ejecutar pruebas. Un «hook» de parada configurado puede bloquear la finalización, pero tiene límites en cuanto al bloqueo repetido. Ninguno de los dos sustituye a las pruebas adecuadas ni a la revisión humana.

Si las correcciones repetidas no resuelven un problema, detente e identifica qué aspecto de la solicitud original no quedó claro. Guarda los hallazgos útiles, el estado actual de Git y el trabajo pendiente antes de borrar la conversación.

La guía de buenas prácticas de Anthropic recomienda empezar de cero tras dos correcciones fallidas sobre el mismo problema. Utiliza /clear y, a continuación, proporciona una indicación revisada que incluya lo que has aprendido. Borrar la conversación no deshace los cambios realizados en los archivos.

Pulsa Esc para interrumpir una respuesta en ejecución. Con la indicación de entrada vacía, pulsa Esc dos veces para abrir el menú de rebobinado y elige qué restaurar. El rebobinado no deshace todos los efectos externos, así que utiliza puntos de control de Git y procedimientos de recuperación independientes para los cambios en bases de datos o servicios remotos.

Guarda las directrices para todo el proyecto en CLAUDE.md, los procedimientos repetibles en «skills» y las instrucciones para archivos concretos en reglas con ámbito de ruta. Utiliza «hooks» para acciones vinculadas a eventos específicos, como ejecutar un formateador tras una edición.

Elige en función de cuándo debe aplicarse la instrucción:

Los requisitos de una función suelen pertenecer a la indicación de la tarea o a la especificación correspondiente, y no al archivo CLAUDE.md. Añadir instrucciones temporales a un archivo que abarca todo el proyecto hace que resulten más difíciles de distinguir de las convenciones que deben aplicarse en todo el repositorio.

Por ejemplo, mantén el comando de prueba del proyecto en CLAUDE.md, incluye las convenciones específicas de cada componente en una regla con ámbito de ruta y guarda un procedimiento de revisión recurrente como una «skill». Revisa estos archivos cuando cambien los comandos o las convenciones, tal y como harías con el resto de la documentación del proyecto.

Las indicaciones, el archivo CLAUDE.md y las habilidades guían el comportamiento de Claude; no garantizan que se siga una instrucción. Los hooks pueden ejecutar comprobaciones en eventos configurados, pero su fiabilidad depende del tipo de hook y de su implementación.

Un gancho de comando ejecuta un script. Un gancho de prompt o de agente se basa en el juicio de un modelo. Tal y como explica la guía de buenas prácticas de Anthropic: «Un gancho de prompt o de agente pide a otro modelo que decida, por lo que tampoco es determinista». Para una regla que deba aplicarse, utiliza los controles de permisos adecuados y prueba el comando o el gancho HTTP correspondiente, incluyendo cómo gestiona los errores.

Los subagentes personalizados son otra forma de organizar el trabajo recurrente. Define un especialista en claude/agents/ cuando se necesite un rol de revisión específico o un ámbito de herramientas concreto, en lugar de añadir cada instrucción especializada a la sesión principal. Estas guías sobre el mejor modelo de Claude para el trabajo y los tipos de agentes de IA proporcionan contexto adicional.

Si tu equipo gestiona indicaciones en varios productos de IA, echa un vistazo a estas herramientas de ingeniería de indicaciones para gestionar bibliotecas más allá de Claude Code.

Cuando una sesión produce un resultado incompleto o inadecuado, comprueba si la solicitud dejó sin resolver decisiones importantes. Estos cinco errores pueden dificultar el diagnóstico y la revisión del trabajo.

La indicación «Investiga el repositorio» ofrece a Claude muy poca orientación sobre qué archivos son relevantes o cuándo debe detenerse. Es posible que recibas un resumen general sin una respuesta al problema que motivó la solicitud.

Nombra el comportamiento o la decisión que necesitas comprender, identifica una ubicación inicial y define el resultado esperado. Por ejemplo: «Rastrea cómo este punto final comprueba los permisos y cita las funciones relevantes». Si utilizas subagentes, formula a cada uno una pregunta delimitada en lugar de delegarles la misma búsqueda sin restricciones.

Al alternar entre una función, un error no relacionado y una solicitud de documentación, la conversación acaba conteniendo un contexto que puede no ser aplicable a la tarea actual. Las referencias como «ese archivo» o «el enfoque anterior» se vuelven ambiguas.

Utiliza sesiones independientes para tareas no relacionadas. Si varias sesiones van a realizar la edición del repositorio, utiliza árboles de trabajo de Git independientes para que no modifiquen el mismo directorio de trabajo. A modo de breve pregunta al margen, el comando /btw de Claude Code mantiene el intercambio fuera del historial principal de la conversación.

Una compilación puede superar las pruebas aunque una función se comporte de forma incorrecta. Un conjunto de pruebas puede superar las pruebas porque nunca se ha probado la entrada que provoca el fallo. Pedirle a Claude que «ejecute las pruebas» no establece qué requisito verifican dichas pruebas.

Correlaciona los criterios de aceptación con comprobaciones específicas. Para la corrección de un error, solicita pruebas de que la prueba de reproducción falló antes del cambio y se superó después. Mantén visibles los criterios no comprobados, en lugar de considerar que un comando que se ha ejecutado de manera correcta sirve como verificación de todo el cambio.

Un archivo CLAUDE.md en constante expansión puede contener comandos obsoletos, reglas duplicadas e instrucciones que contradigan los requisitos específicos de cada tarea. Añadir una redacción más contundente no resuelve esos conflictos.

Revisa el archivo comparándolo con el repositorio actual. Elimina las directrices obsoletas, aclara las reglas contradictorias y traslada las instrucciones de aplicación limitada a reglas o habilidades con ámbito de ruta. Si es necesario hacer cumplir un requisito, configura y prueba los controles adecuados en lugar de recurrir a recordatorios repetidos.

Una revisión puede detectar a la vez defectos reales, posibles problemas y sugerencias opcionales de refactorización. Aplicar todas las sugerencias puede ampliar el alcance del cambio sin mejorar el comportamiento deseado.

Pide pruebas y analiza el impacto de cada hallazgo. Prioriza los problemas de corrección y los requisitos no cumplidos, investiga las afirmaciones dudosas y mantén las mejoras no relacionadas fuera de la comparación actual. Un revisor debe ser capaz de informar de que no hay hallazgos que requieran acción cuando las pruebas respalden esa conclusión.

Para adaptar una plantilla, sustituye sus marcadores de posición por los datos de tu proyecto y decide qué debe hacer Claude antes de realizar los cambios. Sigue estos pasos para preparar la solicitud y revisar el resultado.

Para un cambio pequeño y bien definido, puedes pedirle a Claude que lo implemente directamente. En el caso de código desconocido, cambios que afecten a varios archivos o requisitos sin resolver, empieza por elaborar un plan.

Pulsa Mayús+Tab hasta que aparezca el modo Plan, o inicia Claude Code con el comando claude --permission-mode plan. En este modo, Claude puede inspeccionar archivos y ejecutar comandos de solo lectura sin realizar edición en tu código fuente. Revisa los archivos, las dependencias y las pruebas propuestos antes de aprobar la implementación. Pulsa Ctrl+G para abrir el plan propuesto en tu editor.

Proporciona a Claude la información necesaria para comprender la tarea: una referencia de archivo, un registro de errores depurado, una captura de pantalla o un documento de requisitos. Utiliza @ seguido de la ruta del archivo para incluir su contenido.

Elige el conjunto más reducido posible de fuentes. Incluir un registro o un directorio completo puede añadir material irrelevante y restar contexto. Elimina las credenciales y los datos confidenciales antes del uso compartido de los registros, y comprueba que Claude dispone de las herramientas necesarias para recuperar cualquier URL de documentación que le facilites.

Por ejemplo, «cat error.log | claude -p "Explica este error"» envía un registro mediante una solicitud no interactiva. Úsalo solo después de comprobar el contenido del archivo. Este es el valor práctico de la IA contextual: proporcionar al modelo información relevante para la tarea.

Al añadir una función, identifica un componente o una función similar en el repositorio. Indica a Claude qué convenciones debe seguir, como el cliente de la API, la lógica de validación, la gestión de errores o la estructura de pruebas.

«Sigue cómo @src/widgets/Weather.tsx captura y almacena datos en caché» proporciona a Claude una referencia concreta. Indica también cualquier diferencia que requiera la nueva función para que no copie un comportamiento que ya no sea adecuado. Estas convenciones deben reflejar el flujo de trabajo de desarrollo de software de tu equipo.

Para cambios en el código, especifica el comando de prueba, compilación o lint pertinente y el comportamiento que debe comprobar. Para la investigación, solicita referencias de archivos o ID de confirmación. Para el trabajo en la interfaz de usuario, proporciona una imagen de referencia y una forma configurada de capturar la implementación en la misma ventana gráfica.

Pídele a Claude que te informe de lo que ha comprobado realmente, incluyendo los fallos y las comprobaciones omitidas. Comprueba si las pruebas demuestran que se cumple el requisito; el hecho de que la compilación se haya superado no garantiza que todos los comportamientos solicitados funcionen.

Para tareas más largas, Claude Code también ofrece una condición /goal y «hooks» de parada. El evaluador de objetivos analiza las pruebas que surgen en la conversación, en lugar de inspeccionar archivos de forma independiente o ejecutar pruebas. Un «hook» de parada configurado puede bloquear la finalización, pero tiene límites en cuanto al bloqueo repetido. Ninguno de los dos sustituye a las pruebas adecuadas ni a la revisión humana.

Si las correcciones repetidas no resuelven un problema, detente e identifica qué aspecto de la solicitud original no quedó claro. Guarda los hallazgos útiles, el estado actual de Git y el trabajo pendiente antes de borrar la conversación.

La guía de buenas prácticas de Anthropic recomienda empezar de cero tras dos correcciones fallidas sobre el mismo problema. Utiliza /clear y, a continuación, proporciona una indicación revisada que incluya lo que has aprendido. Borrar la conversación no deshace los cambios realizados en los archivos.

Pulsa Esc para interrumpir una respuesta en ejecución. Con la indicación de entrada vacía, pulsa Esc dos veces para abrir el menú de rebobinado y elige qué restaurar. El rebobinado no deshace todos los efectos externos, así que utiliza puntos de control de Git y procedimientos de recuperación independientes para los cambios en bases de datos o servicios remotos.

Guarda las directrices para todo el proyecto en CLAUDE.md, los procedimientos repetibles en «skills» y las instrucciones para archivos concretos en reglas con ámbito de ruta. Utiliza «hooks» para acciones vinculadas a eventos específicos, como ejecutar un formateador tras una edición.

Elige en función de cuándo debe aplicarse la instrucción:

Los requisitos de una función suelen pertenecer a la indicación de la tarea o a la especificación correspondiente, y no al archivo CLAUDE.md. Añadir instrucciones temporales a un archivo que abarca todo el proyecto hace que resulten más difíciles de distinguir de las convenciones que deben aplicarse en todo el repositorio.

Por ejemplo, mantén el comando de prueba del proyecto en CLAUDE.md, incluye las convenciones específicas de cada componente en una regla con ámbito de ruta y guarda un procedimiento de revisión recurrente como una «skill». Revisa estos archivos cuando cambien los comandos o las convenciones, tal y como harías con el resto de la documentación del proyecto.

Las indicaciones, el archivo CLAUDE.md y las habilidades guían el comportamiento de Claude; no garantizan que se siga una instrucción. Los hooks pueden ejecutar comprobaciones en eventos configurados, pero su fiabilidad depende del tipo de hook y de su implementación.

Un gancho de comando ejecuta un script. Un gancho de indicación o de agente se basa en el juicio de un modelo. Tal y como explica la guía de buenas prácticas de Anthropic: «Un gancho de indicación o de agente pide a otro modelo que decida, por lo que tampoco es determinista». Para una regla que deba aplicarse, utiliza controles de permisos adecuados y prueba el comando o gancho HTTP correspondiente, incluyendo cómo gestiona los fallos.

Los subagentes personalizados son otra forma de organizar el trabajo recurrente. Define un especialista en claude/agents/ cuando se necesite un rol de revisión específico o un ámbito de herramientas concreto, en lugar de añadir cada instrucción especializada a la sesión principal. Estas guías sobre el mejor modelo de Claude para el trabajo y los tipos de agentes de IA proporcionan contexto adicional.

Si tu equipo gestiona indicaciones en varios productos de IA, echa un vistazo a estas herramientas de ingeniería de indicaciones para gestionar bibliotecas más allá de Claude Code.

Cuando una sesión produce un resultado incompleto o inadecuado, comprueba si la solicitud dejó sin resolver decisiones importantes. Estos cinco errores pueden dificultar el diagnóstico y la revisión del trabajo.

La indicación «Investiga el repositorio» ofrece a Claude muy poca orientación sobre qué archivos son relevantes o cuándo debe detenerse. Es posible que recibas un resumen general sin una respuesta al problema que motivó la solicitud.

Nombra el comportamiento o la decisión que necesitas comprender, identifica una ubicación y define el resultado esperado. Por ejemplo: «Rastrea cómo este punto final comprueba los permisos y cita las funciones relevantes». Si utilizas subagentes, formula a cada uno una pregunta delimitada en lugar de delegarles la misma búsqueda sin restricciones.

Al alternar entre una función, una incidencia no relacionada y una solicitud de documentación, la conversación acaba conteniendo un contexto que puede no ser aplicable a la tarea actual. Las referencias como «ese archivo» o «el enfoque anterior» se vuelven ambiguas.

Utiliza sesiones independientes para tareas no relacionadas. Si varias sesiones van a realizar la edición del repositorio, utiliza árboles de trabajo de Git independientes para que no modifiquen el mismo directorio de trabajo. A modo de breve pregunta al margen, el comando /btw de Claude Code mantiene el intercambio fuera del historial principal de la conversación.

Una compilación puede superar las pruebas aunque una función se comporte de forma incorrecta. Un conjunto de pruebas puede superar las pruebas porque nunca se ha probado la entrada que provoca el fallo. Pedirle a Claude que «ejecute las pruebas» no establece qué requisito verifican dichas pruebas.

Correlaciona los criterios de aceptación con comprobaciones específicas. Para la corrección de un error, solicita pruebas de que la prueba de reproducción falló antes del cambio y se superó después. Mantén visibles los criterios no probados, en lugar de considerar que un comando que ha tenido un intento correcto sirve como verificación de todo el cambio.

Un archivo CLAUDE.md en constante expansión puede contener comandos obsoletos, reglas duplicadas e instrucciones que contradigan los requisitos específicos de cada tarea. Añadir una redacción más contundente no resuelve esos conflictos.

Revisa el archivo comparándolo con el repositorio actual. Elimina las directrices obsoletas, aclara las reglas contradictorias y traslada las instrucciones de aplicación limitada a reglas o habilidades con ámbito de ruta. Si es necesario hacer cumplir un requisito, configura y prueba los controles adecuados en lugar de recurrir a recordatorios repetidos.

Una revisión puede detectar a la vez defectos reales, posibles problemas y sugerencias opcionales de refactorización. Aplicar todas las sugerencias puede ampliar el alcance del cambio sin mejorar el comportamiento deseado.

Pide pruebas y analiza el impacto de cada hallazgo. Prioriza los problemas de corrección y los requisitos no cumplidos, investiga las afirmaciones dudosas y mantén las mejoras no relacionadas fuera de la comparación actual. Un revisor debe ser capaz de informar de que no hay hallazgos que requieran acción cuando las pruebas respalden esa conclusión.

Para adaptar una plantilla, sustituye sus marcadores de posición por los datos de tu proyecto y decide qué debe hacer Claude antes de realizar los cambios. Sigue estos pasos para preparar la solicitud y revisar el resultado.

Para un cambio pequeño y bien definido, puedes pedirle a Claude que lo implemente directamente. En el caso de código desconocido, cambios que afecten a varios archivos o requisitos sin resolver, empieza por elaborar un plan.

Pulsa Mayús+Tab hasta que aparezca el modo Plan, o inicia Claude Code con el comando claude --permission-mode plan. En este modo, Claude puede inspeccionar archivos y ejecutar comandos de solo lectura sin realizar edición en tu código fuente. Revisa los archivos, las dependencias y las pruebas propuestos antes de aprobar la implementación. Pulsa Ctrl+G para abrir el plan propuesto en tu editor.

Proporciona a Claude la información necesaria para comprender la tarea: una referencia de archivo, un registro de errores depurado, una captura de pantalla o un documento de requisitos. Utiliza @ seguido de la ruta del archivo para incluir su contenido.

Elige el conjunto más reducido posible de fuentes. Incluir un registro o un directorio completo puede añadir material irrelevante y restar contexto. Elimina las credenciales y los datos confidenciales antes del uso compartido de los registros, y comprueba que Claude dispone de las herramientas necesarias para recuperar cualquier URL de documentación que le facilites.

Por ejemplo, «cat error.log | claude -p "Explica este error"» envía un registro mediante una solicitud no interactiva. Úsalo solo después de comprobar el contenido del archivo. Este es el valor práctico de la IA contextual: proporcionar al modelo información relevante para la tarea.

Al añadir una función, identifica un componente o una función similar en el repositorio. Indica a Claude qué convenciones debe seguir, como el cliente de la API, la lógica de validación, la gestión de errores o la estructura de pruebas.

«Sigue cómo @src/widgets/Weather.tsx captura y almacena datos en caché» proporciona a Claude una referencia concreta. Indica también cualquier diferencia que requiera la nueva función para que no copie un comportamiento que ya no sea adecuado. Estas convenciones deben reflejar el flujo de trabajo de desarrollo de software de tu equipo.

Para cambios en el código, especifica el comando de prueba, compilación o lint correspondiente y el comportamiento que debe comprobar. Para la investigación, solicita referencias de archivos o ID de confirmación. Para el trabajo en la interfaz de usuario, proporciona una imagen de referencia y una forma configurada de capturar la implementación en la misma ventana gráfica.

Pídele a Claude que te informe de lo que ha comprobado realmente, incluyendo los fallos y las comprobaciones omitidas. Comprueba si las pruebas demuestran que se cumple el requisito; el hecho de que la compilación se haya superado no garantiza que todos los comportamientos solicitados funcionen.

Para tareas más largas, Claude Code también ofrece una condición /goal y «hooks» de parada. El evaluador de metas valora las pruebas que surgen en la conversación, en lugar de inspeccionar archivos de forma independiente o ejecutar pruebas. Un «hook» de parada configurado puede bloquear la finalización, pero tiene límites en cuanto al bloqueo repetido. Ninguno de los dos sustituye a las pruebas adecuadas ni a la revisión humana.

Si las correcciones repetidas no resuelven un problema, detente e identifica qué aspecto de la solicitud original no quedó claro. Guarda los hallazgos útiles, el estado actual de Git y el trabajo pendiente antes de borrar la conversación.

La guía de buenas prácticas de Anthropic recomienda empezar de cero tras dos correcciones fallidas sobre el mismo problema. Utiliza /clear y, a continuación, proporciona una indicación revisada que incluya lo que has aprendido. Borrar la conversación no deshace los cambios realizados en los archivos.

Pulsa Esc para interrumpir una respuesta en ejecución. Con la indicación de entrada vacía, pulsa Esc dos veces para abrir el menú de rebobinado y elige qué restaurar. El rebobinado no deshace todos los efectos externos, así que utiliza puntos de control de Git y procedimientos de recuperación independientes para los cambios en bases de datos o servicios remotos.

Guarda las directrices para todo el proyecto en CLAUDE.md, los procedimientos repetibles en «skills» y las instrucciones para archivos concretos en reglas con ámbito de ruta. Utiliza «hooks» para acciones vinculadas a eventos específicos, como ejecutar un formateador tras una edición.

Elige en función de cuándo debe aplicarse la instrucción:

Los requisitos de una función suelen pertenecer a la indicación de la tarea o a la especificación correspondiente, y no al archivo CLAUDE.md. Añadir instrucciones temporales a un archivo que abarca todo el proyecto hace que resulten más difíciles de distinguir de las convenciones que deben aplicarse en todo el repositorio.

Por ejemplo, mantén el comando de prueba del proyecto en CLAUDE.md, incluye las convenciones específicas de cada componente en una regla con ámbito de ruta y guarda un procedimiento de revisión recurrente como una «skill». Revisa estos archivos cuando cambien los comandos o las convenciones, tal y como harías con el resto de la documentación del proyecto.

Las indicaciones, el archivo CLAUDE.md y las habilidades guían el comportamiento de Claude; no garantizan que se siga una instrucción. Los hooks pueden ejecutar comprobaciones en eventos configurados, pero su fiabilidad depende del tipo de hook y de su implementación.

Un gancho de comando ejecuta un script. Un gancho de indicación o de agente se basa en el juicio de un modelo. Tal y como explica la guía de buenas prácticas de Anthropic: «Un gancho de indicación o de agente pide a otro modelo que decida, por lo que tampoco es determinista». Para una regla que deba aplicarse, utiliza los controles de permisos adecuados y prueba el comando o el gancho HTTP correspondiente, incluyendo cómo gestiona los fallos.

Los subagentes personalizados son otra forma de organizar el trabajo recurrente. Define un especialista en claude/agents/ cuando se necesite un rol de revisión específico o un ámbito de herramientas concreto, en lugar de añadir cada instrucción especializada a la sesión principal. Estas guías sobre el mejor modelo de Claude para el trabajo y los tipos de agentes de IA proporcionan contexto adicional.

Si tu equipo gestiona indicaciones en varios productos de IA, echa un vistazo a estas herramientas de ingeniería de indicaciones para gestionar bibliotecas más allá de Claude Code.

Cuando una sesión produce un resultado incompleto o inadecuado, comprueba si la solicitud dejó sin resolver decisiones importantes. Estos cinco errores pueden dificultar el diagnóstico y la revisión del trabajo.

La indicación «Investiga el repositorio» ofrece a Claude muy poca orientación sobre qué archivos son relevantes o cuándo debe detenerse. Es posible que recibas un resumen general sin una respuesta al problema que motivó la solicitud.

Nombra el comportamiento o la decisión que necesitas comprender, identifica una ubicación y define el resultado esperado. Por ejemplo: «Rastrea cómo este punto final comprueba los permisos y cita las funciones relevantes». Si utilizas subagentes, formula a cada uno una pregunta delimitada en lugar de delegarles la misma búsqueda sin restricciones.

Al alternar entre una función, un error no relacionado y una solicitud de documentación, la conversación acaba conteniendo un contexto que puede no ser aplicable a la tarea actual. Las referencias como «ese archivo» o «el enfoque anterior» se vuelven ambiguas.

Utiliza sesiones independientes para tareas no relacionadas. Si varias sesiones van a realizar la edición del repositorio, utiliza árboles de trabajo de Git independientes para que no modifiquen el mismo directorio de trabajo. A modo de breve pregunta al margen, el comando /btw de Claude Code mantiene el intercambio fuera del historial principal de la conversación.

Una compilación puede superar las pruebas aunque una función se comporte de forma incorrecta. Un conjunto de pruebas puede superar las pruebas porque nunca se ha probado la entrada que provoca el fallo. Pedirle a Claude que «ejecute las pruebas» no aclara qué requisito verifican dichas pruebas.

Correlaciona los criterios de aceptación con comprobaciones específicas. Para la corrección de un error, solicita pruebas de que la prueba de reproducción falló antes del cambio y se superó después. Mantén visibles los criterios no comprobados, en lugar de considerar que un comando que ha realizado un intento correcto sirve como verificación de todo el cambio.

Un archivo CLAUDE.md en constante expansión puede contener comandos obsoletos, reglas duplicadas e instrucciones que contradigan los requisitos específicos de cada tarea. Añadir una redacción más contundente no resuelve esos conflictos.

Revisa el archivo comparándolo con el repositorio actual. Elimina las directrices obsoletas, aclara las reglas contradictorias y traslada las instrucciones de aplicación limitada a reglas o habilidades con ámbito de ruta. Si es necesario hacer cumplir un requisito, configura y prueba los controles adecuados en lugar de recurrir a recordatorios repetidos.

Una revisión puede detectar a la vez defectos reales, posibles problemas y sugerencias opcionales de refactorización. Aplicar todas las sugerencias puede ampliar el alcance del cambio sin mejorar el comportamiento deseado.

Pide pruebas y analiza el impacto de cada hallazgo. Prioriza los problemas de corrección y los requisitos no cumplidos, investiga las afirmaciones dudosas y mantén las mejoras no relacionadas fuera de la comparación actual. Un revisor debe ser capaz de informar de que no hay hallazgos que requieran acción cuando las pruebas respalden esa conclusión.

Para adaptar una plantilla, sustituye sus marcadores de posición por los datos de tu proyecto y decide qué debe hacer Claude antes de realizar los cambios. Sigue estos pasos para preparar la solicitud y revisar el resultado.

Para un cambio pequeño y bien definido, puedes pedirle a Claude que lo implemente directamente. En el caso de código desconocido, cambios que afecten a varios archivos o requisitos sin resolver, empieza por elaborar un plan.

Pulsa Mayús+Tab hasta que aparezca el modo Plan, o inicia Claude Code con el comando claude --permission-mode plan. En este modo, Claude puede inspeccionar archivos y ejecutar comandos de solo lectura sin realizar edición en tu código fuente. Revisa los archivos, las dependencias y las pruebas propuestos antes de aprobar la implementación. Pulsa Ctrl+G para abrir el plan propuesto en tu editor.

Proporciona a Claude la información necesaria para comprender la tarea: una referencia de archivo, un registro de errores depurado, una captura de pantalla o un documento de requisitos. Utiliza @ seguido de la ruta del archivo para incluir su contenido.

Elige el conjunto más reducido posible de fuentes. Incluir un registro o un directorio completo puede añadir material irrelevante y restar contexto. Elimina las credenciales y los datos confidenciales antes del uso compartido de los registros, y comprueba que Claude dispone de las herramientas necesarias para recuperar cualquier URL de documentación que le facilites.

Por ejemplo, «cat error.log | claude -p "Explica este error"» envía un registro mediante una solicitud no interactiva. Úsalo solo después de comprobar el contenido del archivo. Este es el valor práctico de la IA contextual: proporcionar al modelo información relevante para la tarea.

Al añadir una función, identifica un componente o una función similar en el repositorio. Indica a Claude qué convenciones debe seguir, como el cliente de la API, la lógica de validación, la gestión de errores o la estructura de pruebas.

«Sigue cómo @src/widgets/Weather.tsx captura y almacena datos en caché» proporciona a Claude una referencia concreta. Indica también cualquier diferencia que requiera la nueva función para que no copie un comportamiento que ya no sea adecuado. Estas convenciones deben reflejar el flujo de trabajo de desarrollo de software de tu equipo.

Para cambios en el código, especifica el comando de prueba, compilación o lint correspondiente y el comportamiento que debe comprobar. Para la investigación, solicita referencias de archivos o ID de confirmación. Para el trabajo en la interfaz de usuario, proporciona una imagen de referencia y una forma configurada de capturar la implementación en la misma ventana gráfica.

Pídele a Claude que te informe de lo que ha comprobado realmente, incluyendo los fallos y las comprobaciones omitidas. Comprueba si las pruebas demuestran que se cumple el requisito; el hecho de que la compilación se haya superado no garantiza que todos los comportamientos solicitados funcionen.

Para tareas más largas, Claude Code también ofrece una condición /goal y «hooks» de parada. El evaluador de metas valora las pruebas que surgen en la conversación, en lugar de inspeccionar archivos de forma independiente o ejecutar pruebas. Un «hook» de parada configurado puede bloquear la finalización, pero tiene límites en cuanto al bloqueo repetido. Ninguno de los dos sustituye a las pruebas adecuadas ni a la revisión humana.

Si las correcciones repetidas no resuelven un problema, detente e identifica qué aspecto de la solicitud original no quedó claro. Guarda los hallazgos útiles, el estado actual de Git y el trabajo pendiente antes de borrar la conversación.

La guía de buenas prácticas de Anthropic recomienda empezar de cero tras dos correcciones fallidas sobre el mismo problema. Utiliza /clear y, a continuación, proporciona una indicación revisada que incluya lo que has aprendido. Borrar la conversación no deshace los cambios realizados en los archivos.

Pulsa Esc para interrumpir una respuesta en ejecución. Con la indicación de entrada vacía, pulsa Esc dos veces para abrir el menú de rebobinado y elige qué restaurar. El rebobinado no deshace todos los efectos externos, así que utiliza puntos de control de Git y procedimientos de recuperación independientes para los cambios en bases de datos o servicios remotos.

Guarda las directrices para todo el proyecto en CLAUDE.md, los procedimientos repetibles en «skills» y las instrucciones para archivos concretos en reglas con ámbito de ruta. Utiliza «hooks» para acciones vinculadas a eventos específicos, como ejecutar un formateador tras una edición.

Elige en función de cuándo debe aplicarse la instrucción:

Los requisitos de una función suelen pertenecer a la indicación de la tarea o a la especificación correspondiente, y no al archivo CLAUDE.md. Añadir instrucciones temporales a un archivo que abarca todo el proyecto hace que resulten más difíciles de distinguir de las convenciones que deben aplicarse en todo el repositorio.

Por ejemplo, mantén el comando de prueba del proyecto en CLAUDE.md, incluye las convenciones específicas de cada componente en una regla con ámbito de ruta y guarda un procedimiento de revisión recurrente como una «skill». Revisa estos archivos cuando cambien los comandos o las convenciones, tal y como harías con el resto de la documentación del proyecto.

Las indicaciones, el archivo CLAUDE.md y las habilidades guían el comportamiento de Claude; no garantizan que se siga una instrucción. Los hooks pueden ejecutar comprobaciones en eventos configurados, pero su fiabilidad depende del tipo de hook y de su implementación.

Un gancho de comando ejecuta un script. Un gancho de indicación o de agente se basa en el juicio de un modelo. Tal y como explica la guía de buenas prácticas de Anthropic: «Un gancho de indicación o de agente pide a otro modelo que decida, por lo que tampoco es determinista». Para una regla que deba aplicarse, utiliza controles de permisos adecuados y prueba el comando o gancho HTTP correspondiente, incluyendo cómo gestiona los fallos.

Los subagentes personalizados son otra forma de organizar el trabajo recurrente. Define un especialista en claude/agents/ cuando se necesite un rol de revisión específico o un ámbito de herramientas concreto, en lugar de añadir cada instrucción especializada a la sesión principal. Estas guías sobre el mejor modelo de Claude para el trabajo y los tipos de agentes de IA proporcionan contexto adicional.

Si tu equipo gestiona indicaciones en varios productos de IA, echa un vistazo a estas herramientas de ingeniería de indicaciones para gestionar bibliotecas más allá de Claude Code.

Cuando una sesión arroja un resultado incompleto o inadecuado, comprueba si la solicitud dejó sin resolver decisiones importantes. Estos cinco errores pueden dificultar el diagnóstico y la revisión del trabajo.

La indicación «Investiga el repositorio» ofrece a Claude muy poca orientación sobre qué archivos son relevantes o cuándo debe detenerse. Es posible que recibas un resumen general sin una respuesta al problema que motivó la solicitud.

Nombra el comportamiento o la decisión que necesitas comprender, identifica una ubicación inicial y define el resultado esperado. Por ejemplo: «Rastrea cómo este punto final comprueba los permisos y cita las funciones relevantes». Si utilizas subagentes, formula a cada uno una pregunta delimitada en lugar de delegarles la misma búsqueda sin restricciones.

Al alternar entre una función, una incidencia no relacionada y una solicitud de documentación, la conversación acaba conteniendo un contexto que puede no ser aplicable a la tarea actual. Las referencias como «ese archivo» o «el enfoque anterior» se vuelven ambiguas.

Utiliza sesiones independientes para tareas no relacionadas. Si varias sesiones van a realizar la edición del repositorio, utiliza árboles de trabajo de Git independientes para que no modifiquen el mismo directorio de trabajo. A modo de breve pregunta al margen, el comando /btw de Claude Code mantiene el intercambio fuera del historial principal de la conversación.

Una compilación puede superarse aunque una función se comporte de forma incorrecta. Un conjunto de pruebas puede superarse porque nunca se ha probado la entrada que da error. Pedirle a Claude que «ejecute las pruebas» no aclara qué requisito verifican dichas pruebas.

Correlaciona los criterios de aceptación con comprobaciones específicas. Para la corrección de un error, solicita pruebas de que la prueba de reproducción falló antes del cambio y se superó después. Mantén visibles los criterios no comprobados, en lugar de considerar que un comando que se ha ejecutado de manera correcta sirve como verificación de todo el cambio.

Un archivo CLAUDE.md en constante expansión puede contener comandos obsoletos, reglas duplicadas e instrucciones que contradigan los requisitos específicos de cada tarea. Añadir una redacción más contundente no resuelve esos conflictos.

Revisa el archivo comparándolo con el repositorio actual. Elimina las directrices obsoletas, aclara las reglas contradictorias y traslada las instrucciones de aplicación limitada a reglas o habilidades con ámbito de ruta. Si es necesario hacer cumplir un requisito, configura y prueba los controles adecuados en lugar de recurrir a recordatorios repetidos.

Una revisión puede detectar a la vez defectos reales, posibles problemas y sugerencias opcionales de refactorización. Aplicar todas las sugerencias puede ampliar el alcance del cambio sin mejorar el comportamiento deseado.

Pide pruebas y analiza el impacto de cada hallazgo. Prioriza los problemas de corrección y los requisitos no cumplidos, investiga las afirmaciones dudosas y mantén las mejoras no relacionadas fuera de la comparación actual. Un revisor debe ser capaz de informar de que no hay hallazgos que requieran acción cuando las pruebas respalden esa conclusión.

Para adaptar una plantilla, sustituye sus marcadores de posición por los datos de tu proyecto y decide qué debe hacer Claude antes de realizar los cambios. Sigue estos pasos para preparar la solicitud y revisar el resultado.

Para un cambio pequeño y bien definido, puedes pedirle a Claude que lo implemente directamente. En el caso de código desconocido, cambios que afecten a varios archivos o requisitos sin resolver, empieza por elaborar un plan.

Pulsa Mayús+Tab hasta que aparezca el modo Plan, o inicia Claude Code con el comando claude --permission-mode plan. En este modo, Claude puede inspeccionar archivos y ejecutar comandos de solo lectura sin realizar edición en tu código fuente. Revisa los archivos, las dependencias y las pruebas propuestos antes de aprobar la implementación. Pulsa Ctrl+G para abrir el plan propuesto en tu editor.

Proporciona a Claude la información necesaria para comprender la tarea: una referencia de archivo, un registro de errores depurado, una captura de pantalla o un documento de requisitos. Utiliza @ seguido de la ruta del archivo para incluir su contenido.

Elige el conjunto más reducido posible de fuentes. Incluir un registro o un directorio completo puede añadir material irrelevante y restar contexto. Elimina las credenciales y los datos confidenciales antes del uso compartido de los registros, y comprueba que Claude dispone de las herramientas necesarias para recuperar cualquier URL de documentación que le facilites.

Por ejemplo, «cat error.log | claude -p "Explica este error"» envía un registro mediante una solicitud no interactiva. Úsalo solo después de comprobar el contenido del archivo. Este es el valor práctico de la IA contextual: proporcionar al modelo información relevante para la tarea.

Al añadir una función, identifica un componente o una función similar en el repositorio. Indica a Claude qué convenciones debe seguir, como el cliente de la API, la lógica de validación, la gestión de errores o la estructura de pruebas.

«Sigue cómo @src/widgets/Weather.tsx captura y almacena datos en caché» proporciona a Claude una referencia concreta. Indica también cualquier diferencia que requiera la nueva función para que no copie un comportamiento que ya no sea adecuado. Estas convenciones deben reflejar el flujo de trabajo de desarrollo de software de tu equipo.

Para cambios en el código, especifica el comando de prueba, compilación o lint correspondiente y el comportamiento que debe comprobar. Para la investigación, solicita referencias de archivos o ID de confirmación. Para el trabajo en la interfaz de usuario, proporciona una imagen de referencia y una forma configurada de capturar la implementación en la misma ventana gráfica.

Pídele a Claude que te informe de lo que ha comprobado realmente, incluyendo los fallos y las comprobaciones omitidas. Comprueba si las pruebas demuestran que se cumple el requisito; el hecho de que la compilación se haya superado no garantiza que todos los comportamientos solicitados funcionen.

Para tareas más largas, Claude Code también ofrece una condición /goal y «hooks» de parada. El evaluador de objetivos valora las pruebas que surgen en la conversación, en lugar de inspeccionar archivos de forma independiente o ejecutar pruebas. Un «hook» de parada configurado puede bloquear la finalización, pero tiene límites en cuanto al bloqueo repetido. Ninguno de los dos sustituye a las pruebas adecuadas ni a la revisión humana.

Si las correcciones repetidas no resuelven un problema, detente e identifica qué aspecto de la solicitud original no quedó claro. Guarda los hallazgos útiles, el estado actual de Git y el trabajo pendiente antes de borrar la conversación.

La guía de buenas prácticas de Anthropic recomienda empezar de cero tras dos correcciones fallidas sobre el mismo problema. Utiliza /clear y, a continuación, proporciona una indicación revisada que incluya lo que has aprendido. Borrar la conversación no deshace los cambios realizados en los archivos.

Pulsa Esc para interrumpir una respuesta en ejecución. Con la indicación de entrada vacía, pulsa Esc dos veces para abrir el menú de rebobinado y elige qué restaurar. El rebobinado no deshace todos los efectos externos, así que utiliza puntos de control de Git y procedimientos de recuperación independientes para los cambios en bases de datos o servicios remotos.

Guarda las directrices para todo el proyecto en CLAUDE.md, los procedimientos repetibles en «skills» y las instrucciones para archivos concretos en reglas con ámbito de ruta. Utiliza «hooks» para acciones vinculadas a eventos específicos, como ejecutar un formateador tras una edición.

Elige en función de cuándo debe aplicarse la instrucción:

Los requisitos de una función suelen pertenecer a la indicación de la tarea o a la especificación correspondiente, y no al archivo CLAUDE.md. Añadir instrucciones temporales a un archivo que abarca todo el proyecto hace que resulten más difíciles de distinguir de las convenciones que deben aplicarse en todo el repositorio.

Por ejemplo, mantén el comando de prueba del proyecto en CLAUDE.md, incluye las convenciones específicas de cada componente en una regla con ámbito de ruta y guarda un procedimiento de revisión recurrente como una «habilidad». Revisa estos archivos cuando cambien los comandos o las convenciones, tal y como harías con el resto de la documentación del proyecto.

Las indicaciones, el archivo CLAUDE.md y las habilidades guían el comportamiento de Claude; no garantizan que se siga una instrucción. Los hooks pueden ejecutar comprobaciones en eventos configurados, pero su fiabilidad depende del tipo de hook y de su implementación.

Un gancho de comando ejecuta un script. Un gancho de indicación o de agente se basa en el juicio de un modelo. Tal y como explica la guía de buenas prácticas de Anthropic: «Un gancho de indicación o de agente pide a otro modelo que decida, por lo que tampoco es determinista». Para una regla que deba aplicarse, utiliza controles de permisos adecuados y prueba el comando o gancho HTTP correspondiente, incluyendo cómo gestiona los fallos.

Los subagentes personalizados son otra forma de organizar el trabajo recurrente. Define un especialista en claude/agents/ cuando se necesite un rol de revisión específico o un ámbito de herramientas concreto, en lugar de añadir cada instrucción especializada a la sesión principal. Estas guías sobre el mejor modelo de Claude para el trabajo y los tipos de agentes de IA proporcionan contexto adicional.

Si tu equipo gestiona indicaciones en varios productos de IA, echa un vistazo a estas herramientas de ingeniería de indicaciones para gestionar bibliotecas más allá de Claude Code.

Cuando una sesión produce un resultado incompleto o inadecuado, comprueba si la solicitud dejó sin resolver decisiones importantes. Estos cinco errores pueden dificultar el diagnóstico y la revisión del trabajo.

La indicación «Investiga el repositorio» ofrece a Claude muy poca orientación sobre qué archivos son relevantes o cuándo debe detenerse. Es posible que recibas un resumen general sin una respuesta al problema que motivó la solicitud.

Nombra el comportamiento o la decisión que necesitas comprender, identifica una ubicación y define el resultado esperado. Por ejemplo: «Rastrea cómo este punto final comprueba los permisos y cita las funciones relevantes». Si utilizas subagentes, formula a cada uno una pregunta delimitada en lugar de delegarles la misma búsqueda sin restricciones.

Al alternar entre una función, una incidencia no relacionada y una solicitud de documentación, la conversación acaba conteniendo un contexto que puede no ser aplicable a la tarea actual. Las referencias como «ese archivo» o «el enfoque anterior» se vuelven ambiguas.

Utiliza sesiones independientes para tareas no relacionadas. Si varias sesiones van a realizar la edición del repositorio, utiliza árboles de trabajo de Git independientes para que no modifiquen el mismo directorio de trabajo. A modo de breve pregunta al margen, el comando /btw de Claude Code mantiene el intercambio fuera del historial principal de la conversación.

Una compilación puede superar las pruebas aunque una función se comporte de forma incorrecta. Un conjunto de pruebas puede superar las pruebas porque nunca se ha probado la entrada que provoca el fallo. Pedirle a Claude que «ejecute las pruebas» no establece qué requisito verifican dichas pruebas.

Correlaciona los criterios de aceptación con comprobaciones específicas. Para la corrección de un error, solicita pruebas de que la prueba de reproducción falló antes del cambio y se superó después. Mantén visibles los criterios no comprobados, en lugar de considerar que un comando que ha tenido un intento correcto sirve como verificación de todo el cambio.

Un archivo CLAUDE.md en constante expansión puede contener comandos obsoletos, reglas duplicadas e instrucciones que contradigan los requisitos específicos de cada tarea. Añadir una redacción más contundente no resuelve esos conflictos.

Revisa el archivo comparándolo con el repositorio actual. Elimina las directrices obsoletas, aclara las reglas contradictorias y traslada las instrucciones de aplicación limitada a reglas o habilidades con ámbito de ruta. Si es necesario hacer cumplir un requisito, configura y prueba los controles adecuados en lugar de recurrir a recordatorios repetidos.

Una revisión puede detectar a la vez defectos reales, posibles problemas y sugerencias opcionales de refactorización. Aplicar todas las sugerencias puede ampliar el alcance del cambio sin mejorar el comportamiento deseado.

Pide pruebas y analiza el impacto de cada hallazgo. Prioriza los problemas de corrección y los requisitos no cumplidos, investiga las afirmaciones dudosas y mantén las mejoras no relacionadas fuera de la comparación actual. Un revisor debe ser capaz de informar de que no hay hallazgos que requieran acción cuando las pruebas respalden esa conclusión.