--- name: jootle-toolkit-builder description: > Build, validate, and deliver Jootle Toolkit Format (JTF v1.1) bundles for the Jootle platform. Use when the user wants to create a Jootle toolkit, build a `.jtf.json` file, package a custom workflow as a Jootle extension, author custom entity types and playbooks for a Jootle instance, ship custom AI agents, autonomous goals, seeded knowledge graph content, pre-populated entity instances, or bundled methodology documents, or design tool HTML pages that use the `window.jootle.*` bridge. Triggers on mentions of Jootle toolkit, JTF, `.jtf.json`, Jootle Toolkit Format, custom Jootle entity type, Jootle playbook authoring, `window.jootle` bridge, Jootle tool page, Jootle module packaging, knowledge_seed, toolkit documents, or custom specialized agents. --- # Jootle Toolkit Builder (JTF v1.1) This skill makes Claude able to author **Jootle Toolkit Format (JTF) v1.1** bundles — single-file `.jtf.json` archives that install into any Jootle instance and deliver a complete, self-contained capability (UI pages, custom entity types, playbooks, menu entries, custom agents, autonomous goals, seeded knowledge graph content, pre-populated entity instances, and bundled reference documents). Use it when the user asks you to build a Jootle toolkit. Output a valid `.jtf.json` they can import via **Tools → Import toolkit…** in their instance. This skill is the **authoritative reference for JTF v1.1**. It supersedes any older `docs.jootle.com` content for build-time decisions; the docs site is intentionally lighter than this skill. **v1.1 is purely additive over v1.0.** Every v1.0 bundle still installs unchanged on a v1.1 instance. v1.1 introduces five new top-level fields — `agents[]`, `goals[]`, `entity_instances[]`, `knowledge_seed`, and `documents[]` — plus a `budget_profile` hint on agents. Set `bundle_schema: "1.1"` if you use any of them; v1.0 instances reject 1.1 bundles with a clear error. --- ## What a Jootle toolkit is — the mental model A Jootle toolkit is a packaged extension of a Jootle instance. It contains: - **One or more HTML pages** ("members") — sandboxed UI surfaces mounted under `/app/tools/{slug}`. - **Optional custom entity types** — new kinds of things the instance can store and reason about (a "Quote", a "Recipe", a "Governance Session"). - **Optional playbooks** — multi-step workflows the AI can run autonomously or on demand. - **A manifest** — menu contributions (sidebar entries, palette commands, widgets) and an `ai_context` string that teaches the instance's AI what this toolkit does. A toolkit is **NOT** a standalone app. It's an extension that participates in the instance's existing systems: the AI loop, the knowledge graph, the playbook engine, the multi-channel input loop, the theming system. Tool pages live in iframes with a CSP that blocks all outbound network calls — they reach the backend only through the `window.jootle.*` bridge. Fresh Jootle instances ship with **zero toolkits**. Toolkits arrive only by: 1. Installing from the library (reviewed, official path). 2. Importing a `.jtf.json` file (unreviewed, "your responsibility" path). The instance never auto-seeds toolkits at provision time. --- ## JTF v1.0 bundle shape A complete bundle is a single JSON file with this top-level structure: ```json { "bundle_schema": "1.1", "toolkit": { /* identity + display */ }, "manifest": { /* AI context, menu, widgets */ }, "members": [ /* one or more HTML pages */ ], "entity_types": [ /* optional custom entity types */ ], "playbooks": [ /* optional playbook definitions */ ], "agents": [ /* v1.1 — optional custom specialized agents */ ], "goals": [ /* v1.1 — optional autonomous goals */ ], "knowledge_seed": { /* v1.1 — optional seeded KG entities + relationships */ }, "entity_instances": [ /* v1.1 — optional pre-populated entity rows */ ], "documents": [ /* v1.1 — optional bundled reference documents */ ], "metadata": { /* author + bill-of-materials */ } } ``` Field-by-field reference follows. ### `bundle_schema` (string, required) Set to `"1.0"` for v1.0 bundles or `"1.1"` if you use any of the five v1.1 fields (`agents[]`, `goals[]`, `entity_instances[]`, `knowledge_seed`, `documents[]`). v1.1 instances accept both `"1.0"` and `"1.1"` bundles; v1.0 instances reject `"1.1"` bundles with a clear error. Setting `"1.0"` while using a v1.1 field is a validator error. v2.0 will be breaking. ### `toolkit` (object, required) ```json { "slug": "ideas", "title": "Ideas", "description": "Capture ideas, think them through, promote the good ones.", "icon": "💡", "category": "general" } ``` - `slug` — unique per instance. Drives the URL (`/app/tools/{slug}`) and conflict detection on install. Use kebab-case, no spaces. - `title` — display name. Title Case. - `description` — one-line summary. Shown in the storefront and the import preview dialog. - `icon` — single emoji or short string. Used in sidebar, dashboard widgets, knowledge-graph nodes. - `category` — freeform string for library grouping. Common values: `general`, `productivity`, `sales`, `games`, `content`, `finance`, `governance`, `health`, `home`. ### `manifest` (object, required) ```json { "version": "1.0.0", "ai_context": "You have the Ideas toolkit installed...", "menu": [ { "id": "tk.ideas.inbox", "surface": "sidebar", "grp": "tools", "label": "Ideas", "icon": "💡", "href": "/app/tools/ideas", "sort_order": 25, "permission": "dashboard" } ], "widgets": [] } ``` **`ai_context`** — prose injected into the instance's AI system prompt when this toolkit is installed. This is how the AI learns: - What entity types your toolkit defines. - What tag syntax (if any) it expects (e.g., `[IDEA: create, title: "..."]`). - When to use it vs. core primitives. - Any naming conventions or behavioral rules. Keep it operational and short. **Under 2000 words.** Every word pollutes every conversation on that instance. **`menu[]`** — sidebar / palette / context-menu / dashboard contributions. Each entry has: - `id` — globally unique. Convention: `tk.{toolkit-slug}.{descriptor}`. - `surface` — one of `sidebar`, `palette`, `context-menu`, `dashboard`. - `grp` — group within the surface. Common sidebar groups: `tools`, `work`, `connections`, `admin`. - `label` — display text. - `icon` — single emoji or short string. - `href` — destination path. Must start with `/app/`. - `sort_order` — integer. Lower = higher in list. - `permission` — gate. Common values: `dashboard` (any logged-in user), `admin`. **`widgets[]`** — dashboard widget declarations. Each: ```json { "slug": "ideas-inbox-count", "name": "Ideas Inbox", "icon": "💡", "category": "Productivity", "default_col_span": 4 } ``` For v1.0, widget HTML lives inline in the manifest — keep widgets simple. Complex UI belongs in a full member tool. ### `members` (array of objects, required) At least one member required. The first member is typically the toolkit hub landing page; additional members are linked sub-tools. ```json { "slug": "ideas-inbox", "title": "Ideas Inbox", "description": "Capture, think, and promote ideas.", "icon": "💡", "content": "...self-contained HTML...", "sort_order": 0 } ``` - `slug` — unique within the toolkit. Drives the URL: `/app/tools/{toolkit-slug}/{member-slug}` (the first member typically uses the toolkit slug as its href). - `content` — **entire HTML document** with inline `

