Curso Claude Code con PHP

La base: CLAUDE.md

El archivo que Claude lee al empezar cada sesión. Lo esencial de esta sección es lo que no se pone en él.

• Los tres niveles y su alcance: el suyo para todos sus proyectos, el del repositorio para el equipo, el local para sus ajustes personales sin versionar.
• Lo que sí corresponde: las convenciones del proyecto, sus trampas, las reglas de criterio.
• Lo que no corresponde: una instrucción que deba aplicarse siempre — eso es tarea de un hook — y la documentación de referencia, que se lee cuando hace falta.
• Redactar instrucciones que se sostengan: breves, imperativas, verificables, y nacidas de un error real y no de una intención.
• Lo que cuesta el archivo: ocupa contexto en cada sesión. Medirlo antes de añadir una línea.
• Arrancar con /init y corregirlo sesión tras sesión.

Las "memories"

Lo que Claude conserva de una sesión a otra, y en qué se diferencia de un CLAUDE.md.

• La distinción que lo ordena todo: la memoria se aprende sobre la marcha, el CLAUDE.md se decide y se revisa.
• Las cuatro naturalezas: quién es usted, las correcciones que ha formulado, las restricciones del proyecto, los recursos externos.
• Lo que no debe guardarse ahí: lo que el repositorio ya dice, y lo que solo es cierto durante una conversación.
• Cómo reaparece una memoria — y por qué conviene comprobarla antes de actuar: es del día en que se escribió.
• El mantenimiento: fusionar duplicados, borrar lo que ha dejado de ser cierto.

Skills

Un manual guardado aparte, que se carga solo cuando el tema aparece.

• El problema que resuelven: un CLAUDE.md que engorda cuesta en cada sesión; un skill solo cuesta el día que sirve.
• La anatomía: una carpeta, un SKILL.md, un nombre — y una descripción, que es lo que dispara la carga. Es la línea que más se cuida.
• Los alcances: skill de proyecto versionado y compartido con el equipo, skill personal, skill distribuido por un plugin.
• Invocarlo a mano o dejar que se dispare solo.
• Taller: escribir el skill de un procedimiento que usted ya repite.

Hooks

Un script ejecutado por la herramienta, no una instrucción confiada al modelo. Lo que debe ocurrir siempre vive aquí.

• Los eventos disponibles: inicio de sesión, envío de un mensaje, antes y después de una llamada a una herramienta, fin de turno.
• El cableado en settings.json, y la trampa: los hooks quedan fijados al arrancar — hay que reiniciar la sesión tras modificarlos.
• Lo que un hook sabe hacer: inyectar contexto, advertir, e incluso bloquear una llamada a una herramienta.
• Cuatro ejemplos de producción: inyectar la documentación técnica al abrir la sesión, inyectar el runbook de despliegue en cuanto se detecta una intención de puesta en producción, advertir antes de editar un archivo de infraestructura, vaciar las cachés al terminar el turno.
• Escribir, probar y depurar un hook.

Configuración entre repositorios

• Lo que se comparte entre todos sus repositorios y lo que debe quedarse en un solo proyecto.
• Las capas de ajustes — usuario, proyecto, local: cuál prevalece y dónde colocar un permiso.
• Compartir skills y hooks entre varios repositorios sin duplicarlos.
• Los plugins: entregar a un equipo un conjunto coherente de skills, hooks y comandos.
• Los servidores MCP compartidos: base de datos, navegador, seguimiento de incidencias.
• Caso concreto: dos proyectos que conviven en la misma máquina, con una infraestructura común y documentaciones que se citan entre sí.

Seguridad

• Los permisos: lo que se autoriza una vez, lo que se autoriza siempre, lo que nunca se delega.
• Los secretos: lo que no debe entrar ni en un repositorio ni en una sesión.
• Los gestos irreversibles — migraciones, borrados, producción — y la regla del acuerdo previo.
• La inyección de prompt: todo lo que viene de una página web, de una incidencia o de un archivo ajeno es un dato, nunca una instrucción.
• Revisar lo que se produce: lo que la herramienta no puede garantizar en su lugar.
• Los hooks como salvaguardas, y la trazabilidad de los cambios.