Building your own toolkits

Custom toolkits are how Jootle extends to needs no off-the-shelf toolkit covers.

There are two paths: let your Jootle build it (recommended for most customers) or hand-write it (for developers comfortable with JSON).

The recommended path: a Claude skill that builds toolkits for you

We publish a Claude skill file that contains the complete Jootle Toolkit Format (JTF) v1.0 specification, the full window.jootle.* bridge API reference, worked examples, and a validation checklist. Drop it into your Claude (Claude Code, the desktop app’s projects, or any Claude-aware coding assistant) and Claude can build you a working toolkit from a single conversation.

Download

Download jootle-toolkit-builder.md — the toolkit-builder Claude skill (single Markdown file).

How to use it

Save the file to a location your Claude can read. For Claude Code: ~/.claude/skills/jootle-toolkit-builder/SKILL.md. For the Claude desktop app: add it as a Project knowledge file. For any other Claude-aware tool: include it in the system prompt or project context.
Tell Claude what you want. Example:

“I run a small catering business. I want a Jootle toolkit that tracks quotes through these stages: inquiry → proposal sent → accepted → in-progress → completed. Each quote has a customer, event date, headcount, and total. I want a sidebar view that shows upcoming events for the week, and a playbook that drafts a follow-up email when a quote has been sitting in ‘proposal sent’ for more than 5 days.”
Claude produces a .jtf.json file. The skill includes the validation checklist so Claude can self-check before delivering.
Import the file in your instance — Tools → Import toolkit… → select file → Install.

Most first toolkits take 15-30 minutes from concept to installed. Iterate by going back to Claude — “add a ‘deposit received’ field”; “when a quote is accepted, also create a project for that event” — and re-importing the updated file.

The hand-written path

If you want to author JTF directly without an AI, the format is straightforward JSON. A complete toolkit is a single .jtf.json file containing:

A manifest — name, version, description, and ai_context (what your toolkit teaches your Jootle about itself).
Menu entries — sidebar items, dashboard widgets.
Members — the HTML pages of the toolkit (mounted under /app/tools/{slug}).
Optional entity types — new kinds of things your instance can track.
Optional playbooks — multi-step workflows your Jootle can run.

The skill file (linked above) is also useful as a hand-author reference even if you don’t run it through Claude — it has the complete schema, the bridge API, and worked examples. Open it in any text editor.

A few gotchas to know up front:

Toolkits are single-file (.jtf.json). No directory format.
Toolkit HTML pages run in sandboxed iframes with no outbound network. Use the window.jootle.* bridge for all backend access.
Entity slugs must be globally unique on the instance.
The ai_context field is what teaches your Jootle about your toolkit — keep it under 2000 words.

The complete reference is in the skill file. Read it once before authoring.

When to build your own

Reasons that justify the build:

A business-specific workflow that no public toolkit handles. (“My catering business needs to track event quotes through a specific 7-stage pipeline.”)
A domain-specific entity type that doesn’t exist as a public toolkit. (“I run a veterinary clinic and want to track patients as a first-class thing.”)
A heavily customised version of a public toolkit, where the public one doesn’t quite fit your workflow.

Reasons that aren’t great:

“It would be cool to build one.” Custom toolkits are real work, even with AI help. If there’s no specific problem driving it, you’ll abandon it.
A tweak to an existing toolkit. Most public toolkits can be configured rather than forked. Try the settings first.

Testing your toolkit

A toolkit you’ve built can be installed on your own instance immediately. Test it there. If it works, you have a strong signal that the design is right.

For toolkits you’d share, install on a fresh test instance to verify it works without depending on your specific data. You can spin up a test instance from your account if your plan includes it, or use a sandbox account.

Two ways:

Private share. Export the toolkit as a .jtf.json file and send it to someone. They install it directly. No public listing. Good for sharing with a colleague, a client, or another business of yours.

Public submission. Submit the toolkit to the library for review. We test it, evaluate fit, and if it’s a good fit for the broader audience, we publish it as a community toolkit. The submission flow is in Settings → Toolkits → Submit.

Submissions can be commercial (you charge a licence fee) or free. If you submit a paid toolkit, the library handles licensing through your Stripe Connect account.

When NOT to build a custom toolkit

Sometimes the right answer is “this isn’t a toolkit, it’s a customisation”:

A custom playbook in your instance, not bundled as a toolkit.
A specific entity type added directly through conversation (“track customers like contacts, but with these extra fields”).

These don’t need to be packaged. They live in your instance.

The dividing line: if it’s only useful for you, just configure it. If it’s reusable across instances, make it a toolkit.

A note on quality

Custom toolkits inherit Jootle’s broader voice and behaviour. The same approval gates, the same conversational interface, the same knowledge graph integration. If your toolkit’s UX feels off-pattern compared to the rest of your instance, it’s usually a sign to align with the conventions rather than fight them.

The toolkit format is generous — you can do a lot. The discipline is to do less.

The library — where library toolkits live.
Importing and exporting — the mechanics of moving .jtf.json files around.
Toolkits overview — the conceptual foundation if you’re new to the toolkit model.