My Tool

``` ### `window.jootle.*` bridge API All methods return Promises and proxy through `postMessage` to the parent, which makes the actual HTTP call with auth headers attached. #### `window.jootle.fetch(path, options?)` — low-level ```js const r = await window.jootle.fetch('/api/projects', { method: 'GET' }); // r = { status: 200, data: {...}, ok: true } ``` Path **must** start with `/api/`. The parent strips and validates the path. 30-second timeout. Use the higher-level helpers below in preference. #### `window.jootle.entity.*` — entity CRUD ```js // Create const created = await window.jootle.entity.create('idea', { name: 'A new idea', data: { title: 'A new idea', summary: 'Worth exploring', status: 'raw' } }); // Get const item = await window.jootle.entity.get('idea', ''); // Update await window.jootle.entity.update('idea', '', { data: { status: 'exploring' } }); // Delete await window.jootle.entity.delete('idea', ''); // List — supports { q, status, limit, offset, toolkit_id } const list = await window.jootle.entity.list('idea', { limit: 50 }); // list = { items: [...], total: N } // Search (alias for list with q) const found = await window.jootle.entity.search('idea', 'climate', 20); ``` The `name` field is at the top level; everything else lives under `data`. #### `window.jootle.brain.*` — LLM access ```js // Free-form prompt — counts against the tool's brain budget const r = await window.jootle.brain.ask( 'Summarize this in one sentence: ' + text, { max_tokens: 200 } ); // r = { text: "...", model: "...", tokens_used: N } // Classification with discrete labels const c = await window.jootle.brain.classify( 'Is this a question or a statement?: ' + text, ['question', 'statement'] ); // c = { label: "question", confidence: 0.95 } ``` Handle `429` (`code: 'budget_exceeded'`) gracefully — fall back to a non-LLM behavior. Don't spam the user with budget errors. #### `window.jootle.playbooks.*` — invoke shipped workflows ```js // Invoke a playbook from your toolkit const { run_id } = await window.jootle.playbooks.invoke( 'pb_notes_summarize', { note_id: id, body: body }, { toolkit_slug: 'notes' } ); // Poll for completion const status = await window.jootle.playbooks.runStatus(run_id); // status = { status: 'completed' | 'running' | 'failed', outputs: {...} } ``` #### `window.jootle.knowledge.*` — KG access ```js // Search the KG const results = await window.jootle.knowledge.search('climate policy', 10); // Get an entity by name (returns null on 404) const entity = await window.jootle.knowledge.get('Climate Policy'); // Write a fact — LLM extracts entities + relationships await window.jootle.knowledge.writeFact( 'The 2026 climate summit will be in Sao Paulo in November.', 'imported from a news article' ); ``` #### `window.jootle.store.*` — per-tool key/value storage ```js // Set await window.jootle.store.set('last-search', { q: 'climate', when: Date.now() }); // Get (returns undefined if not set) const last = await window.jootle.store.get('last-search'); // List keys (optional prefix filter) const keys = await window.jootle.store.list('prefs.'); // Delete await window.jootle.store.delete('last-search'); ``` Values must be JSON-serializable. Storage is scoped per toolkit slug — different toolkits can use the same key without collision. #### `window.jootle.link / unlink / getLinks` — relationships ```js // Link two entities await window.jootle.link({ fromType: 'idea', fromId: 'idea_abc', toType: 'project', toId: 'proj_xyz', linkType: 'graduated-into' }); // Unlink await window.jootle.unlink({ fromType, fromId, toType, toId, linkType }); // Read links (optionally filtered by linkType or targetType) const links = await window.jootle.getLinks('idea', 'idea_abc', { linkType: 'graduated-into' }); ``` #### `window.jootle.documents.*` — bundled reference documents (v1.1) Only available when your member page belongs to a toolkit that ships `documents[]`. Document slug is unique within the toolkit; toolkit context is auto-injected (no need to pass the toolkit slug yourself). ```js // Whole document const doc = await window.jootle.documents.get('gs-spec'); // doc = { slug, name, content_type, size_bytes, content } | null on 404 // Specific section (slash-joined heading path) const sec = await window.jootle.documents.get('gs-spec', { section: 'Part III — The Instruments/Isis Sensing Protocol' }); // sec = { slug, name, content_type, size_bytes, section: { section_path, heading_level, heading_text, content } } // Table of contents const toc = await window.jootle.documents.sections('gs-spec'); // toc = [{ section_path, heading_level, heading_text, section_order }, ...] ``` Heavy methodology / spec content lives in `documents[]`, not `ai_context`. Members and AI tags retrieve sections on demand — pay 2k tokens, not 50k. #### `window.jootle.navigate(path)` — navigate the parent ```js window.jootle.navigate('/app/projects/proj_xyz'); ``` Only `/app/` paths allowed. Used for "open this entity in its full workspace" links. #### `window.jootle.theme` and `onThemeChange` ```js // Current theme snapshot const t = window.jootle.theme; // t = { mode: 'dark' | 'light', tokens: { 'accent': '#...', ... } } // React to theme changes window.jootle.onThemeChange(snapshot => { // Update any baked-in styles }); ``` ### Theme tokens you can use Reference these as `var(--{name})` in your CSS. Don't bake in literal colors. | Group | Tokens | | --- | --- | | Surfaces | `--bg-default`, `--bg-paper`, `--bg-elevated`, `--bg-hover` | | Accent | `--accent`, `--accent-light`, `--accent-muted`, `--accent-subtle` | | Text | `--text-primary`, `--text-secondary`, `--text-muted`, `--text-inverse` | | Borders | `--border-default`, `--border-hover`, `--border-strong` | | Status | `--success`, `--warning`, `--error`, `--info` | | Typography | `--font-sans`, `--font-display`, `--font-mono` | | Spacing | `--space-1` through `--space-8` | | Radii | `--radius-sm`, `--radius-md`, `--radius-lg`, `--radius-full` | | Shadows | `--shadow-xs`, `--shadow-sm`, `--shadow-md`, `--shadow-lg` | | Transitions | `--transition-fast`, `--transition-base`, `--transition-slow` | Renaming or removing these is a breaking change, so they're stable. Adding new ones is additive. --- ## Anti-patterns and gotchas - **No outbound network from member HTML.** CSP blocks `fetch('https://...')`. The bridge only reaches `/api/` paths on the same instance. - **No `" } ], "entity_types": [ { "slug": "note", "name": "Note", "plural_name": "Notes", "icon": "📝", "description": "A short note or capture", "schema_hint": { "fields": [ { "key": "body", "type": "text", "label": "Body" } ], "display_name_field": "name" } } ], "metadata": { "author": "Example Author", "publisher_instance": "example", "bill_of_materials": { "tool_count": 1, "widget_count": 0, "entity_type_count": 1, "entity_types": ["note"], "playbook_count": 0, "playbooks": [], "menu_items": 1, "has_goals": false } } } ``` Saves as `notes.jtf.json`. Install via **Tools → Import toolkit…** --- ## Worked example 2 — Notes + Summarize playbook Adds an LLM-powered playbook the AI can invoke. ```json { "bundle_schema": "1.0", "toolkit": { "slug": "notes", "title": "Notes", "description": "Plain notes with AI summarization.", "icon": "📝", "category": "productivity" }, "manifest": { "version": "1.1.0", "ai_context": "You have the Notes toolkit. Capture notes with [ENTITY: create, type: note, name: , data: { body: }]. To summarize a note, run [PLAYBOOK: pb_notes_summarize, note_id: , body: ] — produces a one-sentence summary as an artifact.", "menu": [ { "id": "tk.notes.hub", "surface": "sidebar", "grp": "tools", "label": "Notes", "icon": "📝", "href": "/app/tools/notes", "sort_order": 30, "permission": "dashboard" } ], "widgets": [] }, "members": [ { "slug": "notes-hub", "title": "Notes", "description": "All your notes", "icon": "📝", "sort_order": 0, "content": "

