Example extensions

These are pre-authored Process Flows packaged as Scrydon extensions (.scrydon-extension.tar.gz). Each one groups a process flow alongside an ontology — download, inspect, then upload via /api/extensions/import. Examples are not auto-installed; you opt in by importing the archive into your organization.

Browse the example extensions

The example catalogue — each scenario, its full step-by-step walkthrough, sample data, and the .scrydon-extension.tar.gz download — lives in the Examples section. This page covers how those extensions are built, imported from the command line, customised, and contributed.

How to import an example

bunx @scrydon/sdk-authoring extension inspect ~/Downloads/iso-quarterly-review-1.0.0.scrydon-extension.tar.gz

curl -X POST "$AGENTIC_URL/api/extensions/import?organizationId=$ORG_ID" \
  -H "Cookie: $SESSION_COOKIE" \
  -F "file=@~/Downloads/iso-quarterly-review-1.0.0.scrydon-extension.tar.gz"

Customising before upload

Most teams will want to tweak personas, due-offset days, or replace actionType: workflow entries with their own workflowIds. Three options:

1. Edit the manifest, re-build. Clone the example source from packages/sdk-authoring/src/process-flows/examples/<slug>/index.ts, edit, then bun run --cwd packages/sdk-authoring build:examples to rebuild every extension. Or assemble a hand-authored extension directory and bunx @scrydon/sdk-authoring extension build path/to/extension.json --outDir dist.
2. Fork the manifest in TypeScript. Author your own defineProcessFlow(...) in your repo, copy-pasting the example as a starting point. Recommended when the changes are non-trivial.
3. Edit process-flow/manifest.json inside the archive. Extract → edit → re-extension with tar -czf. Quick for one-off tweaks; not recommended for ongoing maintenance.

The example manifests are versioned (package.version in both extension.json and the process-flow manifest) — bump that when you fork so your org tracks the divergence.

Adding a new example

To contribute a new example:

1. Create packages/sdk-authoring/src/process-flows/examples/<your-slug>/index.ts exporting a defineProcessFlow(...) result.
2. Append it to exampleTemplates in examples/index.ts.
3. (Optional) If your example needs a real ontology, drop the ontology subdir under packages/sdk-authoring/src/extensions/examples/<your-slug>/ontology/ and register it in ONTOLOGY_OVERRIDES inside scripts/build-examples.ts. Templates without an override get an empty ontology auto-generated at build time.
4. Run bun run --cwd packages/sdk-authoring build:examples — the script auto-discovers and packages every entry.
5. The archive lands at apps/docs/public/static/process-extension-examples/<slug>-<version>.scrydon-extension.tar.gz and is served by the docs site.
6. Add the extension to the catalogue in the Examples section — a card on the examples index and a walkthrough page under content/docs/examples/.

The build script is fail-loud: if a manifest doesn't validate against its schema, the example is rejected and the build fails with the Zod path of the violation.

What's NOT in an example

Extensions are pure data — they cannot include executable code. Custom logic is referenced by workflowId against system or organization-level workflows. The ISO examples reference compliance-quarterly-prefetch, compliance-monitoring-snapshot, compliance-evidence-sync, and compliance-vanta-final-check — these are planned system workflows. Until they ship, those workflow-typed actions degrade to manual checklists in the runtime UI.

Related