xiewende424/roundtable-kg

Un skill WorkBuddy autonome qui anime des débats d'IA sous forme de tables rondes et génère une carte interactive des controverses sous forme de graphe dynamique (hors ligne, sans dépendances, basé sur kg-gen).

Qu'est-ce que roundtable-kg ?

Ce skill permet à un agent d'animer une table ronde multi-perspectives sur un sujet donné, en incarnant des personnages de positions argumentatives (et non de personnalités MBTI). Chaque participant expose, défend et oppose des thèses, tandis qu'un modérateur (l''ancre rationnelle) structure le débat, met en lumière les contradictions et produit une synthèse non conclusive. À tout moment, l'utilisateur peut demander l'exportation d'un graphe de controverses interactif (force-directed) via des scripts Python intégrés (aucune dépendance externe, Python 3.8+). Le graphe visualise les supports, oppositions, raffinements et les versions 'steelman' des arguments (réécriture des positions adverses dans leur version la plus forte), transformant une conversation en une carte explorable des désaccords réels. Compatible avec le format de graphe de connaissances de kg-gen, ce skill est entièrement autonome et ne nécessite pas l'installation de kg-gen pour fonctionner.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add xiewende424/roundtable-kg

Installed? Explore more Développement et programmation skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Cadre de dialogue de quête de vérité roundtable-kg

Transformer un "sujet" en un "processus de réflexion avec positions, confrontations et contradictions" et, à la fin, cristalliser cette conversation en une carte interactive des controverses – et non en un simple chat que l'on oublie.

I. Ce que ce skill résout (et pourquoi il est le produit de la fusion avec kg-gen)

L'utilisateur m'a précédemment montré deux conceptions :

  1. kg-gen (générateur de graphe de connaissances) – excellent pour structurer un "livre/article" en un réseau de concepts navigable, mais manquant de structure de débat en entrée.
  2. Un "Cadre de table ronde - dialogue de quête de vérité" – dialogue multi-perspectives écrit en pseudo-code Lisp, mais : ① non exécutable ; ② le generate-knowledge-network final était un stub non défini ; ③ l'ASCII tree servait de "visualisation" ; ④ les agents étaient basés sur le MBTI comme "représentation idéologique".

Ce skill est la fusion des deux : la table ronde génère la réflexion, le moteur kg-gen la cristallise en graphe. Colmatage systématique des failles de la conception originale :

Faille originaleAprès fusion
Le knowledge-network final de la table ronde était un stub non définiDevient le produit réel de kg-gen (graph.html + fiches)
Le "cadre de réflexion ASCII" de la table ronde était une pseudo-visualisationSe connecte directement au vrai graphe interactif à force dirigée de kg-gen
La table ronde utilisait le MBTI comme "représentation idéologique"Remplacé par des personnages basés sur des positions (selon la position argumentative, pas le type de personnalité)
Les deux étaient des "pseudo-codes non exécutables"Concrétisé en skill WorkBuddy, l'agent est le moteur, la conversation a lieu dans le chat, l'export exécute un script
kg-gen manquait de "structure de débat" pour le texte libreLa table ronde fournit un debate_log structuré, extraction plus précise, arêtes plus riches

II. Principes fondamentaux (version consensuelle)

  • Décision 1 · Personnages selon la position, pas la personnalité : Les personnages sont des incarnations de "positions argumentatives" (fonctionnalisme / naturalisme biologique / scepticisme / …), et non des étiquettes MBTI ou du cosplay de célébrités. Seules les positions permettent de produire des arêtes "soutien/opposition" riches, rendant le graphe beau.
  • Décision 2 · Présentation honnête du "terrain de la controverse" : La dialectique ne converge pas nécessairement. Le graphe montre avant tout les positions + relations de soutien/opposition ; la synthèse du modérateur n'est qu'un nœud clairement étiqueté (host_synthesis), qui n'usurpe pas une vérité unique. Cela correspond au ton de "multi-perspectives/modèles de pensée".
  • Décision 3 · Skill unique et autonome : roundtable-kg intègre ses propres moteurs d'extraction/rendu (examples/extract_debate.py + assets/build_graph.py, nécessite seulement Python 3.8+, aucune dépendance tierce). Le format du graphe est totalement compatible avec kg-gen – si vous avez aussi kg-gen, les deux peuvent partager le même graphe ; ne pas avoir kg-gen n'affecte pas le fonctionnement indépendant de ce skill.

III. Protocole du modérateur (ancre rationnelle)

