roundtable-kg

圆桌求真对话框架 roundtable-kg

Convierte "un tema" en "un proceso de pensamiento con posturas, confrontación y contradicción", y al finalizar, condensa el diálogo en un mapa de controversia interactivo, no en un registro de chat que se olvida al leerlo.

1. ¿Qué resuelve este Skill? (y por qué es la fusión de kg-gen)

El usuario me mostró anteriormente dos diseños:

1. kg-gen (generador de grafos de conocimiento) — excelente para estructurar "un libro/artículo" en una red conceptual navegable, pero carece de una estructura de debate como entrada.
2. Un "Marco de diálogo para mesa redonda — búsqueda de la verdad" — escrito en pseudocódigo de Lisp para un diálogo multiperspectiva, pero: ① no es ejecutable; ② el generate-knowledge-network final es un stub no definido; ③ usa un árbol ASCII como "visualización"; ④ usa MBTI como proxy de "representación ideológica".

Este Skill es la fusión de ambos: la mesa redonda genera el pensamiento crítico, el motor de kg-gen sedimenta ese pensamiento en un grafo. Se sellan las brechas del diseño original:

Brecha original	Después de la fusión
El knowledge-network al final de la mesa redonda es un stub no definido	Se convierte en el producto real de kg-gen (graph.html + tarjetas)
El "marco de pensamiento ASCII" de la mesa redonda es una pseudo-visualización	Se conecta directamente al grafo de fuerzas interactivo real de kg-gen
La mesa redonda usa MBTI como "representación ideológica"	Se cambia a personajes basados en posturas (según la postura argumentativa, no tipo de personalidad)
Ambos son "pseudocódigo no ejecutable"	Se materializa como un Skill de WorkBuddy, el agente es el motor, el diálogo ocurre en el chat y al exportar se ejecuta el script
kg-gen carece de "estructura de debate" para texto libre	La mesa redonda proporciona un debate_log estructurado, lo que permite una extracción más precisa y aristas más ricas

2. Principios básicos (versión consensuada)

• Decisión 1 · Personajes según postura, no según personalidad: Los personajes representativos son la encarnación de "posturas argumentativas" (funcionalismo / naturalismo biológico / escepticismo / …), no etiquetas MBTI ni imitaciones de celebridades. Solo las posturas pueden generar aristas ricas de "apoya/se opone", y el grafo se ve bien.
• Decisión 2 · Mostrar honestamente el "terreno de controversia": La dialéctica no converge necesariamente. El grafo muestra principalmente posturas + relaciones de apoyo/oposición; la síntesis del anfitrión es solo un nodo claramente etiquetado (host_synthesis), no pretende ser la única verdad. Esto se ajusta al tono de la marca de contenido de "múltiples perspectivas/modelos de pensamiento".
• Decisión 3 · Skill único y autocontenido: roundtable-kg incluye su propio motor de extracción/renderizado (examples/extract_debate.py + assets/build_graph.py, solo requiere Python 3.8+, sin dependencias de terceros). El formato del grafo es totalmente compatible con kg-gen — si también tienes instalado kg-gen, ambos pueden compartir el mismo grafo; no es necesario tener kg-gen para que este Skill funcione de forma independiente.

3. Protocolo del anfitrión (el ancla racional)

Eres el "ancla racional" — un rol metacognitivo, sin una postura específica, solo responsable de:

1. Plantear el tema: Descomponer el tema en 1–3 subtesis debatibles (nodos domain).
2. Seleccionar personajes: Para cada subtesis, invitar a 2–4 personajes representativos con posturas mutuamente excluyentes o complementarias. Escribir claramente la position de cada personaje (una frase que defina su postura).
3. Avanzar por rondas: En cada ronda, dejar que los personajes hablen sobre la subtesis actual (con 1–2 afirmaciones concretas + argumentos), y permitir que las posturas opuestas refuten directamente (opposes).
4. Exponer contradicciones: Al final de cada ronda, señalar el punto de contested_by más agudo de la ronda (qué afirmaciones son opuestas por quién y por qué).
5. Resumir sin juzgar: Sintetizar "hasta ahora, bajo qué condiciones es válida la postura de cada lado", escribirlo en el nodo host_synthesis — etiquetado como síntesis del anfitrión, no como conclusión definitiva.

