Fonctionnalité en construction
Cette fonctionnalité n'est pas encore disponible. Voici ce qui est prévu, pour que vous puissiez juger si elle couvrira votre besoin — et nous dire si ce n'est pas le cas.
État — conception arbitrée
Disponibilité prévue — mode serveur uniquement
En résumé
Un skill est une procédure écrite en français, que l’assistant lit et applique : un référentiel de statistiques, la bonne façon d’interroger un entrepôt OMOP, les conventions de votre service. Vous l’écrivez une fois au niveau de l’espace de travail, chaque projet choisit celles dont il a besoin. Le format est un standard ouvert, lu par de nombreux assistants — donc utile même en dehors de Linkr.
Le problème : réexpliquer à chaque fois
Un modèle de langage a des connaissances générales, mais approximatives là où il faudrait être exact. Il confondra deux tests statistiques aux conditions d’application voisines. Il écrira une requête OMOP plausible mais fausse, parce qu’il ignore qu’un concept doit être cherché à la fois dans _concept_id et dans _source_concept_id. Et il ne connaît évidemment pas les usages de votre service.
Vous pouvez le corriger à chaque conversation. Ou l’écrire une fois.
C’est exactement ce qu’est un skill : une procédure de référence, rédigée pour être lue par un assistant plutôt que classée dans un tiroir.
Trois familles se dégagent vite à l’usage.
Un référentiel méthodologique
Les statistiques, par exemple : quel test pour quelle question, à quelles conditions d’application, comment rapporter le résultat. L’assistant qui vous aide à coder dispose alors d’une connaissance sourcée plutôt que de souvenirs approximatifs.
La façon d’interroger votre entrepôt
Les requêtes usuelles sur le modèle OMOP — ou sur le format que vous utilisez — avec leurs pièges. Un assistant qui a lu ce skill écrit du SQL juste sur votre modèle, au lieu de généralités plausibles.
Les usages de votre service
Ce qu’aucun modèle ne peut deviner : vos critères d’inclusion habituels, vos conventions de nommage, les exclusions que vous appliquez systématiquement.
À quoi ça ressemble
Un skill est un dossier contenant un fichier SKILL.md, et éventuellement des fichiers d’appui : des exemples, un modèle de document, un script.
Le fichier commence par un en-tête — un nom, une description — puis le corps est du texte libre.
---
name: requetes-omop
description: >-
Comment interroger un entrepôt au format OMOP : requêtes usuelles,
jointures sur les concepts, pièges à éviter.
---
# Interroger un entrepôt OMOP
## Toujours chercher un concept sur les deux colonnes
Un événement porte un `_concept_id` (le concept standard) et un
`_source_concept_id` (le code d'origine). Chercher sur un seul des deux
laisse passer des enregistrements : interrogez toujours les deux. …
## Compter des patients, pas des lignes
Une même mesure peut apparaître plusieurs fois pour un patient. Sauf
demande contraire, comptez des `person_id` distincts. …Rien de plus. Pas de langage de programmation, pas de compilation : du texte que vous relisez et corrigez comme n’importe quelle note de service. C’est ce qui permet à un clinicien de l’écrire sans intermédiaire.
La description compte plus qu'on ne croit
C’est sur la description que l’assistant décide s’il doit lire un skill. Une description vague le fera passer à côté ; une description qui dit précisément dans quelles situations s’en servir la rendra utile au bon moment.
Écrits une fois, choisis par projet
Les skills appartiennent à l’espace de travail — c’est le bon niveau, puisqu’une convention de service vaut pour tous les projets qui en dépendent.
Chaque projet choisit ensuite ceux qu’il utilise. Un projet d’analyse activera le référentiel de statistiques ; un projet travaillant sur l’entrepôt activera celui des requêtes OMOP. Inutile de noyer l’assistant sous des procédures qui ne concernent pas le travail en cours.
Point important : un projet exporté emporte la référence aux skills qu’il utilise, pas leur copie. Sans quoi chaque projet finirait avec sa propre version divergente d’une même procédure — exactement ce qu’on cherche à éviter en l’écrivant une seule fois. Si un skill référencé manque à l’import, Linkr le signale et propose de l’installer.
Un standard ouvert, pas un format Linkr
C’est le point qui dépasse Linkr : ce format de skill est un standard ouvert, déjà lu par de nombreux assistants du marché.
Concrètement, un skill écrit pour Linkr — « comment interroger notre entrepôt OMOP » — reste lisible par l’assistant de votre éditeur de code, sur votre machine, en dehors de toute instance Linkr. Ce n’est pas un investissement dans un outil, mais dans une procédure réutilisable ailleurs.
C’est aussi ce qui rend les skills partageables : publié dans le catalogue, un skill profite à d’autres établissements, qui pourront l’adapter à leurs usages.
Un usage typique
Un centre rédige un skill de statistiques : quel test pour quelle question, conditions d’application, comment rapporter le résultat, le tout référencé. L’assistant qui aide à écrire une analyse s’y appuie au lieu de reconstituer de mémoire. Publié, ce skill sert à d’autres centres — et la relecture méthodologique profite à tout le monde.
Ce qui n’est pas encore tranché
- Le partage de fichiers entre skills. Le standard pousse vers des skills autonomes, donc chacun embarque ce dont il a besoin ; il n’est pas certain que cela suffise à l’usage.
- Le degré de vérification au moment de l’écriture : un skill mal formé est silencieusement ignoré par les assistants, ce qui est pénible à diagnostiquer — reste à décider ce que Linkr signale, et à quel moment.
Pour aller plus loin
- Agents — l’assistant qui lit ces skills et les applique.
- Publier du contenu — diffuser un skill auprès d’autres établissements.