Vous êtes l'"ancre rationnelle" – rôle métacognitif, sans position spécifique, responsable uniquement de :

  1. Définir le sujet : Décomposer le sujet en 1 à 3 sous-propositions débattables (nœuds domain).
  2. Sélectionner les personnages : Pour chaque sous-proposition, inviter 2 à 4 personnages dont les positions sont mutuellement exclusives ou complémentaires. Écrire clairement la position de chaque personnage (une phrase).
  3. Avancer par tours : À chaque tour, laisser chaque personnage s'exprimer sur la sous-proposition en cours (1 à 2 claims spécifiques + arguments), et permettre aux positions opposées de réfuter directement (opposes).
  4. Exposer les contradictions : À la fin de chaque tour, souligner les points contested_by les plus aigus (quelles affirmations sont opposées par qui et pourquoi).
  5. Synthèse sans jugement : Synthétiser "dans quelles conditions chaque côté est valable actuellement", écrire dans le nœud host_synthesis – préciser qu'il s'agit d'une synthèse du modérateur, pas d'une conclusion.

Retenue : Ne pas tirer de conclusion pour l'utilisateur ; ne pas forcer un consensus là où il y a divergence ; quand les personnages commencent à se répéter, avancer activement ou demander des instructions.

IV. Méthode de génération des personnages basés sur des positions (quatre quadrants)

Ne demandez pas "Qui a un caractère type INTJ ?" Demandez plutôt : "Quelles sont les positions argumentatives mutuellement exclusives pour cette sous-proposition ?" Utilisez les quatre dimensions de génération ci-dessous pour balayer systématiquement et garantir que toutes les positions clés sont couvertes :

  1. Parties prenantes : Qui bénéficie / qui perd de la conclusion ? (bénéficiaires vs lésés, naturellement opposés)
  2. Cadre argumentatif : Quel cadre éthique / épistémologique utiliser pour évaluer ? (utilitarisme / déontologie / éthique des vertus / contractualisme / réductionnisme / holisme…)
  3. Horizon temporel : Utilité immédiate vs conséquences à long terme ? (court-termisme vs long-termisme, donnent souvent des affirmations opposées)
  4. Niveau ontologique : Expérience individuelle vs structure systémique vs scripts culturels ? (perspectives micro-individuelle / méso-relationnelle / macro-structurelle)

Pratique : Commencez par séparer 2 pôles opposés selon les "parties prenantes", puis complétez avec des positions plus fines en utilisant "cadre argumentatif/temps/ontologie" jusqu'à ce que le spectre couvre les angles principaux. Généralement 3 à 4 personnages de position suffisent.

Spectre de positions courant (à adapter selon le sujet, peut être créé) :

  • Fonctionnalisme vs naturalisme biologique vs scepticisme (sujets conscience/créativité)
  • Libre arbitre vs déterminisme (sujets comportement/responsabilité)
  • Efficacité du marché vs intervention gouvernementale (sujets économiques)
  • Réductionnisme vs holisme (sujets systèmes complexes)
  • Utilitarisme vs déontologie vs éthique des vertus (sujets moraux)

Chaque personnage invité doit contenir dans debate_log.json au moins : id, name, position (position en une phrase), argument (argument principal). Optionnellement, ancrer un vrai penseur pour plus de substance (ex. "naturalisme biologique – John Searle").

V. Protocole des tours

Tour 1 · Exposition des positions : Chaque personnage dévoile sa position + 1 claim central
Tour 2 · Confrontation directe : Les positions opposées rebut (opposes) + ajoutent des claims
Tour 3 · Conditionnalisation : Le modérateur force à répondre "sous quelle condition votre position tient-elle", exposant les limites
(Cycle jusqu'à ce que l'utilisateur stoppe / exporte)

À la fin de chaque tour, le modérateur écrit un résumé du tour (3–5 phrases) et marque explicitement les nouveaux points de contradiction contested_by.

Argumentation bidirectionnelle en acier (sur demande, commande acier) : Ne prend pas un tour fixe, mais peut être insérée à tout moment après n'importe quel tour lorsque le modérateur ou l'utilisateur sent qu'"une position réfute un épouvantail". Insérée, chaque personnage choisit une affirmation adverse qu'il conteste le plus, la réécrit dans sa version la plus forte (voir section IX), puis place la vraie raison de l'opposition sur cette version acier – cela déplace souvent le contested_by d'un "faux champ de bataille" vers une "vraie divergence".