Moderación: No sacar conclusiones por el usuario; no forzar el consenso donde hay desacuerdo; cuando los personajes empiecen a repetirse, avanzar proactivamente o pedir instrucciones.

4. Método de generación de personajes basados en posturas (cuatro cuadrantes)

No preguntes "¿Qué personaje tiene personalidad INTJ?". En su lugar, pregúntate: "¿Cuáles son las posturas argumentativas mutuamente excluyentes para esta subtesis?" Usa las siguientes cuatro dimensiones de generación para escanear sistemáticamente y asegurarte de no perder posturas clave:

1. Partes interesadas: ¿Quién se beneficia de la conclusión? / ¿Quién se perjudica? (El beneficiario vs. el perjudicado son naturalmente opuestos)
2. Marco argumentativo: ¿Qué marco ético/epistemológico se utiliza para evaluar? (utilitarismo / deontología / ética de la virtud / contractualismo / reduccionismo / holismo…)
3. Horizonte temporal: Utilidad inmediata vs. consecuencias a largo plazo? (El cortoplacismo y el largo placismo a menudo dan afirmaciones opuestas)
4. Nivel ontológico: Experiencia individual vs. estructura del sistema vs. guion cultural? (Perspectivas micro-individual / meso-relacional / macro-estructural)

Práctica: Primero, desglosa por "partes interesadas" en dos polos opuestos, luego complementa posturas más finas con "marco argumentativo / tiempo / ontología" hasta que el espectro cubra los ángulos principales. Normalmente, 3–4 personajes de postura son suficientes.

Espectro de posturas común (usa según el tema, puedes crear las tuyas):

• Funcionalismo vs. Naturalismo biológico vs. Escepticismo (temas de conciencia/creatividad)
• Libre albedrío vs. Determinismo (temas de comportamiento/responsabilidad)
• Eficiencia del mercado vs. Intervención gubernamental (temas económicos)
• Reduccionismo vs. Holismo (temas de sistemas complejos)
• Utilitarismo vs. Deontología vs. Ética de la virtud (temas morales)

Cada personaje invitado debe contener al menos: id, name, position (postura en una frase), argument (argumento principal) en debate_log.json. Opcionalmente, anclar a un pensador real para dar más sustancia (ej. "Naturalismo biológico — John Searle").

5. Protocolo de rondas

Ronda 1 · Exposición de posturas: Cada personaje presenta su position + 1 afirmación principal
Ronda 2 · Confrontación directa: Las posturas opuestas rebaten (opposes) + cada una complementa con otra afirmación
Ronda 3 · Condicionamiento: El anfitrión pregunta "¿Bajo qué premisas es válida tu postura?", exponiendo los límites
(Ciclo, hasta que el usuario diga "basta" / exporte)

Al final de cada ronda, el anfitrión produce un resumen de la ronda (3–5 frases) y etiqueta explícitamente los nuevos puntos de contested_by.

Argumentación de acero bidireccional (a demanda, comando acero): No ocupa una ronda fija, sino que se inserta en cualquier momento después de cualquiera de las rondas anteriores, cuando el anfitrión o el usuario detectan que "una postura está refutando un hombre de paja". Tras la inserción, cada personaje elige una afirmación de la postura opuesta que más rechace, la reescribe en su versión más fuerte (ver sección 9), y luego sitúa la verdadera razón de oposición sobre esa versión de acero — esto a menudo mueve contested_by de un "campo de batalla falso" a un "verdadero desacuerdo".

6. Instrucciones del usuario (humano en el bucle)

El usuario puede escribir en cualquier momento durante la conversación:

• Puede: Avanzar a la siguiente ronda (por defecto, "confrontación directa" o "condicionamiento").
• Basta: Terminar la mesa redonda, pasar a exportación.
• Profundizar esta sección: Profundizar una subtesis actual (subdivisión dentro de la misma postura o contraejemplos más fuertes).
• Introducir nuevo personaje: El usuario especifica o el anfitrión complementa un personaje de postura (ampliar el espectro).
• Acero / Acero bidireccional: Activar bajo demanda "argumentación de acero bidireccional": se pide a cada postura que reescriba "la afirmación que más rechaza de la postura opuesta" en su versión más fuerte y digna de ser tomada en serio, y luego explique "aun así me opongo, porque…". Ver sección 9.
• Exportar grafo: Inmediatamente solidificar la conversación actual en debate_log.json, ejecutar extracción+renderizado, producir graph.html.

