Extensions

Un seul nom, un seul SDK, un seul cycle de vie — créez des boîtes à outils, des modèles, des ontologies, des workflows, des process flows, des sources de données, des notebooks et des serveurs MCP, et livrez-les comme une seule extension.

Une extension fournit des boîtes à outils, des modèles, une ontologie, des process flows, des workflows, des sources de données, des notebooks et des serveurs MCP. Vous l'écrivez avec un seul defineExtension, vous la construisez avec une seule commande, vous l'installez pour toute l'organisation, puis vous l'activez par espace de travail.

Il n'y a qu'un seul nom pour tout cela, et ce qu'une extension apporte est ce qu'elle fournit.

Création

defineExtension, defineToolkit, defineModels, les outils, les déclencheurs, les blocs et tous les types de contenu qu'une extension peut porter.

Construction et publication

Le versionnage, et la livraison des releases depuis une source Git ou OCI.

Administration

L'installation, la connexion des comptes, le changement de version et l'activation par espace de travail.

Extensions Scrydon

Les extensions que Scrydon publie et révise.

Ce qu'une extension fournit

Une extension déclare un bloc provides, et chaque emplacement est facultatif. Livrez une boîte à outils seule, une ontologie seule, ou tout à la fois.

Emplacement	Ce qu'il apporte	Guide
`toolkits`	les outils qu'un agent peut appeler, les déclencheurs qui lancent un workflow et le bloc de workflow sur le canevas — partageant un identifiant et un même jeu de portées	Création
`models`	les modèles que vous fournissez pour une famille : `llm`, `embedding`, `stt`, `tts`, `image`, `video`, `ocr`, `moderation`	Familles de modèles
`ontology`	types d'objets, types de liens, types d'actions, règles d'identité et liaisons	Ontologies
`processFlows`	étapes, modèles de tâches, personas, modèles d'actions, déclencheurs vocaux	Process flows
`workflows`	graphes de blocs exécutables — portes d'approbation, routages, automatisations	Workflows
`dataSources`	sources de collecte déclaratives : requête REST, DSL de mappage borné, colonnes typées	Sources de données
`notebooks`	notebooks d'analyse	Notebooks
`mcpServers`	serveurs MCP enregistrés pour l'organisation	Serveurs MCP

Les boîtes à outils et les modèles sont compilés et s'exécutent en bac à sable. Tout le reste est du JSON pur et n'exécute jamais de code fourni par l'appelant.

Les extensions s'écrivent en code — il n'y a pas d'éditeur intégré. Si vous préférez ne pas écrire ce code vous-même, voyez Créer une extension avec un agent de codage IA : décrivez en langage naturel ce que vous voulez et laissez un outil comme Claude Code, Cursor ou GitHub Copilot l'écrire, la valider et la construire.

Installer le SDK

bun add -d @scrydon/sdk-authoring zod

Vérifiez la résolution :

bunx @scrydon/sdk-authoring --version

Le cycle

Composez l'extension avec les aides define*(). Ce sont des fonctions identité à l'exécution : leur rôle est de restreindre les types pour que votre éditeur détecte une erreur avant la construction.

Un schéma Zod valide le manifeste à la construction, et la plateforme le valide de nouveau à l'installation. extension validate pointé sur un répertoire CONSTRUIT exécute localement toute la porte de synchronisation.

Une commande produit un seul conteneur : extension.json plus un sous-répertoire par membre déclaré — code/ pour les boîtes à outils et les familles de modèles, et ontology/, process-flow/, workflow-<slug>/, data-source-<id>/, notebook-<slug>/, mcp-server-<id>/ pour le contenu.

Via une source d'extensions sur Paramètres → Plateforme → Extensions → Sources, ou un envoi ponctuel depuis la même page. La plateforme valide le manifeste, stocke l'artefact et enregistre la release dans le catalogue de l'organisation. Aucun redéploiement.

CLI

bunx @scrydon/sdk-authoring extension --help

bunx @scrydon/sdk-authoring extension init     [nom] [--outDir dir]
bunx @scrydon/sdk-authoring extension build    [--entry extension.ts] [--outDir dist]
bunx @scrydon/sdk-authoring extension validate [chemin] [--manifest-only]
bunx @scrydon/sdk-authoring extension inspect  <chemin>
bunx @scrydon/sdk-authoring extension test     [--level static|sandbox|live]

# Construction d'un dépôt entier, pour une source Git :
bunx @scrydon/sdk-authoring extension build-dist   <srcDir> --outDir <destDir>
bunx @scrydon/sdk-authoring extension build-source [rootDir] [--check-catalog]

build accepte un répertoire et découvre automatiquement extension.ts, puis déduit un répertoire source pour chaque membre provides déclaré à <baseDir>/<member.path>. Une extension qui mélange les types se construit sans aucun indicateur par type.

L'archive

Quoi	Archive	Du code ?	Validée par
Une extension	`<extension.id>-<extension.version>.scrydon-extension.tar.gz`	`code/` lorsqu'elle fournit des boîtes à outils ou des modèles : ESM compilé, un manifeste et un SBOM CycloneDX	`ExtensionManifestSchema`, les schémas de manifeste par type, l'inspecteur CycloneDX, la garde des dépendances natives et le validateur de cycles du DAG

Livrez votre première extension

Types d'objets, types de liens, types d'actions et règles d'identité. → Ontologies

Portes d'approbation, routages et automatisations que votre process flow invoque par slug. → Workflows

Étapes, modèles de tâches, personas, modèles d'actions, déclencheurs vocaux. → Process flows

Sources de collecte déclaratives : requête REST, DSL de mappage, colonnes typées. → Sources de données

bunx @scrydon/sdk-authoring extension build ./mon-extension

Paramètres → Plateforme → Extensions → Sources → Envoyer une extension, ou l'API d'administration. Une installation atomique pour tout ce que l'extension fournit.

Extensions

Création

Construction et publication

Administration

Extensions Scrydon

Ce qu'une extension fournit

Installer le SDK

Le cycle

CLI

L'archive

Livrez votre première extension

Et ensuite

Créer une extension

Familles de modèles

Livrer depuis une source

Activer par espace de travail

Sur cette page