Notes

Loading…
" } ], "entity_types": [ { "slug": "note", "name": "Note", "plural_name": "Notes", "icon": "📝", "description": "A short note or capture", "schema_hint": { "fields": [{ "key": "body", "type": "text", "label": "Body" }], "display_name_field": "name" } } ], "playbooks": [ { "playbook": { "id": "pb_notes_summarize", "name": "Summarize note", "description": "Produce a one-line summary of a note", "status": "active", "source": "seed", "category": "standalone", "trigger_config": { "triggers": [] }, "variables_schema": { "note_id": { "type": "string", "required": true }, "body": { "type": "string", "required": true } } }, "nodes": [ { "id": "pb_notes_summarize_step", "node_type": "step", "label": "Summarize", "config": { "agent": "documentation", "instruction": "Summarize the following note in one short sentence. Be plain — no flourish.\n\n{{body}}\n\nRespond with exactly one line, beginning with:\nOUTPUT:artifact_markdown=", "outputs": ["artifact_markdown"] }, "ordering": 1 }, { "id": "pb_notes_summarize_end", "node_type": "end", "label": "Done", "ordering": 2 } ], "edges": [ { "from_node_id": "pb_notes_summarize_step", "to_node_id": "pb_notes_summarize_end", "priority": 0 } ] } ], "metadata": { "author": "Example Author", "publisher_instance": "example", "bill_of_materials": { "tool_count": 1, "widget_count": 0, "entity_type_count": 1, "entity_types": ["note"], "playbook_count": 1, "playbooks": ["pb_notes_summarize"], "menu_items": 1, "has_goals": false } } } ``` --- ## Worked example 3 — Multi-member toolkit with enum entity A small "Decisions" toolkit: a hub page that lists decisions and a detail page for one decision. Decisions have a status enum. (Pattern only — the full HTML would push past readability here. Use the shape:) - `toolkit.slug = "decisions"` - `members`: - `{ slug: "decisions-hub", ... }` — lists all decisions, links to detail pages. - `{ slug: "decisions-detail", ... }` — reads `?id=...` from URL, renders one decision with its options and criteria. - `entity_types`: - `decision` with fields: `framing` (text), `status` (enum: `open`/`decided`/`retrospective`), `outcome` (text) - `decision_option` with fields: `name` (text), `score` (number), `notes` (text) - `playbooks`: - `pb_decisions_retrospect` — invoked 6 months after status flipped to `decided`. Reads the decision + outcome + the world's actual events, scores how the decision aged. - Cross-linking: `window.jootle.link({ fromType: 'decision', fromId: ..., toType: 'decision_option', toId: ... })` to associate options with their parent decision. For multi-member toolkits, the toolkit hub page typically navigates to member pages via `window.jootle.navigate('/app/tools/decisions/decisions-detail?id=' + id)` and the detail page reads `new URLSearchParams(window.location.search).get('id')`. --- ## Worked example 4 — v1.1 vertical (custom agent + goal + knowledge seed + document) A minimal "Reviewer" toolkit that demonstrates each v1.1 field. Trimmed for readability — production toolkits would have richer HTML and more entries. ```json { "bundle_schema": "1.1", "toolkit": { "slug": "reviewer", "title": "Reviewer", "description": "Lightweight document-review toolkit demonstrating JTF v1.1.", "icon": "🔍", "category": "productivity" }, "manifest": { "version": "1.0.0", "ai_context": "You have the Reviewer toolkit. Submissions are `submission` entities. The `reviewer_pro` agent does deep diagnostic review; invoke it via [PLAYBOOK: pb_reviewer_audit, submission_id: ]. Background quality checks run autonomously every 6h. Methodology lives in the `review-spec` document — retrieve specific sections via window.jootle.documents.get('review-spec', { section: '...' }); don't load the whole spec by default. Seeded review-principle entries live in the `reviewer-principles` knowledge group.", "menu": [ { "id": "tk.reviewer.hub", "surface": "sidebar", "grp": "tools", "label": "Reviewer", "icon": "🔍", "href": "/app/tools/reviewer", "sort_order": 40, "permission": "dashboard" } ], "widgets": [] }, "members": [ { "slug": "reviewer-hub", "title": "Reviewer", "description": "Submission queue + review status", "icon": "🔍", "sort_order": 0, "content": "

