https://knightli.com/es/tags/hooks/ Recent content in Hooks on KnightLi Blog Hugo -- gohugo.io es Fri, 01 May 2026 03:11:27 +0800 https://knightli.com/es/2026/05/01/claude-code-hooks-mastery-guide/ Fri, 01 May 2026 03:11:27 +0800 https://knightli.com/es/2026/05/01/claude-code-hooks-mastery-guide/ <p><code>claude-code-hooks-mastery</code> es un proyecto de aprendizaje centrado en <code>Claude Code Hooks</code>.</p> <p>No es sólo una colección de guiones dispersos. Explica el ciclo de vida del gancho de Claude Code, los métodos de configuración, los patrones de script y los escenarios de automatización comunes en un solo lugar. Para las personas que quieren que Claude Code sea más controlable y más parecido a un asistente de ingeniería, vale la pena leer este tipo de material.</p> <p>Claude Code ya puede leer código, editar archivos y ejecutar comandos de forma predeterminada. Pero si desea que verifique permisos automáticamente, bloquee operaciones riesgosas, inyecte reglas de proyecto, ejecute pruebas o le recuerde las convenciones del equipo en momentos específicos, las instrucciones de chat por sí solas no son lo suficientemente estables. El valor de los ganchos es que convierten las “reglas que necesito recordarle a la IA cada vez” en un flujo de trabajo ejecutable.</p> <h2 id="qué-problemas-resuelven-los-ganchos">Qué problemas resuelven los ganchos </h2><p>Después de usar Claude Code por un tiempo, los puntos débiles comunes incluyen:</p> <ul> <li>Cada nueva sesión necesita repetir las mismas reglas del proyecto.</li> <li>Te preocupa que pueda ejecutar comandos que no debería ejecutar.</li> <li>Quieres verificaciones antes y después de la edición de archivos.</li> <li>Quiere formatear, realizar pruebas o realizar análisis de seguridad antes de confirmar</li> <li>Quieres que las convenciones del equipo sean un flujo de trabajo fijo en lugar de recordatorios verbales.</li> <li>Quiere contexto antes y después de las llamadas a herramientas para iniciar sesión o bloquear</li> <li>Quiere que tareas complejas activen subagentes o scripts dedicados</li> </ul> <p>Los ganchos están diseñados para estas &ldquo;acciones automáticas en momentos fijos&rdquo;.</p> <p>Puedes considerarlos como enlaces de eventos en el flujo de trabajo de Claude Code. Cuando se inicia una sesión, un usuario envía un mensaje, el modelo está a punto de llamar a una herramienta, finaliza una llamada a una herramienta o un agente está a punto de detenerse, Claude Code puede ejecutar los scripts que usted configuró.</p> <h2 id="los-13-eventos-del-ciclo-de-vida-del-gancho">Los 13 eventos del ciclo de vida del gancho </h2><p>Uno de los puntos principales del proyecto README es que cubre sistemáticamente los 13 eventos de gancho del Código Claude.</p> <p>Estos eventos abarcan varias etapas, desde el inicio de la sesión hasta las llamadas a las herramientas, y desde la entrada del usuario hasta la terminación del agente. Por finalidad, se pueden agrupar a grandes rasgos como:</p> <ul> <li>Inicio de sesión: inicializa el entorno e inyecta el contexto del proyecto.</li> <li>Entrada del usuario: inspeccionar indicaciones, agregar reglas y realizar auditorías</li> <li>Antes de las llamadas a la herramienta: comprobaciones de permisos, bloqueo de comandos y validación de seguridad.</li> <li>Después de las llamadas a la herramienta: registrar resultados, activar el formateo y ejecutar la verificación</li> <li>Finalización de tareas: resumir, limpiar, notificar o guardar estado</li> </ul> <p>Este diseño de ciclo de vida significa que no es necesario incluir todas las reglas en un mensaje muy largo.</p> <p>Por ejemplo, el control de permisos debe realizarse antes de las llamadas a la herramienta. Las comprobaciones de formato son mejores después de editar los archivos. La inyección de reglas del proyecto es mejor al inicio de la sesión o después de la entrada del usuario. Poner reglas en el punto de enlace correcto suele ser más confiable que meter todo en un indicador del sistema.</p> <h2 id="dónde-vive-la-configuración">Dónde vive la configuración </h2><p>Los ganchos de Claude Code generalmente se configuran a través de archivos de configuración.</p> <p>Las ubicaciones comunes incluyen:</p> <ul> <li>Configuración a nivel de usuario: <code>~/.claude/settings.json</code></li> <li>Configuración a nivel de proyecto: <code>.claude/settings.json</code></li> </ul> <p>La configuración a nivel de usuario es buena para las preferencias personales, como reglas generales de seguridad, bloqueo de comandos y rutas de registro.</p> <p>La configuración a nivel de proyecto es mejor para reglas específicas del repositorio, como qué pruebas se deben ejecutar, qué directorios no se pueden editar, cómo se manejan los archivos generados y qué comprobaciones se requieren antes de la confirmación. Si usa Claude Code en un equipo, es mejor colocar la configuración a nivel de proyecto en el repositorio. De esa manera, todos inician el proyecto con las mismas limitaciones de colaboración de IA en lugar de depender de la memoria personal.</p> <h2 id="por-qué-son-importantes-los-scripts-de-un-solo-archivo">Por qué son importantes los scripts de un solo archivo </h2><p>El proyecto enfatiza los scripts de un solo archivo &ldquo;UV&rdquo;.</p> <p>El beneficio es una implementación simple. Un único archivo Python puede declarar dependencias y ejecutarse sin mantener un entorno complejo para un enlace. Esto encaja bien con los ganchos porque muchos ganchos solo hacen una pequeña cosa:</p> <ul> <li>Comprobar si un comando está permitido</li> <li>Determinar si la ruta de un archivo es segura</li> <li>Leer las reglas del proyecto y devolvérselas a Claude.</li> <li>Escanear la salida en busca de información confidencial</li> <li>Ejecutar formateo o pruebas después de las ediciones.</li> <li>Escribir eventos en registros.</li> </ul> <p>Cuanto más pequeño sea un script de enlace, más fácil será de mantener y es menos probable que se convierta en un sistema nuevo y complicado.</p> <h2 id="qué-pueden-hacer-los-ganchos-con-la-automatización">¿Qué pueden hacer los ganchos con la automatización? </h2><p><code>claude-code-hooks-mastery</code> muestra muchas direcciones. En el trabajo real, los más comunes se encuentran a continuación.</p> <h3 id="1-control-de-permisos-y-seguridad">1. Control de permisos y seguridad </h3><p>Este es el uso más directo de los ganchos.</p> <p>Antes de que Claude Code ejecute un comando, un gancho puede inspeccionar el contenido del comando. Si contiene acciones de alto riesgo, como eliminar, restablecer, limpiar o sobrescribir, puede bloquear la ejecución o requerir confirmación manual.</p> <p>Se pueden aplicar reglas similares a las rutas de archivos:</p> <ul> <li>No modificar la configuración de producción.</li> <li>No escribir en archivos secretos</li> <li>No eliminar scripts de migración</li> <li>No tocar directorios específicos</li> <li>No ejecute comandos de red no aprobados</li> </ul> <p>Anteponer esta protección a las llamadas a herramientas es más confiable que escribir &ldquo;no realizar operaciones peligrosas&rdquo; en un mensaje.</p> <h3 id="2-inyección-de-contexto">2. Inyección de contexto </h3><p>Muchos proyectos tienen información de fondo fija:</p> <ul> <li>Pila de tecnología</li> <li>Convenciones de codificación</li> <li>Comandos de prueba</li> <li>Estrategia de ramificación</li> <li>Estructura del directorio</li> <li>Acciones prohibidas</li> <li>Reglas para archivos generados.</li> </ul> <p>Decirle esto a Claude Code manualmente cada vez es molesto y fácil de olvidar. Los ganchos pueden inyectar automáticamente el contexto necesario al inicio de la sesión o después de que el usuario envía un mensaje.</p> <p>Esto es como darle a Claude Code un manual de trabajo a nivel de proyecto. No reemplaza el README ni la documentación de desarrollo, pero ayuda a la IA a ingresar al estado correcto antes de ejecutar una tarea.</p> <h3 id="3-verificación-después-de-las-ediciones">3. Verificación después de las ediciones </h3><p>Después de que Claude Code modifica archivos, los ganchos pueden activar comprobaciones automáticamente.</p> <p>Las acciones comunes incluyen:</p> <ul> <li>Ejecutar formateo</li> <li>Ejecutar pelusa</li> <li>Ejecutar pruebas unitarias.</li> <li>Verificar errores de tipo</li> <li>Escanear archivos generados</li> <li>Validar formato Markdown o JSON</li> </ul> <p>Esto ayuda a reducir los errores de bajo nivel. Cuando la IA edita varios archivos, una verificación ligera después de la modificación puede revelar problemas antes.</p> <p>Sin embargo, los ganchos no deberían ejecutar tareas pesadas de forma predeterminada. Ejecutar el conjunto de pruebas completo después de cada cambio de archivo puede ralentizar la experiencia. Un mejor enfoque es elegir comprobaciones según el tipo de archivo, el directorio y el riesgo de la tarea.</p> <h3 id="4-validación-de-las-reglas-del-equipo">4. Validación de las reglas del equipo </h3><p>Si un equipo ya tiene convenciones claras, algunas de ellas pueden colocarse en ganchos.</p> <p>Por ejemplo:</p> <ul> <li>Confirmar formato de mensaje</li> <li>Reglas de estilo de código</li> <li>No editar directamente ciertos archivos generados</li> <li>La documentación debe actualizarse en conjunto.</li> <li>Los cambios de API deben actualizar las pruebas.</li> <li>Ciertos directorios sólo pueden ser generados por herramientas específicas Esto hace que Claude Code se parezca más a una parte del flujo de trabajo del equipo que a un asistente externo sin restricciones.</li> </ul> <p>Por supuesto, los ganchos no deberían reemplazar a la CI. Son mejores para recordatorios locales y bloqueo temprano. La validación final aún debe pertenecer a los sistemas de CI, revisión y prueba.</p> <h3 id="5-subagentes-y-tareas-dedicadas">5. Subagentes y tareas dedicadas </h3><p>El archivo README también menciona contenido relacionado con subagentes.</p> <p>Este tipo de uso es adecuado para enviar tareas complejas a flujos de trabajo más especializados. Por ejemplo, la conversación principal puede comprender el requisito, mientras que un enlace o una configuración desencadenan tareas dedicadas de verificación, auditoría, resumen o documentación.</p> <p>Para los usuarios individuales, el primer paso útil no es la compleja orquestación de agentes. Es mejor entregar primero a los ganchos acciones repetitivas, claras y de bajo riesgo. Una vez que las reglas se estabilicen, puede producirse una automatización más compleja.</p> <h2 id="línea-de-estado-y-estilos-de-salida">Línea de estado y estilos de salida </h2><p>El proyecto también cubre la línea de estado y los estilos de salida.</p> <p>Esto puede parecer un pequeño detalle de la experiencia, pero es importante para el uso a largo plazo del Código Claude. Una línea de estado puede mostrar el contexto actual, el estado de la tarea, información del entorno o sugerencias. Los estilos de salida pueden hacer que las respuestas de Claude Code se ajusten mejor a sus hábitos de trabajo.</p> <p>Si colaboras con IA en el mismo terminal todos los días, estos detalles afectan la eficiencia. Las buenas sugerencias de estado reducen los errores y le ayudan a determinar rápidamente si la sesión actual se encuentra en el proyecto, rama y entorno correctos.</p> <h2 id="no-hagas-que-los-ganchos-sean-demasiado-pesados">No hagas que los ganchos sean demasiado pesados </h2><p>Los ganchos son poderosos, pero no son el lugar para poner todo.</p> <p>Las buenas reglas son:</p> <ul> <li>Las acciones de alta frecuencia deben ser rápidas.</li> <li>El bloqueo de seguridad debe ser claro.</li> <li>La salida debe ser corta.</li> <li>Los motivos del fallo deben ser legibles.</li> <li>Los scripts deben tener una única responsabilidad.</li> <li>Las comprobaciones exhaustivas deben ser comandos explícitos o tareas de CI</li> </ul> <p>Si un enlace tarda más de diez segundos cada vez, los usuarios pronto querrán desactivarlo. Si un gancho tiene reglas de bloqueo vagas, tanto Claude Code como el usuario tendrán dificultades para entender qué hacer a continuación.</p> <p>Los ganchos son mejores para tareas con límites claros: permitir o rechazar, agregar contexto, registrar eventos, ejecutar comprobaciones ligeras y sugerir el siguiente paso.</p> <h2 id="quién-debería-usarlo">¿Quién debería usarlo? </h2><p>Si solo ocasionalmente le pides a Claude Code que edite un pequeño fragmento de código, es posible que aún no necesites estudiar los ganchos en profundidad.</p> <p>Pero este proyecto es útil si:</p> <ul> <li>Utilice Claude Code con frecuencia</li> <li>A menudo deja que la IA modifique el código del proyecto real.</li> <li>Preocupación por que la IA ejecute comandos peligrosos</li> <li>Quiere inyectar automáticamente reglas de equipo en los flujos de trabajo de IA</li> <li>Quiere que las comprobaciones se ejecuten automáticamente después de las ediciones</li> <li>Quiere convertir recordatorios repetidos en configuración</li> <li>Están creando un flujo de trabajo de codificación de IA más estable.</li> </ul> <p>Los ganchos son especialmente significativos en proyectos colaborativos. Pueden convertir parte de la experiencia del equipo en guiones en lugar de depender de que cada persona se lo recuerde a la IA manualmente.</p> <h2 id="notas-de-uso">Notas de uso </h2><p>Primero, comience con los ganchos de seguridad.</p> <p>En comparación con la automatización compleja, el bloqueo de comandos, la protección de rutas y las comprobaciones de archivos confidenciales son más fáciles de implementar y reducen el riesgo de inmediato.</p> <p>En segundo lugar, comprometa cuidadosamente las reglas a nivel de proyecto.</p> <p><code>.claude/settings.json</code> afecta a todos los que usan el repositorio. Antes de comprometer reglas, asegúrese de que no restrinjan demasiado el desarrollo normal ni dependan de rutas que solo existen en su máquina.</p> <p>En tercer lugar, mantenga la salida del gancho concisa. Claude Code consume esta salida. Si es demasiado largo, contamina el contexto. Si es demasiado vago, no guía el siguiente paso. Lo mejor es devolver sólo el juicio necesario y la siguiente recomendación.</p> <p>Cuarto, mantenga los ganchos depurables.</p> <p>Cuando los ganchos aumentan en número, los problemas pueden provenir de la configuración, los scripts, los permisos, las rutas, las dependencias o el propio Claude Code. Los registros claros facilitan mucho la depuración posterior.</p> <h2 id="referencia">Referencia </h2><ul> <li><a class="link" href="https://github.com/disler/claude-code-hooks-mastery" target="_blank" rel="noopener" >disler/claude-code-hooks-mastery</a></li> </ul> <h2 id="pensamiento-final">Pensamiento final </h2><p>El valor de &ldquo;Claude Code Hooks&rdquo; es convertir &ldquo;reglas que espero que la IA recuerde siempre&rdquo; en flujos de trabajo que realmente se ejecutan.</p> <p>Si ya utiliza Claude Code en proyectos reales, los ganchos son un paso clave desde &ldquo;un asistente de codificación que puede conversar&rdquo; hasta &ldquo;un colaborador de ingeniería limitado&rdquo;.</p> https://knightli.com/es/2026/04/23/claude-code-claude-md-rules-memory-hooks-guide/ Thu, 23 Apr 2026 10:43:40 +0800 https://knightli.com/es/2026/04/23/claude-code-claude-md-rules-memory-hooks-guide/ <p>Si usas <code>Claude Code</code> durante un tiempo, pronto notas algo: el modelo importa, pero el entorno que le das, los límites que defines y las reglas que configuras importan igual.</p> <p>Al principio, mucha gente se centra en &ldquo;cómo escribo este prompt&rdquo;. Pero cuando empiezas a usar <code>Claude Code</code> en serio, te importa más otra cosa:</p> <ul> <li>¿Sabe quién eres?</li> <li>¿Sabe cómo trabajas?</li> <li>¿Sabe qué reglas no puede romper?</li> <li>¿Sabe qué acciones requieren confirmación primero?</li> <li>¿Puede recordar esos límites con el tiempo?</li> </ul> <p>Lo que vuelve maduro a <code>Claude Code</code> no es solo la capacidad del modelo. Es que hay un sistema completo para convertir tu estilo de trabajo en estructura persistente. A alto nivel, ese sistema puede dividirse en cuatro capas:</p> <ul> <li><code>CLAUDE.md</code></li> <li><code>Rules</code></li> <li><code>Memory</code></li> <li><code>Hooks</code></li> </ul> <p>Este artículo explica las cuatro.</p> <h2 id="por-qué-la-configuración-de-entorno-importa-más-que-prompts-únicos">Por qué la configuración de entorno importa más que prompts únicos </h2><p>Puedes pensar en <code>Claude Code</code> como un asistente que contrataste.</p> <p>El primer día no le dirías solo &ldquo;ayúdame a hacer cosas&rdquo;. Le darías un manual y explicarías:</p> <ul> <li>quién eres</li> <li>qué estilo de comunicación prefieres</li> <li>qué acciones siempre requieren confirmación</li> <li>qué errores ya ocurrieron y no deben repetirse</li> <li>dónde están los documentos importantes del proyecto</li> </ul> <p>Por eso, a largo plazo, la configuración de entorno suele importar más que un prompt aislado.</p> <p>Un prompt resuelve &ldquo;qué hacemos esta vez&rdquo;. La configuración de entorno resuelve &ldquo;cómo trabajamos cada vez desde ahora&rdquo;.</p> <h2 id="capa-1-claudemd">Capa 1: <code>CLAUDE.md</code> </h2><p>Empieza por la pieza básica. <code>CLAUDE.md</code> es esencialmente un archivo de texto.</p> <p>Puedes escribir instrucciones para Claude, como:</p> <ul> <li>quién eres</li> <li>en qué trabajas</li> <li>tus preferencias de comunicación</li> <li>reglas obligatorias</li> <li>contexto especial del proyecto actual</li> <li>dónde están documentos o directorios importantes</li> </ul> <p>Cada vez que <code>Claude Code</code> arranca, este documento se inyecta automáticamente en el contexto, así que el modelo lo leerá.</p> <p>Suelo pensarlo como un &ldquo;archivo de entendimiento compartido&rdquo;, porque eso es: el acuerdo permanente entre tú y el modelo.</p> <h3 id="qué-poner-en-claudemd">Qué poner en <code>CLAUDE.md</code> </h3><p>Lo mejor para <code>CLAUDE.md</code> suele ser:</p> <ul> <li>identidad y contexto de trabajo</li> <li>preferencias de tono y salida</li> <li>reglas globales de comportamiento</li> <li>contexto de proyecto que aparece a menudo</li> <li>errores comunes y cómo evitarlos</li> </ul> <p>Por ejemplo:</p> <ul> <li>tu zona horaria</li> <li>si permites que el modelo envíe emails o mensajes directamente</li> <li>qué acciones son irreversibles</li> <li>tus hábitos con documentos y archivos</li> <li>prácticas de seguridad y límites sobre información sensible</li> </ul> <h3 id="un-principio-muy-importante-mantenerlo-conciso">Un principio muy importante: mantenerlo conciso </h3><p>Un principio clave para <code>CLAUDE.md</code>: mantenlo lo más conciso posible.</p> <p>La razón es simple: se inyecta en contexto cada vez.</p> <p>Si crece demasiado, ocupa demasiado espacio de contexto y diluye la información importante. El modelo no lo ignora, pero su atención se dispersa, así que es más probable que pase por alto reglas críticas.</p> <p>La recomendación oficial suele ser mantenerlo por debajo de <code>400</code> líneas.</p> <p>Mi hábito es aún más conservador: intento mantenerlo por debajo de <code>200</code> líneas.</p> <h3 id="alcances-comunes-de-claudemd">Alcances comunes de <code>CLAUDE.md</code> </h3><p>En la práctica, <code>CLAUDE.md</code> puede existir en distintos niveles, y esos niveles determinan su alcance.</p> <h4 id="1-nivel-de-usuario">1. Nivel de usuario </h4><p>Es el nivel global.</p> <p>Vive en tu entorno de máquina y aplica a todos los proyectos locales.</p> <p>Es buen lugar para:</p> <ul> <li>información de identidad</li> <li>preferencias generales de comunicación</li> <li>hábitos que aplican a todos los proyectos</li> <li>reglas globales de seguridad</li> </ul> <h4 id="2-nivel-de-proyecto">2. Nivel de proyecto </h4><p>Es el nivel del proyecto.</p> <p>Está dentro de un directorio de proyecto concreto y solo aplica a ese proyecto.</p> <p>Es buen lugar para:</p> <ul> <li>contexto específico del proyecto</li> <li>reglas que solo tienen sentido ahí</li> <li>explicación de la estructura de directorios</li> <li>entradas a documentos clave del proyecto</li> </ul> <h3 id="cómo-decidir-qué-nivel-usar">Cómo decidir qué nivel usar </h3><p>La regla es simple:</p> <p>Si lo escrito seguiría siendo verdad en otro proyecto, ponlo en el <code>user level</code>.</p> <p>Si deja de ser verdad al cambiar de proyecto, ponlo en el <code>project level</code>.</p> <h3 id="cómo-escribir-la-primera-versión">Cómo escribir la primera versión </h3><p>Hay dos formas comunes de empezar:</p> <h4 id="1-usar-init">1. Usar <code>/init</code> </h4><p>Puedes ejecutar <code>/init</code> directamente en la terminal y dejar que Claude escanee el proyecto para generar un <code>CLAUDE.md</code> básico.</p> <h4 id="2-dejar-que-claude-te-ayude-a-organizarlo">2. Dejar que Claude te ayude a organizarlo </h4><p>También puedes pedirle que busque cómo otras personas estructuran <code>CLAUDE.md</code>, que te haga preguntas según tu situación y organice una versión que encaje contigo.</p> <h3 id="un-hábito-práctico">Un hábito práctico </h3><p>Al colaborar con Claude, cuando notes algo que debe recordarse o que no debe fallar otra vez, puedes pedirle que lo escriba en <code>CLAUDE.md</code>.</p> <p>Antes de hacerlo, decide:</p> <ul> <li>¿es una regla global?</li> <li>¿o solo del proyecto actual?</li> </ul> <p>No lo metas todo en un único archivo.</p> <h2 id="capa-2-rules">Capa 2: <code>Rules</code> </h2><p>La siguiente capa es <code>Rules</code>.</p> <p>La diferencia principal con <code>CLAUDE.md</code> no es el formato, sino cómo se carga.</p> <p><code>CLAUDE.md</code> se lee sin importar qué haces.</p> <p>La ventaja de <code>Rules</code> es que pueden cargarse <strong>condicionalmente</strong>.</p> <p>Una regla puede cargarse solo para ciertas rutas, archivos, herramientas o escenarios.</p> <h3 id="por-qué-importa-la-carga-condicional">Por qué importa la carga condicional </h3><p>Porque el espacio de contexto siempre es escaso.</p> <p>Si todas las reglas entran al contexto todo el tiempo:</p> <ul> <li>el modelo carga más overhead</li> <li>las reglas realmente importantes se entierran</li> </ul> <p>El valor de cargar reglas bajo demanda es que el modelo ve la información correcta en el momento correcto.</p> <h3 id="cuándo-mover-reglas-desde-claudemd-a-rules">Cuándo mover reglas desde <code>CLAUDE.md</code> a <code>Rules</code> </h3><p>Suelen darse dos situaciones:</p> <h4 id="1-claudemd-se-volvió-demasiado-largo">1. <code>CLAUDE.md</code> se volvió demasiado largo </h4><p>Si empieza a pasar de <code>200</code> líneas, sigue creciendo y lo importante se diluye, toca separar reglas.</p> <h4 id="2-algunas-reglas-solo-aplican-a-rutas-concretas">2. Algunas reglas solo aplican a rutas concretas </h4><p>Si sabes que ciertas reglas solo tienen sentido para ciertos archivos, por ejemplo:</p> <ul> <li>reglas solo para scripts Python</li> <li>reglas solo para un directorio de hooks</li> <li>reglas solo para un subproyecto</li> </ul> <p>entonces pertenecen más naturalmente a <code>Rules</code>.</p> <h3 id="dónde-encajan-mejor-rules">Dónde encajan mejor <code>Rules</code> </h3><p>El caso típico es &ldquo;situación específica, ruta específica, tipo de archivo específico&rdquo;.</p> <p>Por ejemplo:</p> <ul> <li>convenciones al manejar hooks</li> <li>reglas de código para cierto tipo de scripts</li> <li>formas de trabajo que solo aplican bajo un directorio</li> </ul> <p>Mantener ese contenido en <code>CLAUDE.md</code> suele no ser rentable.</p> <h2 id="capa-3-memory">Capa 3: <code>Memory</code> </h2><p>La tercera capa es <code>Memory</code>.</p> <p>Como <code>CLAUDE.md</code> y <code>Rules</code>, también entra al contexto del modelo, pero su diferencia central es:</p> <p><code>CLAUDE.md</code> es algo que defines deliberadamente.</p> <p><code>Memory</code> se parece más a notas que Claude escribe para sí mismo durante la colaboración.</p> <h3 id="qué-entra-en-memory">Qué entra en <code>Memory</code> </h3><p>Cuando Claude juzga que algo vale la pena recordar o conservar por un tiempo, escribe esa información en <code>Memory</code>.</p> <p>Ejemplos comunes:</p> <ul> <li>una forma de trabajar que corregiste</li> <li>una preferencia nueva</li> <li>estado temporal del proyecto actual</li> <li>algo que no terminaste hoy y debes continuar mañana</li> <li>con quién colaboraste recientemente</li> <li>contexto personal aparecido hace poco</li> </ul> <p>Es conocimiento dinámico más que política de largo plazo.</p> <h3 id="diferencia-con-las-dos-primeras-capas">Diferencia con las dos primeras capas </h3><p>Una distinción simple:</p> <ul> <li><code>CLAUDE.md</code> / <code>Rules</code>: reglas explícitas, de largo plazo y tipo política</li> <li><code>Memory</code>: contexto temporal, dinámico y recién aprendido</li> </ul> <p>Si algo solo importa unos días o cambia con frecuencia, suele pertenecer a <code>Memory</code>, no a una regla permanente.</p> <h3 id="memory-también-puede-escribirse-manualmente"><code>Memory</code> también puede escribirse manualmente </h3><p>Aunque <code>Memory</code> puede mantenerse automáticamente, también puedes decirle explícitamente:</p> <ul> <li>recuerda lo que debo hacer mañana</li> <li>recuerda a quién debo hacer seguimiento</li> <li>recuerda el hito clave de este proyecto este mes</li> </ul> <p>También puedes usar <code>/memory</code> para ver, editar o borrar memorias.</p> <h2 id="capa-4-hooks">Capa 4: <code>Hooks</code> </h2><p>La última y más avanzada capa es <code>Hooks</code>.</p> <p>Todo lo anterior, incluido <code>CLAUDE.md</code>, <code>Rules</code> y <code>Memory</code>, sigue siendo guía en lenguaje natural.</p> <p>Escribes reglas y el modelo normalmente las sigue, pero primero debe interpretarlas.</p> <p>Mientras la regla viva en lenguaje natural, quedan problemas:</p> <ul> <li>el modelo puede pasarla por alto</li> <li>demasiadas reglas diluyen atención</li> <li>puede decidir que no es suficientemente importante</li> </ul> <h3 id="qué-son-realmente-hooks">Qué son realmente <code>Hooks</code> </h3><p><code>Hooks</code> ya no son instrucciones en lenguaje natural. Son scripts.</p> <p>Son lógica de enforcement a nivel programa, disparada por eventos.</p> <p>Cuando ocurre cierto evento, esa lógica corre. No se salta porque el modelo la ignore.</p> <p>Ese es su valor:</p> <p>convierten &ldquo;debería seguir esto&rdquo; en &ldquo;debe ejecutarse esto&rdquo;.</p> <h3 id="cuándo-subir-algo-a-hooks">Cuándo subir algo a <code>Hooks</code> </h3><p>Si una regla ya está escrita en <code>CLAUDE.md</code> o <code>Rules</code>, pero Claude todavía falla ocasionalmente, y el coste de fallar es real, probablemente debería ser un <code>Hook</code>.</p> <p>En simple:</p> <ul> <li>comportamiento de bajo riesgo: reglas</li> <li>comportamiento de alto riesgo: <code>Hooks</code></li> </ul> <h3 id="escenarios-típicos">Escenarios típicos </h3><p>Ejemplos obvios:</p> <ul> <li>exigir confirmación antes de enviar un email</li> <li>exigir confirmación antes de enviar mensajes Slack, Outlook o Gmail</li> <li>interceptar borrados peligrosos de archivos</li> <li>bloquear fugas de contraseñas o API keys</li> </ul> <p>Si solo están escritas como reglas, el modelo puede equivocarse algún día. Si son <code>Hooks</code>, el evento se intercepta cada vez.</p> <h3 id="puntos-de-disparo-comunes">Puntos de disparo comunes </h3><p><code>Hooks</code> pueden engancharse en distintas etapas:</p> <ul> <li>inyectar recordatorios al inicio de una conversación</li> <li>revisar condiciones antes de ejecutar una herramienta</li> <li>validar resultados después de ejecutar una herramienta</li> </ul> <p>No necesitas conocer toda la terminología formal. A menudo basta con describir claramente el requisito y preguntar a Claude si debería convertirse en hook.</p> <p>También puedes usar <code>/hook</code> para inspeccionar hooks configurados.</p> <h2 id="una-forma-práctica-de-empezar">Una forma práctica de empezar </h2><p>Recomiendo este orden:</p> <h3 id="paso-1-usa-init-para-generar-un-claudemd-básico">Paso 1: usa <code>/init</code> para generar un <code>CLAUDE.md</code> básico </h3><p>No intentes escribir un enorme documento completo desde el inicio.</p> <p>Deja que Claude escanee el proyecto y genere un punto de partida, luego itera.</p> <h3 id="paso-2-añade-cosas-mientras-trabajas">Paso 2: añade cosas mientras trabajas </h3><p>Cuando notes:</p> <ul> <li>esto debe recordarse</li> <li>este error no debe repetirse</li> <li>esta preferencia aplicará siempre</li> </ul> <p>pide a Claude que lo añada a <code>CLAUDE.md</code>.</p> <h3 id="paso-3-mueve-cosas-a-rules-cuando-claudemd-crezca">Paso 3: mueve cosas a <code>Rules</code> cuando <code>CLAUDE.md</code> crezca </h3><p>Cuando <code>CLAUDE.md</code> se alarga y el modelo no sigue todo con fiabilidad:</p> <ul> <li>¿qué reglas son globales?</li> <li>¿cuáles solo aplican a ciertas rutas?</li> </ul> <p>Mueve las segundas a <code>Rules</code> para carga condicional.</p> <h3 id="paso-4-convierte-reglas-de-alto-riesgo-en-hooks">Paso 4: convierte reglas de alto riesgo en <code>Hooks</code> </h3><p>Si una regla sigue fallando y el coste de fallar es alto, no te quedes en lenguaje natural. Conviértela en <code>Hooks</code>.</p> <p>Ahí el &ldquo;recordatorio&rdquo; se vuelve &ldquo;enforcement&rdquo;.</p> <h3 id="paso-5-deja-que-memory-maneje-estado-temporal">Paso 5: deja que <code>Memory</code> maneje estado temporal </h3><p>Para cosas que expiran, cambian a menudo o no son política permanente, no lo metas todo en <code>CLAUDE.md</code>.</p> <p>Es más limpio dejar que <code>Memory</code> guarde:</p> <ul> <li>progreso actual del proyecto</li> <li>colaboradores recientes</li> <li>preferencias recién añadidas</li> <li>planes y to-dos de corto plazo</li> </ul> <h2 id="qué-debería-guardar-cada-capa">Qué debería guardar cada capa </h2><p>Modelo mental rápido:</p> <ul> <li><code>CLAUDE.md</code>: entendimiento compartido de largo plazo, instrucciones globales, contexto base del proyecto</li> <li><code>Rules</code>: reglas especializadas cargadas por ruta o escenario</li> <li><code>Memory</code>: conocimiento dinámico, estado temporal, cosas aprendidas recientemente</li> <li><code>Hooks</code>: enforcement programático para acciones de alto riesgo</li> </ul> <h2 id="cierre">Cierre </h2><p>Mucha gente trata <code>Claude Code</code> como &ldquo;una interfaz de chat que escribe código&rdquo;. Pero al usarlo a fondo, se siente más como una estación de trabajo inteligente de largo plazo.</p> <p>La clave no es solo cómo formulas cada instrucción. Es si le diste un entorno estable, claro y acumulativo.</p> <p>Cuando construyes estas cuatro capas:</p> <ul> <li><code>CLAUDE.md</code></li> <li><code>Rules</code></li> <li><code>Memory</code></li> <li><code>Hooks</code></li> </ul> <p>la calidad de colaboración suele mejorar mucho.</p> <p>Porque ya no reexplicas desde cero quién eres, cómo trabajas y qué no debe pasar en cada sesión. Convertiste esas cosas en parte del entorno.</p> <p>Ese es el paso clave para convertir un modelo fuerte en una herramienta madura.</p>