Extensions
One noun, one SDK, one lifecycle — author toolkits, models, ontologies, workflows, process flows, data sources, notebooks and MCP servers, and ship them as one extension.
An extension provides toolkits, models, an ontology, process flows,
workflows, data sources, notebooks and MCP servers. You author it with one
defineExtension, build it with one command, install it org-wide, and turn it
on per workspace.
There is one noun for all of it, and the things an extension brings are what it provides.
Authoring
defineExtension, defineToolkit, defineModels, tools, triggers, blocks,
and every content kind an extension can carry.
Building & publishing
Versioning, and delivering releases from a Git or OCI source.
Administering
Installing, connecting accounts, moving versions, and turning an extension on per workspace.
First-party extensions
The extensions Scrydon ships and reviews.
What an extension provides
One extension declares a provides block, and every slot is optional. Ship a
toolkit alone, an ontology alone, or all of them together.
| Slot | What it brings | Guide |
|---|---|---|
toolkits | tools an agent can call, triggers that start a workflow, and the workflow block on the canvas — sharing one credential and one set of scopes | Authoring |
models | the models you provide for one family: llm, embedding, stt, tts, image, video, ocr, moderation | Model families |
ontology | typed object types, link types, action types, identity rules and bindings | Ontologies |
processFlows | stages, task templates, personas, action templates, voice triggers | Process flows |
workflows | executable block graphs — approval gates, routes, automations | Workflows |
dataSources | declarative poll sources: a REST request spec, a bounded field-mapping DSL, typed columns | Data sources |
notebooks | analysis notebooks | Notebooks |
mcpServers | MCP servers registered for the org | MCP servers |
Toolkits and models compile to code and run sandboxed. Everything else is pure JSON and never executes caller-supplied code.
Extensions are authored in code — there is no in-app editor. If you would rather not write that code yourself, see Author an extension with an AI coding agent: describe what you want in plain language and let a tool like Claude Code, Cursor or GitHub Copilot write, validate and build it.
Install the SDK
bun add -d @scrydon/sdk-authoring zodConfirm it resolved:
bunx @scrydon/sdk-authoring --versionThe loop
Compose the extension with define*() helpers. They are identity functions
at run time — their job is to narrow types so your editor catches a mistake
before you build.
A Zod schema validates the manifest at build time, and the platform
validates it again at install time. extension validate pointed at a BUILT
directory runs the full platform sync gate locally.
One command emits one container: extension.json plus a subdirectory for
every declared member — code/ for toolkits and model families, and
ontology/, process-flow/, workflow-<slug>/, data-source-<id>/,
notebook-<slug>/, mcp-server-<id>/ for content.
Through an extension source on Settings → Platform → Extensions → Sources, or a one-off upload from the same page. The platform validates the manifest, stores the artifact, and registers the release in the org's catalog. No redeploy.
CLI
bunx @scrydon/sdk-authoring extension --help
bunx @scrydon/sdk-authoring extension init [name] [--outDir dir]
bunx @scrydon/sdk-authoring extension build [--entry extension.ts] [--outDir dist]
bunx @scrydon/sdk-authoring extension validate [path] [--manifest-only]
bunx @scrydon/sdk-authoring extension inspect <path>
bunx @scrydon/sdk-authoring extension test [--level static|sandbox|live]
# Whole-repository builds, for a Git source:
bunx @scrydon/sdk-authoring extension build-dist <srcDir> --outDir <destDir>
bunx @scrydon/sdk-authoring extension build-source [rootDir] [--check-catalog]build accepts a directory and auto-discovers extension.ts, then derives a
source directory for every declared provides member at
<baseDir>/<member.path>. An extension that mixes kinds builds with no
per-kind flags.
The archive
| What | Archive | Code? | Validated by |
|---|---|---|---|
| An extension | <extension.id>-<extension.version>.scrydon-extension.tar.gz | code/ when it provides toolkits or models: compiled ESM, a manifest and a CycloneDX SBOM | ExtensionManifestSchema, the per-kind manifest schemas, the CycloneDX inspector, the native-dependency guard and the DAG cycle validator |
Ship your first extension
Object types, link types, action types and identity rules. → Ontologies
Approval gates, routes and automations your process flow invokes by slug. → Workflows
Stages, task templates, personas, action templates, voice triggers. → Process flows
Declarative poll sources: a REST request, a mapping DSL, typed columns. → Data sources
bunx @scrydon/sdk-authoring extension build ./my-extensionSettings → Platform → Extensions → Sources → Upload an extension, or the admin API. One atomic install for everything the extension provides.
Where to next
Author an extension
defineExtension, toolkits, models, tools, triggers, blocks, and the build
and install loop.
Model families
Provide llm, embedding, stt, tts, image, video, ocr or
moderation models.
Deliver from a source
Publish releases from a Git or OCI source and let the org pull updates.
Turn it on per workspace
Install org-wide, then choose which workspaces get it.