Gabriel Neuman
Gabriel Neuman
💡 Aprendizaje14 de abril de 2026·gabrielneuman.com·Gabriel Neuman

Le instalé un cerebro al repo: Wiki Karpathy en gnbsite

Instalé el sistema de Wiki + Raw inbox tipo Karpathy en el repo de mi sitio personal. Menos ruido, más contexto, y reglas que Claude realmente sigue entre sesiones.

💡 Aprendizaje clave

Un wiki de 6 archivos cortos le da a Claude más contexto útil que 20 archivos largos que nadie mantiene.

#claude-code#wiki#karpathy#workflows#productividad

Contexto

Llevo meses peleando con lo mismo: cada sesión nueva con Claude arranca en cero. Le tengo que re-explicar qué es el proyecto, qué no tocar, cómo se llama cada cosa, a quién avisarle cuando termino algo. Y cuando trabajo en varios repos a la vez (gnbsite, Naira, 4cuadrante), el problema se multiplica.

Vi el enfoque de Andrej Karpathy: en vez de RAG, embeddings y pipelines complicados, simplemente una carpeta /wiki con markdown que el modelo lee al principio de cada sesión. Como un humano leyendo docs.

Decidí probarlo en gnbsite.

Qué hicimos

Creamos dos carpetas en el repo:

/wiki/ — 7 archivos, cortos, que Claude lee al arrancar:

  • index.md — mapa del proyecto
  • architecture.md — stack, capas, datos
  • decisions.md — por qué las cosas son como son (con campo "Aplica a" para que se use, no solo se lea)
  • dont-touch.md — archivos privados, config sensible, reglas de commit
  • glossary.md — GNB, Naira, Elias, AIDA, PDR, RFQ... términos del dominio
  • workflows.md — flujos recurrentes (publicar blog, lanzar lead magnet, delegar humano)
  • reference.md — IDs de Linear, proyecto de Harvest, canales de Slack, APIs más usadas

/raw/ — inbox para notas crudas, transcripciones, brain dumps. Ignorado por git (es privado). Claude lo procesa en la sesión siguiente y propone actualizar el wiki si hay algo útil.

Pero lo que realmente hizo click fueron tres decisiones de proceso:

  1. División clara con auto-memory. Wiki = conocimiento del repo (arquitectura, decisiones técnicas del proyecto). Auto-memory global = preferencias mías y contexto cross-proyecto. No duplicar.

  2. Documentar workflows de lanzamiento, no solo código. Un lead magnet no es "un archivo JSON", es una cadena de 7 entregables: landing, 5 emails, carrusel, post LinkedIn, Twitter, newsletter, CTAs en blog y landings. Documenté la coreografía completa para cada tipo de contenido (blog, video, podcast, diario, lead magnet) con el paso obligatorio "solo planeación hasta confirmación". Así cuando digo "lanzamos LM de NoCode en GTM", Claude sigue la receta sin preguntar qué tocar.

  3. La regla del humano olvidadizo. Si necesito que una persona haga algo, la única forma de que me acuerde es crear una tarea en Linear. Nunca dejarlo solo en el chat. Esa regla vive en workflows.md con árbol de decisión: experimento → subtarea de la tarea padre de experimentos; ventas/contenido → Growth GNB; delivery → Operaciones Agencia (Naira); técnica → label correspondiente.

Probé la regla en vivo. Claude no podía crear canales de Slack desde su MCP. En vez de dejármelo en el chat (y olvidarlo dos horas después), creó GRO-21 como subtarea de GRO-15. Funciona.

También creamos 5 pilotos en Linear (GRO-16 a GRO-20) para probar cada workflow con contenido real. Si un workflow se siente raro en la práctica, se ajusta el wiki.

Al final, empaqueté todo esto en un skill global nuevo: /wiki-init. Con un comando lo instalo en cualquier otro repo mío (Naira, 4cuadrante, lo que venga). El skill descubre el stack, pobla los archivos con datos reales, marca TODOs donde no puede inferir, y deja el CLAUDE.md con el protocolo de sesión.

Resultado

  • 7 archivos en /wiki/ con datos reales del repo (no plantillas vacías).
  • /raw/ configurado como inbox privado.
  • CLAUDE.md con protocolo de sesión: "al inicio, leer wiki/index.md".
  • Proyecto de Harvest 44442990 fijado para este repo.
  • Canales de Slack documentados (#finanzas, #reportes-gnb) y los que faltan crear anotados como tarea.
  • 1 tarea padre + 6 subtareas en Linear para probar el sistema.
  • 1 skill global nuevo (/wiki-init) listo para replicar en otros repos.

Aprendizaje clave

El valor no está en tener un wiki. Está en tener reglas de proceso que el wiki codifica: división con memoria, modo planeación antes de ejecutar, delegar a humanos solo vía Linear, y "si busqué algo 3+ veces, va al wiki". El markdown es solo el contenedor. Las reglas son lo que hace que la próxima sesión no empiece en cero.

También aprendí algo que no esperaba: documentar workflows es una forma de descubrir que tu stack ya tiene todo lo que necesitas. Cuando escribí el workflow de lead magnet, me di cuenta que ya tengo lib/newsletter/utm.ts, lib/emails/, carruseles por convención, CMS de AI para ideas. No falta infraestructura. Falta orquestación.

Próximo paso: correr los 5 pilotos y ver qué partes del workflow no aguantan el contacto con la realidad.

← Volver al DiarioVer Mi Primer Empleado de IA →