Importing and exporting toolkits

Toolkits are portable. You can export the toolkits you’ve built or customised, and you can import toolkits someone else has shared with you, without going through the public library.

The .jtf.json file

A toolkit is a single .jtf.json file (Jootle Toolkit Format, JSON-based). The file contains:

• The toolkit’s manifest (name, version, description, AI context).
• Menu entries (sidebar items, dashboard widgets).
• Member HTML pages (the toolkit’s UI surfaces).
• Optional entity type definitions.
• Optional playbooks.
• A bill-of-materials summary.

It does NOT contain:

• Your data. The toolkit is the definition; your data is separate.
• Your secrets or credentials. Those live in your instance, not in the toolkit file.

A typical toolkit file is between 5 KB (a small toolkit with one page and no playbooks) and 200 KB (a complex toolkit with several entities and playbooks). Each member HTML page is capped at 512 KB.

Exporting

From your instance’s admin UI, find the toolkit you want to export and choose Download as .jtf.json. You get a single file you can save, share, or commit to git.

The export captures the current state of the toolkit on your instance. If you’ve modified anything (added a new playbook, changed an entity type’s fields, customised a member page), the export includes those modifications.

Importing

From the library or Tools → Import toolkit…, choose the .jtf.json file. Your instance:

1. Validates the file’s schema.
2. Computes the bill-of-materials and checks for conflicts (a toolkit slug or entity slug that already exists on your instance).
3. Shows you the preview dialog — what will be added, what conflicts exist.
4. Waits for you to confirm.

Before clicking install, review:

• What entities it adds. Names, fields, relationships.
• What playbooks it adds. What each one does.
• What menu entries it adds. Where they’ll appear in your sidebar.
• Who built it. The manifest names the author.

Imports from sources you trust (a colleague, a vendor you work with, your own export) are routine. Imports from sources you don’t know should be reviewed carefully, the same way you’d review any file you got from a stranger.

File imports vs. library installs

There are two trust tiers:

• Library installs — toolkits in the official catalogue have been reviewed by Jootle before publication. You can install with reasonable confidence.
• File imports — toolkits delivered as a .jtf.json file directly to you bypass the library review. The import preview dialog explicitly warns: “File imports are not reviewed by the Jootle library. Only import bundles from sources you trust — imported toolkits can run LLM prompts and create entity types on your instance.”

File imports require the admin permission on the instance. If you don’t trust the source, don’t import.

What a toolkit file can do (and can’t)

Worth knowing before you accept a file from someone:

Can:

• Add custom entity types and write data into them.
• Run LLM prompts on your instance’s AI budget.
• Add UI pages that run sandboxed code (no outbound network, only window.jootle.* calls back to your instance).
• Add playbooks your Jootle can invoke.
• Emit tags that the engine processes ([ENTITY:], [LIST:], [TASK:], etc.).

Cannot:

• Execute code outside an iframe or outside the playbook runner.
• Access other customers’ data (instances are single-tenant).
• Escape the sandbox.
• Install without admin permission.

Use cases

Sharing across your own instances. You have a personal Jootle and a business Jootle and want a toolkit on both. Export from one, import to the other.

Sharing with a colleague. You built something useful for your work; a colleague at another company wants it. Export, send, they import.

Onboarding a client. Your consulting business builds a custom toolkit for a client. You install on their instance via import, rather than them having to build it themselves.

Versioning your own toolkits. Each time you ship a new version of a custom toolkit you’re maintaining, export to a versioned filename (my_toolkit_v3.jtf.json). If a future version breaks something, you can re-import the older file.

Round-trips

You can export a toolkit, modify the JSON in any editor, and re-import. This is how developers iterate on custom toolkits — change a playbook prompt, tweak a page’s HTML, add a new entity type field, then re-import to update.

The import is upsert — existing components on your instance are updated in place rather than duplicated.

Some changes are still moving in v1.0:

• Goals are not bundled in v1.0 (a known limitation, planned for v1.1). Toolkits that use recurring goals will export their pages and playbooks, but the goal itself must be re-created on the target instance.
• Playbook version history doesn’t travel. Install creates version 1 on the target; history restarts there.

Full format details live in the toolkit-builder skill file.

Removing an imported toolkit

Imported toolkits uninstall the same way as library toolkits. You don’t need to keep the source .jtf.json file; the toolkit’s contents live in your instance once installed.

Uninstalling preserves your data by default; deleting it is a separate explicit action.

File hygiene

If you’re sharing .jtf.json files:

• Use a clear filename. crm_v2.jtf.json beats toolkit.jtf.json.
• Keep nontrivial custom toolkits in version control. Git is a fine fit.
• If a toolkit has external dependencies (specific API keys, SaaS accounts), document them alongside the file too, so the recipient knows what they’re signing up for.

When NOT to use import / export

A few cases where there’s a better path:

• Backing up your data isn’t done via toolkit export. Data backup is separate — see Backups and recovery.
• Migrating users from one instance to another. Toolkits travel; user accounts don’t (they’re scoped to the instance).
• Sharing a single playbook with someone, without the surrounding toolkit. For now, you’d share by re-creating it in the recipient’s instance via conversation. A “share a single playbook” export is on the roadmap.

Related

• Building your own toolkits — the build side, including the downloadable Claude skill that produces .jtf.json files for you.
• The library — the official catalogue.