{"id":4701,"date":"2026-08-20T09:17:45","date_gmt":"2026-08-20T07:17:45","guid":{"rendered":"https:\/\/davidperezgar.com\/?p=4701"},"modified":"2026-08-20T09:17:51","modified_gmt":"2026-08-20T07:17:51","slug":"claude-code-como-empleado-24-7-como-lo-adapto-a-wordpress","status":"publish","type":"post","link":"https:\/\/davidperezgar.com\/es\/claude-code-como-empleado-24-7-como-lo-adapto-a-wordpress\/","title":{"rendered":"Claude Code como empleado 24\/7: c\u00f3mo lo adapto a WordPress"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Llevo meses usando Claude Code a diario y esta semana he escuchado un episodio que me ha hecho replantearme c\u00f3mo tengo montados los repos. Es un episodio en solitario de <a href=\"https:\/\/www.gregisenberg.com\/\" target=\"_blank\" rel=\"noopener\">Greg Isenberg en The Startup Ideas Podcast<\/a>, patrocinado por Anthropic, donde monta en directo lo que \u00e9l llama un \u00abempleado de IA\u00bb.<\/p>\n\n\n\n<figure class=\"wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio\"><div class=\"wp-block-embed__wrapper\">\n<iframe loading=\"lazy\" title=\"Claude Code New Features, Explained\" width=\"500\" height=\"281\" src=\"https:\/\/www.youtube.com\/embed\/SkY-tR9kf-k?feature=oembed\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen><\/iframe>\n<\/div><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Resumo lo que cuenta y luego te explico las dos cosas que yo cambio para que esto encaje en repos de WordPress, que es donde trabajo yo y donde el planteamiento original se queda un poco corto.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">La idea de fondo: tratar a Claude como a alguien que acaba de entrar<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La premisa de Greg es sencilla y funciona: dale a Claude lo mismo que le dar\u00edas a una persona que se incorpora a tu equipo. Un sitio donde trabajar, contexto del negocio, un briefing antes de tocar nada, una tarea concreta, ojos para comprobar su propio trabajo, una revisi\u00f3n contra tus est\u00e1ndares, unas tareas recurrentes y unos permisos claros.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Lo monta todo en directo sobre una idea que saca de ideabrowser.com, un responder de leads perdidos para cl\u00ednicas de est\u00e9tica. Da igual el caso, lo interesante es la estructura.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Las nueve piezas, en corto<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li class=\"\"><strong>Workspace.<\/strong> El repo. Carpetas para el producto, el contexto de negocio, las notas de cliente, las especificaciones, las demos y las tareas recurrentes. M\u00e1s tres ficheros ra\u00edz: claude.md (c\u00f3mo trabajas), roadmap.md (qu\u00e9 importa ahora) y review.md (cu\u00e1ndo algo est\u00e1 bien).<\/li>\n\n\n\n<li class=\"\"><strong>Briefing.<\/strong> Plan mode antes de editar. Que lea el contexto, proponga enfoque, liste ficheros a tocar y riesgos, y espere aprobaci\u00f3n. Medir dos veces, cortar una.<\/li>\n\n\n\n<li class=\"\"><strong>Ticket.<\/strong> Una tarea, una meta visible, un cambio revisable. \u00abMejora la app\u00bb no es un ticket. \u00abA\u00f1ade un formulario de lista de espera con estado de \u00e9xito\u00bb s\u00ed.<\/li>\n\n\n\n<li class=\"\"><strong>Ojos.<\/strong> Que abra la app en el preview, haga clic por el flujo, mire consola y red, y te diga qu\u00e9 entender\u00eda un cliente en cinco segundos. Esta parte casi nadie la usa y es la que m\u00e1s cambia el resultado.<\/li>\n\n\n\n<li class=\"\"><strong>Revisi\u00f3n.<\/strong> Primero la tuya en el diff, buscando lo que sobra. Despu\u00e9s la de Claude contra review.md, separando en \u00abhay que arreglar\u00bb, \u00abconvendr\u00eda arreglar\u00bb y \u00abse puede publicar\u00bb.<\/li>\n\n\n\n<li class=\"\"><strong>Horario.<\/strong> Las routines. Un brief cada ma\u00f1ana, una revisi\u00f3n de issues los viernes, una revisi\u00f3n autom\u00e1tica de cada pull request.<\/li>\n\n\n\n<li class=\"\"><strong>Agentes en paralelo.<\/strong> Sesiones separadas con aislamiento por worktree, cada una con un encargo distinto y un entregable claro.<\/li>\n\n\n\n<li class=\"\"><strong>Permisos.<\/strong> Tres niveles: lo que puede hacer solo, lo que tiene que preguntar y lo que se queda en manos de una persona.<\/li>\n\n\n\n<li class=\"\"><strong>Skills, conectores y hooks.<\/strong> Lo repetible se convierte en skill, los conectores le dan contexto externo y los hooks ponen las barreras alrededor del trabajo.<\/li>\n<\/ol>\n\n\n\n<figure class=\"wp-block-image alignwide size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1082\" height=\"604\" src=\"\/wp-content\/uploads\/2026\/10\/Guia_para_Asistente_de_IA-1082x604-1.avif\" alt=\"Gui\u0301a para Asistente de IA\" class=\"wp-image-4918\" title=\"\"><figcaption class=\"wp-element-caption\">El sistema completo de un vistazo: el cerebro del repo, el ciclo de trabajo y los tres niveles de permisos.<\/figcaption><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Mi primer cambio: toda la documentaci\u00f3n en \/docs<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Aqu\u00ed es donde me separo del planteamiento original. Greg propone colgar \/context, \/customers, \/specs, \/demos y \/routines directamente en la ra\u00edz. En un proyecto que nace de cero y vive en Vercel, vale. En un plugin de WordPress, eso es ensuciar el repo.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Piensa en c\u00f3mo es la ra\u00edz de un plugin: el fichero principal con la cabecera, readme.txt, composer.json, package.json, phpcs.xml.dist, phpunit.xml.dist, .distignore, la carpeta .github con los workflows, includes, assets, languages. Meterle cinco carpetas m\u00e1s de documentaci\u00f3n en ese nivel hace dos cosas malas. La primera, que cuesta encontrar lo que importa. La segunda, y esta es la seria, que si no lo excluyes bien acaba en el ZIP que se sube al directorio de WordPress.org.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">As\u00ed que todo lo que sea documentaci\u00f3n para agentes se va a una sola carpeta:<\/p>\n\n\n\n<div class=\"cbc-code-wrapper\"><div class=\"cbc-code-bar\"><button class=\"cbc-copy-button\">Copy<\/button><\/div><pre class=\"wp-block-code\"><code class=\"\">mi-plugin\/\n\u251c\u2500\u2500 AGENTS.md\n\u251c\u2500\u2500 CLAUDE.md\n\u251c\u2500\u2500 REVIEW.md\n\u251c\u2500\u2500 mi-plugin.php\n\u251c\u2500\u2500 readme.txt\n\u251c\u2500\u2500 includes\/\n\u251c\u2500\u2500 assets\/\n\u2514\u2500\u2500 docs\/\n    \u251c\u2500\u2500 roadmap.md\n    \u251c\u2500\u2500 context\/\n    \u2502   \u251c\u2500\u2500 product.md\n    \u2502   \u251c\u2500\u2500 decisions.md\n    \u2502   \u2514\u2500\u2500 daily-brief.md\n    \u251c\u2500\u2500 specs\/\n    \u251c\u2500\u2500 routines\/\n    \u2514\u2500\u2500 customers\/<\/code><\/pre><\/div>\n\n\n\n<p class=\"wp-block-paragraph\">Una regla que sigo sin excepciones: carpetas y nombres de fichero siempre en ingl\u00e9s. Si ma\u00f1ana entra en el repo alguien de fuera o una herramienta nueva, <code>docs\/customers\/<\/code> se entiende en cualquier sitio y <code>docs\/clientes\/<\/code> no. Es lo mismo que ya hacemos con los nombres de funciones y de hooks, no veo motivo para cambiar de criterio con la documentaci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Con el contenido el criterio es todav\u00eda m\u00e1s simple: repo privado, en espa\u00f1ol; repo p\u00fablico, en ingl\u00e9s. Los proyectos de la agencia los lee mi equipo y nadie m\u00e1s, as\u00ed que escribir el contexto de negocio en espa\u00f1ol va m\u00e1s r\u00e1pido y sale m\u00e1s preciso. En cuanto el repo es p\u00fablico entra cualquiera desde cualquier parte, y ah\u00ed el ingl\u00e9s no es una preferencia, es lo que hace que la documentaci\u00f3n sirva de algo.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Y esto hay que dejarlo escrito en el <code>AGENTS.md<\/code>, no darlo por hecho. Una l\u00ednea del tipo \u00abtoda la documentaci\u00f3n de este repo se escribe en ingl\u00e9s\u00bb evita que el agente te devuelva un fichero mezclando los dos idiomas, que es lo que pasa siempre si no se lo dices, porque t\u00fa le est\u00e1s hablando en espa\u00f1ol y \u00e9l deduce lo que puede.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La ventaja pr\u00e1ctica de tenerlo todo bajo una carpeta es que con una sola l\u00ednea lo dejas fuera de la distribuci\u00f3n. En .distignore metes <code>docs\/<\/code> y ya no viaja al ZIP. Si adem\u00e1s usas <code>git archive<\/code> para generar releases, en .gitattributes pones <code>docs\/ export-ignore<\/code> y tienes el mismo efecto. Una carpeta, una regla, sin sorpresas en el deploy a SVN.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ojo con una cosa: Claude Code no lee autom\u00e1ticamente todo lo que hay en \/docs. Lee el fichero de instrucciones de la ra\u00edz, y de ah\u00ed tira del resto. As\u00ed que la carpeta solo funciona si el fichero ra\u00edz apunta a ella de forma expl\u00edcita, con rutas concretas y una frase de cu\u00e1ndo usar cada documento. Si escribes \u00abla documentaci\u00f3n est\u00e1 en docs\u00bb, el agente unas veces la abre y otras no.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Mi segundo cambio: AGENTS.md en vez de CLAUDE.md<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">En mis repos no trabaja un solo agente. Entra Claude Code, entra Codex, a veces Copilot en un pull request, y en los repos de la comunidad puede entrar cualquiera con la herramienta que le guste. Tener un fichero que se llama <code>CLAUDE.md<\/code> y que solo entiende una herramienta no tiene mucho sentido cuando el contenido, el estilo de c\u00f3digo, los comandos de test, las reglas de WPCS, sirve para todas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>AGENTS.md<\/code> es el est\u00e1ndar abierto que se ha ido asentando para esto. Lo leen Codex, Cursor, Copilot, Zed y unos cuantos m\u00e1s. Mi fuente de verdad va ah\u00ed.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Pero aqu\u00ed hay un detalle t\u00e9cnico que conviene tener claro, porque circulan bastantes gu\u00edas que lo cuentan mal: <strong>Claude Code no lee AGENTS.md<\/strong>. Lee CLAUDE.md. No hay fallback autom\u00e1tico, aunque lleva tiempo siendo una de las peticiones m\u00e1s votadas del repositorio de Claude Code.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La soluci\u00f3n que documenta Anthropic es un CLAUDE.md de una l\u00ednea que importa el otro fichero:<\/p>\n\n\n\n<div class=\"cbc-code-wrapper\"><div class=\"cbc-code-bar\"><button class=\"cbc-copy-button\">Copy<\/button><\/div><pre class=\"wp-block-code\"><code class=\"\">@AGENTS.md<\/code><\/pre><\/div>\n\n\n\n<p class=\"wp-block-paragraph\">Y ya est\u00e1. La sintaxis <code>@ruta<\/code> de Claude Code carga el contenido de ese fichero como si estuviera escrito ah\u00ed mismo. Un fichero de una l\u00ednea, cero duplicaci\u00f3n, cero riesgo de que los dos textos se vayan separando con el tiempo. La otra opci\u00f3n es un enlace simb\u00f3lico de CLAUDE.md a AGENTS.md, que funciona igual de bien, aunque en equipos con gente en Windows me he encontrado m\u00e1s de un problema, as\u00ed que yo me quedo con el import.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si en alg\u00fan repo necesito reglas que solo apliquen a Claude Code, por ejemplo cosas de skills o de hooks que las dem\u00e1s herramientas no van a usar, las pongo debajo del import en CLAUDE.md. El resto vive en AGENTS.md.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">C\u00f3mo traduzco las carpetas a mi trabajo real<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">El nombre de las carpetas del episodio est\u00e1 pensado para una startup con clientes que llaman por tel\u00e9fono. En mi caso hay dos escenarios bastante distintos y no uso lo mismo en cada uno.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Proyecto de cliente en la agencia.<\/strong> Aqu\u00ed s\u00ed encaja casi todo tal cual. En <code>docs\/customers\/<\/code> van las actas de reuni\u00f3n, las objeciones que salen en las llamadas, el vocabulario que usa el cliente para describir su propio negocio. Eso \u00faltimo vale mucho m\u00e1s de lo que parece cuando le pides a Claude que escriba copy o que revise una landing, porque deja de escribir con mis palabras y empieza a escribir con las del sector.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Herramienta de la comunidad, tipo Plugin Check o las utilidades de revisi\u00f3n.<\/strong> Aqu\u00ed no hay clientes, hay usuarios y hay un equipo. La carpeta de customers se convierte en <code>docs\/context\/decisions.md<\/code>, donde anoto por qu\u00e9 se hizo algo de una manera y no de otra. Y el roadmap deja de ser \u00ablo que quiero esta semana\u00bb para ser \u00ablo que hay abierto y en qu\u00e9 orden\u00bb. El review.md es el que m\u00e1s me importa de los tres, porque las reglas de revisi\u00f3n de un plugin son muy concretas y son exactamente el tipo de cosa que un agente olvida entre sesiones.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Los permisos, en versi\u00f3n WordPress<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Esta parte del episodio la firmo entera, solo hay que traducir los ejemplos. Los tres niveles quedan as\u00ed en mis proyectos:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li class=\"\"><strong>Puede hacerlo solo:<\/strong> leer el c\u00f3digo, pasar PHPCS con WPCS, ejecutar PHPUnit, correr Plugin Check, trabajar en una rama peque\u00f1a, actualizar documentaci\u00f3n en \/docs, abrir un pull request en borrador.<\/li>\n\n\n\n<li class=\"\"><strong>Tiene que preguntar:<\/strong> instalar o subir dependencias de Composer y npm, tocar el proceso de build, cambiar la estructura de la base de datos, meter mano en autenticaci\u00f3n, capabilities o nonces, borrar ficheros.<\/li>\n\n\n\n<li class=\"\"><strong>Solo yo:<\/strong> el tag en SVN de WordPress.org, subir una versi\u00f3n al directorio, cualquier cosa que toque datos reales de un cliente, un cambio de seguridad que ya est\u00e9 en producci\u00f3n.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">La frase del episodio que m\u00e1s me ha gustado es que los permisos son una estrategia, no un obst\u00e1culo. Cuanto mejor est\u00e1 el review.md y m\u00e1s peque\u00f1os son los tickets, m\u00e1s margen le puedes dar. Al rev\u00e9s no funciona: dar barra libre con un repo sin contexto es c\u00f3mo se acaba limpiando trabajo en vez de dirigi\u00e9ndolo.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Por d\u00f3nde voy a empezar con las routines<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">De todo el episodio, esto es lo que tengo menos rodado y lo que m\u00e1s curiosidad me da. La recomendaci\u00f3n de Greg es empezar por algo \u00fatil y controlado, que no toque producci\u00f3n. Un brief por la ma\u00f1ana que lea las notas y los issues abiertos y te diga la tarea del d\u00eda.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Traducido a lo m\u00edo, hay dos que voy a montar esta semana. La primera, una revisi\u00f3n autom\u00e1tica de cada pull request contra <code>docs\/review.md<\/code>, que comente solo lo que pueda provocar un bug, un problema de seguridad o un comportamiento raro, y que acabe diciendo si est\u00e1 listo para que lo mire una persona. La segunda, un repaso semanal de issues que agrupe los que hablan de lo mismo y me se\u00f1ale el arreglo con m\u00e1s recorrido. Las dos son de leer y escribir en \/docs, sin tocar c\u00f3digo, que es justo donde quiero estar mientras aprendo c\u00f3mo se comportan.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Lo que me llevo<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">El fondo del episodio no va de prompts, va de que el repo se explique a s\u00ed mismo. Y eso es una tarea de documentaci\u00f3n, algo que llevamos haciendo mal en desarrollo web desde siempre porque nunca hab\u00eda un incentivo inmediato. Ahora s\u00ed lo hay: la calidad de lo que te devuelve el agente es m\u00e1s o menos la calidad de lo que has escrito en esos ficheros.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Mis dos cambios son peque\u00f1os pero me ahorran problemas. Todo en \/docs para que la ra\u00edz siga limpia y el ZIP no se llene de markdown. Y AGENTS.md como fuente de verdad, con un CLAUDE.md de una l\u00ednea, para que cualquier agente que entre en el repo lea las mismas reglas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si tienes repos de WordPress y te animas a montarlo, cu\u00e9ntame c\u00f3mo lo has organizado t\u00fa. Y si ya tienes routines funcionando, me interesa mucho saber cu\u00e1les.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Llevo meses usando Claude Code a diario y esta semana he escuchado un episodio que me ha hecho replantearme c\u00f3mo tengo montados los repos. Es un episodio en solitario de Greg Isenberg en The Startup Ideas Podcast, patrocinado por Anthropic, donde monta en directo lo que \u00e9l llama un \u00abempleado de IA\u00bb. Resumo lo que [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4922,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":17,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-4701","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"_links":{"self":[{"href":"https:\/\/davidperezgar.com\/es\/wp-json\/wp\/v2\/posts\/4701","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/davidperezgar.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/davidperezgar.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/davidperezgar.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/davidperezgar.com\/es\/wp-json\/wp\/v2\/comments?post=4701"}],"version-history":[{"count":1,"href":"https:\/\/davidperezgar.com\/es\/wp-json\/wp\/v2\/posts\/4701\/revisions"}],"predecessor-version":[{"id":5985,"href":"https:\/\/davidperezgar.com\/es\/wp-json\/wp\/v2\/posts\/4701\/revisions\/5985"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/davidperezgar.com\/es\/wp-json\/wp\/v2\/media\/4922"}],"wp:attachment":[{"href":"https:\/\/davidperezgar.com\/es\/wp-json\/wp\/v2\/media?parent=4701"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/davidperezgar.com\/es\/wp-json\/wp\/v2\/categories?post=4701"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/davidperezgar.com\/es\/wp-json\/wp\/v2\/tags?post=4701"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}