Ordené mis 234 repos para que mis agentes de IA arranquen desde una sola casa

El 12 de noviembre de 2026 conté mis repos en GitHub: 234. Solo 86 tenían un push en los últimos 60 días. Los demás llevaban por lo menos dos meses quietos.

Los conté porque mis agentes no tenían un lugar fijo donde arrancar. Cinco repos hacían de “casa” al mismo tiempo, y cada uno tenía una parte del contexto.

Lo ordené en cuatro pasos, con una regla de nombres, y me quedaron 7 aprendizajes.

¿Qué es un repo central para agentes de IA?

Es el repo donde arranca toda sesión de tu agente, y desde el que abre los demás. Varias personas que trabajan con agentes lo llaman home repo: el agente siempre empieza en un repo central que tiene un puntero a cada repo, con su ruta y de dónde clonarlo.

El mío se llama gnb-meta. Guarda quién soy, cómo sueno, las cifras que puedo publicar, las decisiones con su fecha y la lista de repos. El código vive en los demás.

La versión anterior de esta idea fue un segundo cerebro de tres carpetas dentro del repo de mi sitio. Las notas que hoy leen mis agentes están abiertas en mi cerebro operativo.

¿Qué estaba mal antes de ordenar?

Me sobraban casas. Cinco repos hacían de punto de partida a la vez, y un agente que cruzaba de un repo a otro no tenía una sola fuente que le dijera dónde estaba cada cosa.

El orden ya estaba escrito. Desde octubre tenía un archivo de convenciones con las familias de repos y el mapa de renombres. Ni yo ni mis agentes lo habíamos aplicado.

¿Cómo ordené 234 repos?

En cuatro pasos: inventario, archivo, renombre y un índice por sección dentro de la casa.

1. Inventario contra GitHub. Los 234, cada uno con la fecha de su último push. Lo revisé contra GitHub ese mismo día.
2. Archivar. El agente propuso la lista y yo marqué los de clientes uno por uno. Archivé 121; con los que ya estaban archivados, quedaron 125.
3. Renombrar. 30 repos, con la regla de prefijos de abajo. GitHub redirige el nombre viejo.
4. Un índice por sección. En gnb-meta quedó la lista de repos vivos, partida en secciones: lo mío, mis productos, la agencia y las startups. Los repos de clientes van en el meta de la agencia, ns-meta, que creé en esta misma limpieza.

Archivar en GitHub no borra nada. El repo queda de solo lectura y se recupera con gh repo unarchive.

¿Cómo se nombra cada repo?

Con un prefijo que dice de quién es. Esta es la regla que quedó:

• gnb-<pieza>: mío o de mi operación.
• ns-<pieza>: interno de Neuman Solutions, mi agencia: su sitio, su meta, sus herramientas.
• cliente-<cliente>-<pieza>: hecho para un cliente de la agencia. Nunca lleva ns-.
• tkb-<pieza>: Teknobuilding.
• Producto propio o startup: su propio nombre, sin prefijo. Si crece, su meta es <producto>-meta.

La tercera regla es la que más me importa. Un repo de cliente con prefijo ns- parece interno de la agencia, y eso le pasó a mi propio agente (aprendizaje 4).

¿Cómo se ve un puntero?

Es una línea con el nombre del repo, su ruta junto a la casa y de dónde clonarlo. Así se ve la del repo de este sitio:

- gnb-website (mi sitio, Astro): ../gnb-website.
  Clónalo de github.com/gneuman/gnb-website si falta.
  Lee su CLAUDE.md antes de tocarlo.

Todos los repos viven junto a gnb-meta, en la misma carpeta. Si el agente no encuentra la ruta, la línea le dice de dónde clonarlo, y no tiene que preguntarme.

Pasados unos 20 repos, el patrón recomienda agrupar los punteros por área. Por eso el índice manda leer el archivo general y el de la sección que toca, y no cargar las demás.

¿Qué cambia dentro de la casa?

Cada carpeta tiene un contrato: qué lee, qué hace, qué entrega y quién lo revisa. La idea viene del método ICM, Interpretable Context Methodology: Folder Structure as Agent Architecture, de Van Clief y McDermott: la estructura de carpetas hace de arquitectura del agente.

En gnb-meta cada carpeta tiene un README.md con una sección de insumos que dice qué leer y qué no cargar. La de los repos cierra así:

Entrega: un repo nuevo entra con su línea en su sección, en el mismo PR que lo anuncia. Revisión: el nombre sigue la regla de abajo y la línea dice de dónde clonarlo.

Lo que se puede revisar con un script ya no lo reviso a mano: un verificador encuentra las ligas rotas, el índice de skills se genera solo y cada agente nuevo se copia de una plantilla con su contrato.

¿Qué aprendí ordenando 234 repos?

Siete cosas. Las anoté mientras trabajaba, en el mismo repo.

1. El orden ya estaba escrito y nadie lo había aplicado. El archivo de convenciones traía las familias y el mapa de renombres desde octubre. Faltaba ejecutarlo.

2. La mayoría de los repos estaba quieta. De 234, 86 tenían un push en los últimos 60 días. Archivé 121.

3. Me sobraban casas. Cinco repos hacían de casa a la vez. Quedó una.

4. El prefijo engañó a mi propio agente. Un repo con prefijo ns- parecía interno de la agencia y era el meta de un cliente, compartido con él. Lo detectamos al abrirlo, antes de escribir nada adentro, y lo renombré con el prefijo cliente-.

La lección: antes de escribir en un repo, ábrelo y lee qué tiene. El nombre es una pista y puede estar mal, igual que las reglas que encontré falsas en mi CLAUDE.md.

5. Separa internos y clientes por prefijo antes que por organización. El prefijo es barato y se revierte con un renombre. Una organización de GitHub aparte conviene cuando el equipo necesita ver solo los repos de sus clientes.

6. Hay nombres que el código usa. Mi repo calls recibe escrituras del CRM por API. Ese se renombra junto con su código, en el mismo cambio, y por eso quedó para una segunda tanda.

7. El que decide qué se archiva es el dueño. El agente propuso la lista. Los repos de clientes los marqué yo, uno por uno.

¿Cómo armo mi repo central en una tarde?

Empieza por contar. Estos son los cinco pasos en el orden en que los haría otra vez:

1. Lista tus repos con su último push. gh repo list <tu-usuario> --limit 300 --json name,pushedAt,isArchived te da el inventario en un comando.
2. Marca lo quieto y decide tú. Que el agente proponga qué archivar; lo de clientes lo revisas repo por repo.
3. Escribe la regla de nombres antes de renombrar. Un prefijo por dueño: lo tuyo, lo interno de tu empresa, lo de cada cliente.
4. Crea la casa. Un repo sin código, con un AGENTS.md que diga “arranca aquí” y un índice con un puntero por repo. Mi CLAUDE.md solo apunta a ese AGENTS.md.
5. Dale contrato a cada carpeta. Qué lee, qué entrega y quién lo revisa, escrito en su README.md.

Si quieres armar algo así para tu equipo y no sabes por dónde empezar, en el diagnóstico de 15 minutos vemos qué proceso conviene atacar primero.