Segundo Cerebro para QE:
Jira, Confluence, Obsidian, Graphify y Claude Code

1. El Problema: Conocimiento Fragmentado

Un QA o QE senior acumula, en un año de trabajo, cientos de decisiones: por qué se diseñó un caso de una forma y no de otra, qué bug recurrente ya se investigó tres veces, qué estrategia de testing se descartó y por qué, qué edge case casi se escapa a producción.

Ese conocimiento vive disperso: tickets cerrados en Jira que nadie vuelve a leer, páginas de Confluence desactualizadas, mensajes de Slack que se pierden, y la memoria de la persona que en algún momento se va del equipo. Cada sprint nuevo repite preguntas que ya se respondieron.

El síntoma más común: volver a investigar algo que el equipo ya sabía. Un bug de timing que ya se documentó en un incidente de hace seis meses. Una estrategia de datos de prueba que ya se probó y falló. Una arquitectura de test que ya se justificó ante otro squad.

Este artículo propone un flujo concreto para dejar de perder ese conocimiento: un segundo cerebro construido con Obsidian, indexado como grafo con Graphify, consultado por Claude Code, y conectado a la operación diaria vía Jira y Confluence.

2. Qué es un Segundo Cerebro para QE

"Segundo cerebro" es un concepto de gestión del conocimiento personal: un sistema externo a tu memoria donde capturas, organizas y conectas ideas para que estén disponibles cuando las necesitás, no solo cuando las recordás. Aplicado a QE, significa un repositorio vivo de:

• Estrategias de testing que funcionaron (y las que no)
• Patrones de bugs recurrentes con su causa raíz y su fix
• Decisiones de arquitectura de pruebas con su justificación
• Postmortems e incidentes con lecciones aprendidas
• Runbooks y checklists de release, regresión y smoke test

La diferencia entre esto y una wiki tradicional es el enlace. Una wiki es un archivo de documentos aislados. Un segundo cerebro es una red: cada nota se conecta con otras notas relacionadas, y esas conexiones son las que un asistente de IA puede recorrer para responder preguntas que ningún documento individual contesta por sí solo.

3. El Stack: Rol de Cada Herramienta

Cinco herramientas, cinco capas distintas. Ninguna reemplaza a la otra: se complementan.

Obsidian y Graphify son el segundo cerebro propiamente dicho: capa personal o de equipo, de largo plazo. Jira y Confluence son la capa operacional: efímera por sprint, orientada a la ejecución. Claude Code es el puente entre ambas.

4. Arquitectura: Cómo se Conectan

El flujo de datos va en un solo sentido dominante: de la operación hacia el conocimiento, y de vuelta desde el conocimiento hacia la operación vía IA.

La regla de oro: Obsidian captura, Graphify indexa, Claude Code consulta y orquesta, Jira/Confluence ejecutan y documentan. Nadie escribe dos veces lo mismo a mano — el conocimiento fluye una vez hacia el vault, y desde ahí se reutiliza indefinidamente.

5. Capa de Captura: Obsidian como Vault

Obsidian es una app de notas en Markdown plano, local, con soporte nativo para [[enlaces internos]] y un grafo visual de conexiones. Para QE, la clave no es la herramienta: es la estructura del vault.

├── 00-MOCs/          # Maps of Content: índices por tema
│   ├── estrategias.md
│   └── bugs-recurrentes.md
├── 01-estrategias/   # Por qué se eligió cada approach
├── 02-bugs/          # Un archivo por patrón de bug, no por ticket
├── 03-incidentes/    # Postmortems con causa raíz y lección
├── 04-decisiones/    # ADRs de testing: qué se descartó y por qué
└── 05-runbooks/      # Checklists de release, smoke, regresión

Tres reglas prácticas:

• Notas atómicas: una idea por archivo. "Timeout en checkout bajo carga" es una nota; no la mezcles con "Bugs de noviembre".
• Enlazar, no copiar: si un bug de esta semana se parece a uno de marzo, enlazá [[timeout-checkout-carga]] en vez de reescribir el contexto.
• MOCs (Maps of Content): notas índice que agrupan por tema — sirven de entrada tanto para vos como para el grafo que Graphify va a construir.