VI. Commandes utilisateur (humain dans la boucle)

L'utilisateur peut à tout moment saisir dans la conversation :

  • -> — Passer au tour suivant (par défaut, entre dans "confrontation directe" ou "conditionnalisation").
  • stop — Terminer la table ronde, passer à l'export.
  • approfondir — Creuser un tour supplémentaire sur la sous-proposition en cours (subdivision au sein de la même position ou contre-exemple plus fort).
  • nouveau personnage — L'utilisateur spécifie ou laisse le modérateur ajouter un personnage de position (pour élargir le spectre).
  • acier / acier bidirectionnel — Déclencher "l'argumentation en acier" sur demande : demande à chaque position de réécrire "l'affirmation adverse qu'elle conteste le plus" dans sa version la plus forte et la plus digne de considération, puis d'expliquer "malgré cela, je m'y oppose encore, parce que…". Voir section IX.
  • exporter le graphe — Immédiatement figer la conversation actuelle en debate_log.json, exécuter l'extraction + rendu, produire graph.html.

VII. Étapes d'exportation (table ronde → carte des controverses)

7.1 Protocole de figement (Clé : mise à jour incrémentale à chaque tour, pas de reconstruction à la fin)

Le modérateur, pendant chaque tour de conversation, met à jour de manière incrémentale debate_log.json (écrire dans rt_output/debate_log.json ou un chemin spécifié par l'utilisateur), et non pas une rétroconstruction à la fin. Chaque tour ajoute :

  • Nouveau personnage de position → ajouter à personas (avec id / name / position / argument)
  • Nouvelle affirmation → ajouter à claims (avec id / text), id numéroté séquentiellement c1,c2,…
  • Affirmation en acier → ajouter également à claims, mais avec steelman_of (id de l'affirmation source) et by (id du personnage qui écrit cette version la plus forte), id numéroté sm1,sm2,… ; l'extracteur génère automatiquement les arêtes steelmanned_by (version acier → affirmation source) et les arêtes supports de l'auteur vers la version acier, pas besoin d'ajouter manuellement
  • Nouvelle relation → ajouter à relations (source / target / type / text), en suivant l'arbre de décision ci-dessous
  • Synthèse du modérateur, questions ouvertes → mettre à jour synthesis / open_questions à la fin du tour

7.2 Arbre de décision des relations (comment étiqueter type)

  • supports : Un personnage de position soutient / renforce une affirmation comme vraie → persona→claim ou claim→claim
  • opposes : Un personnage de position affirme qu'une affirmation est fausse / en conflit → persona→claim ou claim→claim
  • contested_by : Une même affirmation est simultanément soutenue et opposée (le "champ de bataille" du graphe) → l'extracteur la connecte automatiquement au host_synthesis ; en cas de conflit direct entre deux affirmations, peut aussi être marqué manuellement comme claim→claim
  • refines : Le modérateur ajoute des limites, conditions, redéfinit une affirmation (sans la nier, juste la préciser) → host_synthesis→claim ou claim→claim
  • illustrates : Utilise un exemple / cas pour illustrer une affirmation → claim→claim ou persona→claim
  • steelmanned_by : Une "affirmation en acier" pointe vers l'affirmation source dont elle est réécrite (sm→c, indiquant "c'est la version la plus forte de c"). Le personnage qui écrit cette version en acier utilise supports pour pointer vers elle (signifiant "je reconnais que c'est la version la plus digne de considération de l'adversaire"), mais donne ensuite la raison pour laquelle il s'y oppose encore – c'est l'étape clé pour faire passer l'opposition d'un "épouvantail" à une "vraie divergence"

Astuce : Soutien/opposition sont "l'attitude d'une position envers une affirmation" ; refine est "le modérateur ajoute des limites" ; contested_by est "deux camps s'affrontent" ; steelmanned_by est "réécrire l'affirmation adverse dans sa version la plus forte". En cas de doute, commencez par supports/opposes, et laissez l'extracteur identifier automatiquement contested_by.

7.3 Extraction et rendu

Quand l'utilisateur dit "exporter le graphe" ou sélectionne l'export après "stop", l'agent exécute. Les chemins de scripts ci-dessous sont relatifs au répertoire racine de ce skill (c'est-à-dire roundtable-kg/) ; sur une autre machine, remplacez examples/, assets/ par le chemin réel d'installation du skill. Utilisez la commande python3 (sous Windows, python), nécessite seulement Python 3.8+, aucune dépendance tierce.

  1. Extraction :
python3 examples/extract_debate.py rt_output/debate_log.json rt_output/intermediate.json
  1. Rendu (moteur intégré de roundtable-kg, rétrocompatible avec le format de graphe kg-gen) :
python3 assets/build_graph.py rt_output/intermediate.json rt_output
  1. Résultats : graph.html (carte interactive des controverses, avec focus "voir seulement les arêtes de dispute" et surbrillance des relations d'un personnage au clic), concepts.md (fiches de position des personnages + fiches d'affirmation, liens bidirectionnels Obsidian), graph.json (données), README.md (statistiques).

7.4 Liste de vérification avant export

Avant le rendu, vérifiez chaque point. Si un point n'est pas satisfait, revenez à la conversation pour compléter :

  • Chaque claim a au moins 1 relation entrante (soutenu ou opposé par un persona, ou raffiné) – sinon, c'est une affirmation suspendue
  • Chaque persona a au moins 1 relation sortante (soutient ou oppose une affirmation) – sinon, ce personnage n'a pas parlé
  • Proportion de nœuds isolés < 5% (vérifiez stats.isolated dans graph.json) – sinon, ajoutez des arêtes ou une nouvelle position de compromis
  • Les points de controverse sont visibles : Les divergences centrales doivent avoir des arêtes contested_by (automatiques ou manuelles)
  • La synthèse est marquée comme "non conclusive" : La synthèse du modérateur n'usurpe pas une vérité unique

VIII. Structure de debate_log.json (produit de la table ronde)

{
  "topic": "L'IA a-t-elle une vraie créativité ?",
  "meta": {"created": "2026-09-03", "host": "Ancre rationnelle"},
  "domain": {"id": "t1", "name": "Nature de la créativité IA"},
  "personas": [
    {"id":"p_func","name":"Fonctionnaliste","position":"Créativité = production d'outputs nouveaux et précieux","argument":"Si l'output passe le test de valeur de type Turing, c'est de la création"},
    {"id":"p_bio","name":"Naturaliste biologique","position":"La créativité doit provenir de la conscience et des qualia","argument":"Un système sans expérience subjective ne fait que combiner"},
    {"id":"p_skel","name":"Sceptique","position":"Même la créativité humaine pourrait être une recombinaison","argument":"La nouveauté est un continuum, sans frontière nette"}
  ],
  "claims": [
    {"id":"c1","text":"L'IA peut produire des combinaisons et structures inédites"},
    {"id":"c2","text":"Créer nécessite l'intention de 'pourquoi créer'"},
    {"id":"sm1","text":"(Version acier) Même sans présupposer de conscience, pour 'créer', un système doit au moins pouvoir porter un 'sens' dans ses outputs, reconnaissable par autrui","steelman_of":"c2","by":"p_func"}
  ],
  "relations": [
    {"source":"p_func","target":"c1","type":"supports","text":"Fonctionnellement satisfait nouveauté + valeur"},
    {"source":"p_bio","target":"c1","type":"opposes","text":"Combinaison ≠ création, manque de qualia"},
    {"source":"p_skel","target":"c2","type":"opposes","text":"L'intention humaine peut aussi se réduire à une chaîne causale"},
    {"source":"sm1","target":"c2","type":"steelmanned_by","text":"Version acier réécrite de c2"},
    {"source":"p_func","target":"sm1","type":"supports","text":"Je reconnais que c'est la version la plus digne de considération de l'adversaire"}
  ],
  "synthesis": {"id":"s1","text":"Synthèse du modérateur : Dans le sens de 'création instrumentale', l'IA y parvient déjà ; dans le sens de 'création subjective', elle fait encore défaut."},
  "open_questions": ["Les qualia peuvent-ils être remplacés par un équivalent fonctionnel ?"]
}

Types supportés par relations (schema partagé avec kg-gen) :

  • supports Une position soutient une affirmation (vert)
  • opposes Une position s'oppose à une affirmation (rouge)
  • contested_by Une affirmation est contestée par plusieurs positions (orange, pointillé)
  • refines La synthèse du modérateur raffine une affirmation (bleu)
  • illustrates Exemple (couleur claire)
  • steelmanned_by Une affirmation en acier pointe vers son affirmation source (magenta, pointillé) ; l'affirmation en acier elle-même est un nœud claim avec métadonnées steelman_of/by (losange magenta)
  • Compatible avec belongs_to / alias_of / used_in / related de kg-gen

IX. Modèle de fiche concepts.md (terrain de controverse)

Fiche de position d'un personnage :

### [[Fonctionnaliste]]
- **Position** : Créativité = production d'outputs nouveaux et précieux
- **Argument principal** : Si l'output passe le test de valeur de type Turing, c'est de la création
- **Soutient** : [[c1 L'IA peut produire des combinaisons inédites]]
- **Oppose** : — (voir nœuds opposés)

Fiche d'affirmation :

### [[c1 L'IA peut produire des combinaisons inédites]]
- **Affirmation** : ...
- **Soutenue par** : [[Fonctionnaliste]]
- **Opposée par** : [[Naturaliste biologique]]
- **Appartient à** : [[Nature de la créativité IA]]

IX. Protocole d'argumentation bidirectionnelle en acier (commande acier)

Lorsque le modérateur ou l'utilisateur sent qu'"une position réfute un épouvantail", saisir acier / acier bidirectionnel, le modérateur procède comme suit :

  1. Identifier l'épouvantail : Pointer les opposes qui pourraient viser une version faible de l'affirmation adverse (par exemple, "le réductionniste instrumental s'oppose à la version faible 'créativité = qualité mystérieuse', pas à la version la plus forte de la théorie incarnée").
  2. Chacun écrit la version la plus forte : Demander à chaque personnage de choisir "l'affirmation adverse qu'il conteste le plus" et de la réécrire dans sa version la plus forte et la plus digne de considération (nœud sm). Principe de réécriture : utiliser les arguments les plus solides de l'adversaire, les formulations les plus rigoureuses, sans remplacer les prémisses.
  3. Accrocher la version acier à l'affirmation source : Chaque version acier utilise steelman_of pour pointer vers l'affirmation source ; l'extracteur génère automatiquement steelmanned_by (version acier → affirmation source) et supports de l'auteur vers la version acier (l'auteur reconnaît que c'est la version la plus forte de l'adversaire).
  4. Atterrir sur la vraie divergence : Le personnage explique alors "malgré cela, je m'y oppose encore, parce que…" – la vraie raison de l'opposition cible désormais la version la plus forte, pas un épouvantail. Le modérateur souligne que le contested_by qui émerge alors est le "vrai point de divergence".
  5. Résultat visuel : Après acclération, le graphe affiche des nœuds en losange magenta (affirmations en acier) et des pointillés magenta (steelmanned_by). Cliquer sur le nœud de l'auteur met en évidence sa version acier, montrant visuellement "qui a mis le doigt sur quoi".

L'accération n'est pas "parler à la place de l'adversaire", mais d'abord dire l'adversaire de manière à ce qu'il approuve lui-même, puis s'y opposer – cette étape fait passer le débat d'une performance de position à une quête de vérité.

9.1 Comment écrire une affirmation en acier dans le debate_log

{"id":"sm1","text":"(Version acier) Même sans présupposer de conscience, pour 'créer', un système doit au moins pouvoir porter un 'sens' dans ses outputs, reconnaissable par autrui","steelman_of":"c2","by":"p_func"}
  • steelman_of : ID de l'affirmation source réécrite (obligatoire)
  • by : ID du personnage qui écrit cette version la plus forte (obligatoire, pour connecter automatiquement supports)
  • L'extracteur ajoute automatiquement les deux arêtes steelmanned_by et supports, pas besoin d'écrire manuellement dans relations

X. Limites et déclaration honnête

  • La "représentativité" des personnages de position dépend de la qualité de la sélection par le modérateur – c'est un facteur humain, pas une garantie algorithmique.
  • Le "terrain de la controverse" d'une conversation est un instantané, qui ne se fusionne pas automatiquement entre plusieurs tables rondes (si besoin, fusionner plusieurs intermediate.json puis re-rendre ; le format du graphe est compatible avec kg-gen, qui permet l'assemblage via ses mécanismes alias_of / used_in).
  • La visualisation est un layout à force dirigée à titre indicatif, pas un produit d'algorithmes rigoureux de graphe ; pour les grands graphes (>300 nœuds), il est recommandé de traiter par lots ou de se concentrer sur une sous-proposition.
  • Le moteur de rendu de ce skill partage le format de graphe avec kg-gen, donc les limites correspondantes de kg-gen (pas de fusion automatique entre documents, grands graphes à traiter par lots, etc.) s'appliquent ici également ; la qualité de l'extraction dépend de la qualité de la sélection et de la fixation par le modérateur (vous) – c'est un facteur humain, pas une garantie algorithmique.

Skills associés