Cargando la bóveda…
Cargando la bóveda…
Convertir una carpeta (código, PDFs, papers) en un grafo de conocimiento navegable que Claude consulta en lugar de leer archivo por archivo. Reduce dramáticamente el costo de tokens en preguntas de arquitectura y onboarding de proyectos heredados.
Le pedís a Claude Code que entienda tu repo. Lo que hace:
Glob para encontrar archivos relevantes → encuentra 200Read del primeroRead del segundoRead del tercero...A los 30 archivos ya quemaste la mitad del contexto y todavía no respondió tu pregunta. En un repo de 3 años, ni siquiera llegás al final.
Cada Read son tokens reales que pagás vos.
Para preguntas chicas no importa. Para preguntas de arquitectura ("¿cómo se conecta el módulo de auth con payments?") o onboarding ("explicame la app entera"), el costo es enorme.
En lugar de hacer que Claude abra archivos para entender estructura, pre-procesar el repo una vez y guardar:
Todo guardado en 2 archivos: GRAPH_REPORT.md (legible) y graph.json (serializado para queries).
Cuando Claude pregunta sobre arquitectura, lee estos 2 archivos en lugar de 200 archivos sueltos. Reducción típica: 50-70× menos tokens en queries de arquitectura.
GRAPH_REPORT.md)#Markdown navegable con:
Útil para onboarding — abrís este archivo y entendés el proyecto en 10 min.
graph.json)#Estructura serializada con nodos y aristas:
{
"nodes": [
{ "id": "lib/auth", "type": "module", "exports": [...], "summary": "..." },
{ "id": "lib/payments", "type": "module", "exports": [...], "summary": "..." }
],
"edges": [
{ "from": "api/checkout", "to": "lib/payments", "type": "import" },
{ "from": "lib/payments", "to": "lib/auth", "type": "import" }
]
}Claude lo consulta para responder queries específicas sin leer código fuente.
Reportes derivados del grafo:
# Vía uv (rápido)
uv tool install graphify
# O pipx
pipx install graphify
# O pip clásico
pip install graphifyDesde la raíz del proyecto:
graphify build .Procesa el repo, genera GRAPH_REPORT.md y graph.json en ./graphify/.
Tiempo típico:
Agregá al CLAUDE.md del proyecto:
## Estructura del proyecto
Antes de explorar archivos individuales para entender arquitectura,
**siempre** consultá:
- `./graphify/GRAPH_REPORT.md` — mapa del proyecto
- `./graphify/graph.json` — relaciones serializadas
El grafo está pre-procesado. Úsalo en lugar de hacer múltiples Read.Ahora cuando Claude tenga que responder algo de arquitectura, va al grafo primero.
Graphify entiende ~25 lenguajes (los populares):
Para cada uno entiende imports/requires y exports/declarations. La calidad varía por lenguaje (TS/Python son mejor soportados que Lua).
Te asignan un proyecto que ningún dev actual escribió. 3 años de código, sin docs.
graphify build .> Leé ./graphify/GRAPH_REPORT.md y explicame:
1. ¿Cuál es el módulo "core" del que dependen los demás?
2. ¿Cuáles son las 3 carpetas más independientes (testeables en aislamiento)?
3. ¿Hay alguna dependencia circular que indique deuda técnica?
4. ¿Qué módulos parecen ser "legacy" (nadie los importa)?
Resumime en 1 página.En 5 minutos tenés el mapa mental. Sin Graphify, esto te toma 2-3 horas leyendo carpetas.
> Quiero renombrar la función `validateOrder` en lib/orders/validate.ts.
Antes de hacerlo:
1. Consultá graph.json para ver TODOS los archivos que la importan
2. Hacé una lista de los cambios necesarios
3. Estimame el blast radius (chico / medio / grande)
4. Si es grande, proponé strategy de cambio gradual
NO empieces a editar hasta que aprobé el plan.Mucho más seguro que hacer find/replace y rezar.
Sos consultor. Te pasan un repo, tenés 1h para diagnosticarlo:
graphify build /ruta/al/repo-cliente> Soy consultor revisando este repo. Generame un reporte ejecutivo
de 2 páginas:
1. Salud general: organización, modularidad, deuda técnica visible
2. Top 5 problemas estructurales
3. Top 3 oportunidades de quick win
4. Recomendación de cambios de fondo (si los hay)
Basate principalmente en el grafo, no leas código.Reporte profesional en minutos.
Graphify no es solo para código. Tirale una carpeta de PDFs:
graphify build ./docs-cliente/Procesa los PDFs, identifica conceptos, genera grafo de referencias entre documentos.
Después:
> El cliente nos dio 40 PDFs sobre su plataforma. Leé el grafo y
proponeme un orden de lectura priorizando los documentos centrales
primero (los que más se referencian).Convertís 40 PDFs sin orden en curso secuencial coherente.
Si lo generás pero no agregás al CLAUDE.md que lo use primero, Claude va a seguir leyendo archivos. El instructivo en CLAUDE.md es crítico.
El grafo es snapshot. Si refactorizás estructura mayor, el grafo queda desactualizado. Reconstruí periódicamente o cuando el repo cambie significativamente.
El grafo es para navegación estructural, no para entender lógica fina. Para "qué hace exactamente esta función", Claude tiene que leer el código. Es complemento, no reemplazo.
El análisis estático no captura todo (imports dinámicos, monkey patching, eval). El blast radius es buena aproximación, no verdad absoluta.
Para preguntas de arquitectura, blast radius, onboarding: Graphify gana. Para búsqueda semántica en docs: RAG (Book-to-Skill, embeddings) gana. Para entender lógica detallada de una función: lectura directa gana.
Los 3 enfoques son complementarios, no sustitutos.