El vault vive en una carpeta local versionable (podés incluso llevarlo con git). Esa carpeta es exactamente lo que Graphify va a indexar en el siguiente paso.

6. Capa de Grafo: Graphify

Graphify es una herramienta open-source (MIT) que convierte una carpeta —código o notas— en un knowledge graph que un asistente de IA puede recorrer, en vez de tener que releer archivos completos cada vez.

Lo que la distingue de un buscador semántico tradicional (embeddings + similitud vectorial):

• Graph-based, no embeddings: construye rutas explícitas entre nodos (notas, conceptos, archivos) en vez de aproximar por similitud.
• Citas reales: las respuestas vienen acompañadas de referencias concretas — en un vault de QE, eso significa "esta afirmación viene de 02-bugs/timeout-checkout.md", no una alucinación.
• On-device: corre localmente, sin cuentas ni API keys, sin enviar el contenido del vault a un tercero. Relevante si tu vault contiene información de incidentes de producción o datos sensibles del negocio.

El resultado práctico: en vez de preguntarle a Claude Code "¿tenemos algo sobre timeouts?" y que tenga que abrir carpetas a ciegas, el grafo ya sabe qué notas están conectadas a "timeout", qué incidentes las mencionan y qué estrategia de testing las cubre.

7. Capa de IA: Claude Code sobre el Grafo

Con el vault indexado, Claude Code deja de ser un asistente sin memoria entre sesiones y pasa a tener acceso a todo el historial de decisiones de QE del equipo. Usos concretos:

• Diseño de casos de prueba: "generá los casos de regresión para el módulo de pagos" — Claude Code consulta el grafo, encuentra el incidente de timeout de marzo y la estrategia de datos de prueba descartada, y los incorpora al diseño en vez de partir de cero.
• Análisis de cobertura: cruza qué patrones de bug documentados en el vault no tienen un caso de prueba asociado en Jira.
• Redacción de test plans: arma el borrador de Confluence citando las decisiones (ADRs de testing) ya tomadas, en vez de reinventar el approach.
• Onboarding: alguien nuevo en el equipo le pregunta a Claude Code "¿por qué probamos así el checkout?" y obtiene la respuesta con la nota y el enlace exacto, no una explicación de pasillo que se pierde.

La diferencia frente a "pegarle todo el vault en el contexto" es la eficiencia y la trazabilidad: el grafo sirve subconjuntos acotados y con cita de origen, en vez de forzar a releer (o resumir con pérdida) cientos de notas en cada consulta.

8. Capa Operacional: Jira + Confluence

Jira y Confluence siguen siendo el lugar donde vive la ejecución del sprint — no reemplazamos nada de eso, lo conectamos al segundo cerebro.

• Jira: historias de usuario, criterios de aceptación, casos de prueba vinculados, bugs con severidad y estado. Es el "qué se está haciendo ahora".
• Confluence: test plans del sprint, reportes de resultados de release, actas de retro. Es la "documentación compartida del momento".

La conexión con el segundo cerebro ocurre en dos direcciones:

1. Jira/Confluence → Obsidian: cuando un incidente se resuelve o un test plan deja una lección reutilizable, se destila en una nota atómica del vault (no se copia el ticket entero — se extrae la decisión o el patrón).
2. Obsidian/Graphify → Jira/Confluence (vía Claude Code): al planificar el próximo sprint, Claude Code consulta el grafo para proponer casos de prueba y redactar el test plan con contexto histórico ya incorporado.

Con MCP servers de Jira y Confluence conectados a Claude Code, este flujo se vuelve conversacional: pedís "creá los tickets de regresión en Jira para el módulo X basándote en los incidentes documentados" y la creación de tickets, la consulta al grafo y la redacción ocurren en la misma sesión.

9. Orquestación en un Sprint Ágil

Así se ve el flujo aplicado a las ceremonias de un sprint bajo testing ágil:

El punto clave: el vault no se actualiza una vez y se olvida. Cada retro cierra el ciclo agregando conocimiento nuevo, que vuelve a estar disponible desde el próximo refinamiento. Es el mismo principio de mejora continua del testing ágil, aplicado a la memoria del equipo en vez de solo al proceso.

10. Setup Paso a Paso

1. Crear el vault en Obsidian

Descargá Obsidian (gratis para uso personal), creá un vault nuevo y armá la estructura de carpetas descrita en la sección 5. Empezá con una nota por cada bug recurrente que ya conozcas de memoria — es la forma más rápida de poblar el vault con valor real.

2. Instalar Graphify

# Instalar vía uv (requiere Python)
uv tool install graphifyy

# Instalar el comando en tu proyecto/CLI de IA
graphify install

Verificá los comandos exactos y requisitos en graphify.com antes de instalar, ya que el proyecto puede actualizar su CLI.

3. Indexar el vault

/graphify .

Este paso construye el grafo local a partir de las notas Markdown y sus [[enlaces]]. Se re-ejecuta cada vez que el vault crece de forma significativa (por ejemplo, al cerrar cada sprint).

4. Conectar Claude Code al grafo

Con el grafo generado, Claude Code puede consultarlo directamente desde el CLI apuntando al mismo directorio del vault. Las consultas se hacen en lenguaje natural: "buscá patrones de timeout documentados" o "qué decisiones de testing tenemos sobre el módulo de pagos".

5. Sumar los MCP de Jira y Confluence

# Agregar servidores MCP oficiales/comunitarios
claude mcp add jira
claude mcp add confluence

Con esto, una misma sesión de Claude Code puede: consultar el grafo del vault, leer/crear tickets en Jira y leer/escribir páginas en Confluence. El comando exacto de instalación depende del MCP server que elijas (Atlassian ofrece uno oficial); revisá su documentación antes de conectarlo a un entorno productivo.

6. Cerrar el ciclo

Al final de cada sprint o retro, agregá al vault las notas nuevas (bugs, decisiones, lecciones) y volvé a correr /graphify . para reindexar. Ese es el hábito que sostiene el segundo cerebro en el tiempo — sin este paso, el grafo envejece y deja de reflejar lo que el equipo realmente sabe.

11. Beneficios, Límites y Buenas Prácticas

✅ Beneficios

• Menos tiempo re-investigando bugs y decisiones ya resueltas
• Onboarding más rápido para gente nueva en el equipo
• Trazabilidad real: cada afirmación de la IA cita su fuente en el vault
• El conocimiento sobrevive a la rotación de personas

⚠️ Límites

• El grafo es tan bueno como el vault: si nadie escribe notas, no hay nada que indexar
• Requiere el hábito de reindexar (paso 6 del setup) — un vault desactualizado genera respuestas desactualizadas
• No reemplaza la revisión humana: el grafo cita la fuente, pero decidir si esa fuente sigue vigente es criterio del QE

Buenas prácticas

1. Nota atómica por evento: un bug, una decisión, un patrón — no mezcles temas en un mismo archivo
2. Reindexar al cierre de sprint: convertí /graphify . en parte del checklist de retro
3. MOCs actualizados: revisá periódicamente que los índices por tema sigan reflejando la estructura real del vault
4. Privacidad: aprovechá que Graphify corre on-device para vaults con información sensible de producción

12. Conclusión

El testing ágil ya resolvió cómo ejecutar rápido dentro de un sprint. Lo que suele quedar sin resolver es qué pasa con todo lo que el equipo aprende en el camino — y ese conocimiento, sin un lugar donde vivir, se pierde entre tickets cerrados y gente que rota.

Un segundo cerebro con Obsidian, indexado con Graphify y consultado por Claude Code no reemplaza a Jira ni a Confluence: les da memoria. La operación sigue pasando por las herramientas de siempre; lo que cambia es que cada decisión, cada bug recurrente y cada postmortem queda disponible — con cita de fuente — para la próxima vez que el equipo lo necesite.

Empezá chico: una carpeta de bugs recurrentes, tres notas bien escritas, un /graphify .. El valor se acumula con el tiempo, no con la cantidad de herramientas conectadas el primer día.