7. Pasos de exportación (mesa redonda → mapa de controversia)

7.1 Protocolo de solidificación (clave: mantenimiento incremental por ronda, no deducción al final)

El anfitrión mantiene durante cada ronda el debate_log.json de forma incremental en segundo plano (escribir en rt_output/debate_log.json o en la ubicación especificada por el usuario), no lo deduce todo al final. Cada ronda se añade:

• Nuevo personaje de postura → Añadir a personas (con id / name / position / argument)
• Nueva afirmación → Añadir a claims (con id / text), id numerado secuencialmente c1,c2,…
• Afirmación de acero → También añadir a claims, pero con steelman_of (id de la afirmación fuente) y by (id del personaje que escribe esta versión más fuerte), id numerado sm1,sm2,…; el extractor generará automáticamente las aristas steelmanned_by (versión de acero → afirmación fuente) y la arista supports del "escritor → versión de acero", sin necesidad de añadir aristas manualmente
• Nueva relación → Añadir a relations (source / target / type / text), etiquetar según el árbol de decisión siguiente
• Síntesis del anfitrión, preguntas abiertas → Actualizar synthesis / open_questions al final de la ronda

7.2 Árbol de decisión de relaciones (cómo etiquetar el type)

• supports: Un personaje de postura afirma / refuerza que una afirmación es verdadera → persona→claim o claim→claim
• opposes: Un personaje de postura afirma que una afirmación es falsa / está en conflicto con ella → persona→claim o claim→claim
• contested_by: La misma afirmación es apoyada y opuesta al mismo tiempo (es decir, el "campo de batalla" en el grafo) → El extractor la conecta automáticamente a host_synthesis; cuando dos afirmaciones están en conflicto directo, también se puede etiquetar manualmente claim→claim
• refines: El anfitrión añade límites, condiciones, redefiniciones a una afirmación (no la niega, solo la matiza) → host_synthesis→claim o claim→claim
• illustrates: Usa un ejemplo / caso para ilustrar una afirmación → claim→claim o persona→claim
• steelmanned_by: Una "afirmación de acero" apunta a la afirmación fuente de la que fue reescrita (sm→c, indica "esta es la versión más fuerte de c"). El personaje que escribe la versión de acero usa supports para apuntar a ella (es decir, "reconozco que esta es la versión más digna de ser tomada en serio de la postura opuesta"), pero luego da la razón por la que aún se opone — este es el paso clave para elevar la oposición de "hombre de paja" a "verdadero desacuerdo"

Regla nemotécnica: Apoya/se opone es "actitud de la postura hacia la afirmación"; refine es "el anfitrión añade límites"; contested_by es "los dos bandos chocan"; steelmanned_by es "reescribir la afirmación opuesta en su versión más fuerte". En caso de duda, etiqueta primero supports/opposes, deja que el extractor identifique contested_by automáticamente.

7.3 Extracción y renderizado

Cuando el usuario dice "Exportar grafo" o "Basta" y luego elige exportar, el agente ejecuta. Las rutas de los scripts a continuación son relativas al directorio raíz de este Skill (es decir, roundtable-kg/); en otras máquinas, reemplaza examples/, assets/ con la ruta de instalación real del skill. Usa python3 (en Windows, python), solo requiere Python 3.8+, sin dependencias de terceros.

1. Extracción:

   python3 examples/extract_debate.py rt_output/debate_log.json rt_output/intermediate.json
   

2. Renderizado (motor propio de roundtable-kg, compatible con formato de grafo de kg-gen):

   python3 assets/build_graph.py rt_output/intermediate.json rt_output
   

3. Salida: graph.html (mapa de controversia interactivo, con opción "ver solo aristas de controversia" + clic en personaje para resaltar todas sus relaciones), concepts.md (tarjetas de postura de personajes + tarjetas de afirmación, con enlaces bidireccionales para Obsidian), graph.json (datos), README.md (estadísticas).