Reviewer

Loading…
" } ], "entity_types": [ { "slug": "submission", "name": "Submission", "plural_name": "Submissions", "icon": "📨", "description": "A document submitted for review", "schema_hint": { "fields": [ { "key": "body", "type": "text", "label": "Body" }, { "key": "status", "type": "enum", "label": "Status", "options": ["received", "in_review", "approved", "rejected"] } ], "display_name_field": "name" } } ], "playbooks": [ { "playbook": { "id": "pb_reviewer_audit", "name": "Audit submission", "description": "Run a deep diagnostic audit on a submission", "status": "active", "source": "seed", "category": "standalone", "trigger_config": { "triggers": [] }, "variables_schema": { "submission_id": { "type": "string", "required": true } } }, "nodes": [ { "id": "pb_reviewer_audit_step", "node_type": "step", "label": "Audit", "config": { "agent": "reviewer_pro", "instruction": "Audit submission {{submission_id}} against the review spec. Reference seeded principles where relevant. Produce a single-paragraph verdict.\n\nOUTPUT:artifact_markdown=", "outputs": ["artifact_markdown"] }, "ordering": 1 }, { "id": "pb_reviewer_audit_end", "node_type": "end", "label": "Done", "ordering": 2 } ], "edges": [ { "from_node_id": "pb_reviewer_audit_step", "to_node_id": "pb_reviewer_audit_end", "priority": 0 } ] } ], "agents": [ { "name": "reviewer_pro", "description": "You are Reviewer-Pro, a meticulous document auditor. You evaluate submissions against the Reviewer toolkit's methodology (loaded from the `review-spec` document) and the seeded review principles. Voice: precise, unsentimental, citation-oriented.\n\n## Protocol\n\n1. Retrieve relevant sections of the review spec on demand.\n2. Cite seeded principles by name when applicable.\n3. Produce a single-paragraph verdict with a confidence score.", "budget_profile": "deep" } ], "goals": [ { "title": "Stale submissions patrol", "description": "Flag submissions sitting in_review for >7 days.", "rules": { "trigger": "schedule", "agent": "reviewer_pro", "context_query": "type=submission AND status=in_review AND updated_at < now() - 7d" }, "schedules": { "cron": "0 9 * * *", "timezone": "UTC" }, "reporting_cadence": "weekly", "status": "active" } ], "knowledge_seed": { "group_id": "reviewer-principles", "entities": [ { "name": "Citation-Density Principle", "entity_type": "concept", "summary": "Strong reviews cite specific lines, not vibes. Density of citation per claim is the canonical signal of seriousness.", "attributes": { "tier": "core" } }, { "name": "Scope-Match Check", "entity_type": "concept", "summary": "A review must operate within the submission's declared scope; finding flaws outside that scope is interesting but not load-bearing.", "attributes": { "tier": "core" } } ], "relationships": [ { "source": "Citation-Density Principle", "target": "Scope-Match Check", "type": "complemented_by", "fact": "Citation density bounded by declared scope keeps reviews actionable.", "weight": 0.7 } ] }, "entity_instances": [ { "entity_type": "submission", "name": "Example submission template", "data": { "body": "A placeholder so reviewers see the empty-queue shape on day one.", "status": "received", "knowledge_links": ["Citation-Density Principle"] } } ], "documents": [ { "slug": "review-spec", "name": "Reviewer Methodology Spec", "content_type": "text/markdown", "content": "# Reviewer Methodology\n\n## Part I — Principles\n\nAll reviews must respect citation density and scope-match.\n\n## Part II — Procedure\n\n### Intake\n\n1. Confirm submission has a declared scope.\n2. Stamp received_at.\n\n### Audit pass\n\n1. Retrieve relevant principles via the knowledge bridge.\n2. Cite by name in the verdict.\n\n## Part III — Verdict format\n\nOne paragraph. Plain prose. Confidence as a 0..1 number at the end." } ], "metadata": { "author": "Example Author", "publisher_instance": "example", "bill_of_materials": { "tool_count": 1, "widget_count": 0, "entity_type_count": 1, "entity_types": ["submission"], "playbook_count": 1, "playbooks": ["pb_reviewer_audit"], "menu_items": 1, "has_goals": true, "agent_count": 1, "goal_count": 1, "entity_instance_count": 1, "knowledge_seed_entity_count": 2, "knowledge_seed_relationship_count": 1, "document_count": 1, "document_total_bytes": 396 } } } ``` What this demonstrates: - A custom agent (`reviewer_pro`) the toolkit ships, with a `deep` budget hint and a multi-paragraph system prompt that won't pollute every conversation. - A goal that runs autonomously on cron, using the custom agent. - A two-entity knowledge seed with one relationship, queryable via `window.jootle.knowledge.search` and `.get`. - A seed entity instance that soft-links to the knowledge seed via `data.knowledge_links`. - A methodology document with three sections, retrievable section-by-section via `window.jootle.documents.get('review-spec', { section: 'Part II — Procedure/Audit pass' })`. The `ai_context` stays under 100 words — substance lives in the document and the KG. --- ## Validation checklist Before delivering a `.jtf.json` to a customer, run through this list: **Structure** - [ ] `bundle_schema` is `"1.0"` (v1.0-only fields) OR `"1.1"` (if you use any v1.1 field: `agents`, `goals`, `entity_instances`, `knowledge_seed`, `documents`). - [ ] `toolkit.slug`, `toolkit.title`, `toolkit.icon`, `toolkit.category` all present. - [ ] `manifest.version` follows semver (e.g., `"1.0.0"`). - [ ] `manifest.ai_context` is non-empty and under 2000 words. - [ ] `members[]` has at least one entry. - [ ] Each member has `slug`, `title`, `content`, `sort_order`. - [ ] If `entity_types[]` present, each has unique `slug` and valid field types (`text`/`enum`/`number`/`boolean`/`json`). - [ ] If `playbooks[]` present, every node has an `id`, `node_type`, and `ordering`; every edge references existing node IDs. - [ ] `metadata.bill_of_materials` counts match the actual content (including v1.1 counts when applicable). **v1.1 fields (skip if your bundle is v1.0)** - [ ] If `agents[]` present, each has `name` (prefixed with toolkit slug) and `description`. `budget_profile` (if set) is one of `fast`/`balanced`/`deep`/`thinking`. - [ ] If `goals[]` present, each has `title` (unique within bundle), `rules`, and references only agents/playbooks shipped in this same bundle (or core ones). - [ ] If `entity_instances[]` present, each `entity_type` refers to either this bundle's `entity_types[]` or a core type. Each has `name` and `data`. - [ ] If `knowledge_seed` present, `group_id` follows `-` convention. Every relationship's `source` and `target` names match an entry in `knowledge_seed.entities[]`. - [ ] If `documents[]` present, each has unique `slug` (within this toolkit), `name`, `content_type`, and `content`. No document exceeds 2 MB. - [ ] If you use any v1.1 field, `bundle_schema` is `"1.1"` (not `"1.0"`). **Content quality** - [ ] Member HTML uses theme tokens (`var(--accent)`, etc.) rather than literal colors. - [ ] No `