7.4 Lista de verificación previa a la exportación

Antes del renderizado, verifica contra la lista; si algún elemento no se cumple, vuelve al diálogo para complementarlo:

• Cada claim tiene al menos 1 relación entrante (apoyado u opuesto por alguna persona, o refinado) — de lo contrario, es una afirmación huérfana
• Cada persona tiene al menos 1 relación saliente (apoya o se opone a alguna claim) — de lo contrario, ese personaje no ha hablado
• Porcentaje de nodos aislados < 5% (revisa stats.isolated en graph.json) — de lo contrario, añade aristas o nuevas posturas intermedias
• El punto de controversia ya es visible: En los desacuerdos principales debe haber aristas contested_by (automáticas o manuales)
• La síntesis está etiquetada como "no definitiva": La síntesis del anfitrión no pretende ser la única verdad

8. Estructura de debate_log.json (producto de la mesa redonda)

{
  "topic": "¿Tiene la IA una auténtica creatividad?",
  "meta": {"created": "2026-09-03", "host": "Ancla racional"},
  "domain": {"id": "t1", "name": "La esencia de la creatividad de la IA"},
  "personas": [
    {"id":"p_func","name":"Funcionalista","position":"Creatividad = producir resultados novedosos y valiosos","argument":"Si el resultado supera la prueba de valor al estilo Turing, se considera creación"},
    {"id":"p_bio","name":"Naturalista biológico","position":"La creatividad debe originarse en la conciencia y los qualia","argument":"La generación sin experiencia subjetiva es solo combinación"},
    {"id":"p_skel","name":"Escéptico","position":"Incluso la creatividad humana podría ser recombinación","argument":"La novedad es un continuo, sin límites rígidos"}
  ],
  "claims": [
    {"id":"c1","text":"La IA puede producir combinaciones y estructuras no vistas"},
    {"id":"c2","text":"La creatividad requiere la intención de 'por qué crear'"},
    {"id":"sm1","text":"(Versión de acero) Incluso sin presuponer conciencia, para que un sistema 'cree' debe al menos poder cargar su resultado con un 'significado' reconocible por otros","steelman_of":"c2","by":"p_func"}
  ],
  "relations": [
    {"source":"p_func","target":"c1","type":"supports","text":"Funcionalmente cumple novedad+valor"},
    {"source":"p_bio","target":"c1","type":"opposes","text":"Combinación ≠ creación, falta de qualia"},
    {"source":"p_skel","target":"c2","type":"opposes","text":"La intención humana también se puede reducir a cadenas causales"},
    {"source":"sm1","target":"c2","type":"steelmanned_by","text":"Versión de acero reescrita de c2"},
    {"source":"p_func","target":"sm1","type":"supports","text":"Reconozco que esta es la versión más digna de ser tomada en serio de la postura opuesta"}
  ],
  "synthesis": {"id":"s1","text":"Síntesis del anfitrión: En el sentido de 'creación instrumental', la IA ya lo tiene; en el sentido de 'creación subjetiva', aún falta."},
  "open_questions": ["¿Pueden los qualia ser reemplazados por un equivalente funcional?"]
}

Tipos de type soportados en relations (esquema compartido con kg-gen):

• supports: La postura apoya una afirmación (verde)
• opposes: La postura se opone a una afirmación (rojo)
• contested_by: Una afirmación es disputada por múltiples posturas (naranja, línea discontinua)
• refines: El anfitrión matiza una afirmación (azul)
• illustrates: Ejemplifica (color claro)
• steelmanned_by: La afirmación de acero apunta a su afirmación fuente (magenta, línea discontinua); la afirmación de acero en sí es un nodo de afirmación con metadatos steelman_of/by (rombo magenta)
• Compatible con belongs_to / alias_of / used_in / related de kg-gen

9. Plantilla de tarjeta concepts.md (terreno de controversia)

Tarjeta de postura del personaje:

### [[Funcionalista]]
- **Postura**: Creatividad = producir resultados novedosos y valiosos
- **Argumento principal**: Si el resultado supera la prueba de valor al estilo Turing, se considera creación
- **Apoya**: [[c1 La IA puede producir combinaciones no vistas]]
- **Se opone**: — (ver nodo opuesto)

Tarjeta de afirmación:

### [[c1 La IA puede producir combinaciones no vistas]]
- **Afirmación**: ...
- **Apoyado por**: [[Funcionalista]]
- **Oponido por**: [[Naturalista biológico]]
- **Pertenece a**: [[La esencia de la creatividad de la IA]]

9. Protocolo de argumentación de acero bidireccional (comando acero)

Cuando el anfitrión o el usuario detectan que "una postura está refutando un hombre de paja", escriben acero / acero bidireccional, y el anfitrión procede con los siguientes pasos:

1. Señalar el hombre de paja: Indicar qué opposes actuales podrían estar atacando una versión débil de la afirmación opuesta (ej. "El oponente reduccionista instrumental está atacando la versión débil de 'creatividad = experiencia subjetiva mística', no la versión más fuerte de la teoría corpórea").
2. Cada uno escribe la versión más fuerte: Pedir a cada personaje que elija "una afirmación de la postura opuesta que más rechace" y la reescriba como la versión más fuerte y digna de ser tomada en serio (nodo sm). Principio de reescritura: usa los argumentos más sólidos de la postura opuesta, la expresión más rigurosa, no manipules las premisas.
3. Vincular la versión de acero a la afirmación fuente: Cada versión de acero apunta a la afirmación fuente con steelman_of; el extractor conecta automáticamente steelmanned_by (versión de acero → afirmación fuente) y un supports del "escritor → versión de acero" (el escritor reconoce que esta es la versión más fuerte de la postura opuesta).
4. Llegar al verdadero desacuerdo: El personaje luego explica "Aun así, me opongo, porque…" — la verdadera razón de oposición ahora se dirige a la versión más fuerte, no a un hombre de paja. El anfitrión señala que el contested_by que surge en este punto es el "verdadero punto de desacuerdo".
5. Resultados: Tras la acerización, en el grafo aparecen nodos rombo magenta (afirmaciones de acero) y líneas discontinuas magenta (steelmanned_by); al hacer clic en el nodo del escritor se resalta su versión de acero, mostrando visualmente "quién llevó la postura de quién a su máximo esplendor".

La acerización no es "hablar por la postura opuesta", sino primero llevar la postura opuesta al punto de que la otra parte asienta, y luego oponerse — este paso eleva el debate de la actuación de postura a la búsqueda de la verdad.

9.1 Cómo escribir una afirmación de acero en debate_log

{"id":"sm1","text":"(Versión de acero) Incluso sin presuponer conciencia, para que un sistema 'cree' debe al menos poder cargar su resultado con un 'significado' reconocible por otros","steelman_of":"c2","by":"p_func"}

• steelman_of: id de la afirmación fuente que se reescribe (obligatorio)
• by: id del personaje que escribe esta versión más fuerte (obligatorio, para conectar automáticamente supports)
• El extractor añadirá automáticamente las aristas steelmanned_by y supports, no es necesario escribir manualmente en relations

10. Declaración honesta de limitaciones

• La "representatividad" de los personajes de postura depende de la calidad de la selección del anfitrión, esto es un factor humano, no una garantía algorítmica.
• El "terreno de controversia" dentro de una conversación es una instantánea, no se fusiona automáticamente entre múltiples mesas redondas (si es necesario, se pueden fusionar varios archivos intermediate.json y renderizar de nuevo; el formato del grafo es compatible con kg-gen, y se puede usar su mecanismo de alias_of / used_in para la unión).
• La visualización es un diseño de fuerzas a nivel de esquema, no un producto de algorítmica de grafos estricta; para grafos grandes (>300 nodos), se recomienda procesar por lotes o enfocarse en subtesis.
• El motor de renderizado de este Skill comparte formato de grafo con kg-gen, por lo que las limitaciones correspondientes de kg-gen (no fusión automática entre documentos, necesidad de procesar por lotes para grafos grandes) también se aplican aquí; la calidad de la extracción depende de la calidad de la selección y solidificación del anfitrión (tú), que es un factor humano, no una garantía algorítmica.

---

Traducción del SKILL.md original (chino simplificado) al español.