Update to Worktable
Snapshot Oct 28, 2026 · 18:05 UTC · version 0.1.6
Collection source: downloaded plugin package.
Instructions updated for worktable-create-or-manage-interactive-html
Skill instructions — Now says: Use the Worktable tools the connection lists. On a Worktable that lists the earlier grouped tools, such as `worktable_discover`, use the listed tool with the...
Observed in instructions or declared skills. Runtime behavior has not been tested.
Up to 10 plugins free · no card required.
All fields and original values.
Skill instructions
Oct 28, 2026 · 13:02 UTC
1. Discover the workspace and related artifacts. Update the existing HTML Doc when it already owns the job. A new HTML Doc needs a `lifetime`: `durable` for interfaces people will return to, `temporary` for a one-off view that only suppo...
Oct 28, 2026 · 18:05 UTC
Use the Worktable tools the connection lists. On a Worktable that lists the earlier grouped tools, such as `worktable_discover`, use the listed tool with the matching `request.action` instead. 1. Discover the workspace and related artifa...
Compare saved observations
Download comparison JSONSKILL.md text changes
− removed · + added
--- before +++ after @@ -8,6 +8,8 @@ Use an HTML doc for an interactive tool, visual explanation, or custom view. Keep it understandable when opened outside the current conversation. +Use the Worktable tools the connection lists. On a Worktable that lists the earlier grouped tools, such as `worktable_discover`, use the listed tool with the matching `request.action` instead. + ## Choose the composition - **Presentation or visual brief:** keep the complete high-level experience in one HTML Doc. Link a narrative Doc when deeper reasoning or source notes matter independently. @@ -17,13 +19,13 @@ ## Build the artifact -1. Discover the workspace and related artifacts. Update the existing HTML Doc when it already owns the job. A new HTML Doc needs a `lifetime`: `durable` for interfaces people will return to, `temporary` for a one-off view that only supports current work. Check a document's lifetime with `worktable_files_read`; change it later with `worktable_files_write` action `set_lifetime`. -2. Before updating an existing HTML Doc, read its complete source with `worktable_html_read` action `read`. List open annotations with `worktable_annotations_read` filtered by its `htmlId`, inspect the context of relevant instructions, and preserve user-owned content that the request does not replace. +1. Discover the workspace and related artifacts. Update the existing HTML Doc when it already owns the job. A new HTML Doc needs a `lifetime`: `durable` for interfaces people will return to, `temporary` for a one-off view that only supports current work. Check a document's lifetime with `worktable_files_read`; change it later with `worktable_files_update` and `lifetime`. +2. Before updating an existing HTML Doc, read its complete source with `worktable_html_read` and `includeHtml: true`. List open annotations with `worktable_annotations_read` filtered by its `htmlId`, inspect the context of relevant instructions, and preserve user-owned content that the request does not replace. 3. Make the purpose and primary action clear. Use the content and task to choose the layout. -4. Read `worktable_html_read` action `guide` with the `runtime` profile for the authoritative sandbox, bridge, permission, and data contract. Do not treat visual workflow guidance as a server security boundary. +4. Read `worktable_guidance` with `topic: "html"` and the `runtime` profile for the authoritative sandbox, bridge, permission, and data contract. Do not treat visual workflow guidance as a server security boundary. 5. Model and seed canonical Records first when the interface depends on them. Then write one complete self-contained HTML document with the narrowest permissions that cover its actual calls. 6. Validate Mermaid sources with `worktable_mermaid` when embedding a diagram or returned SVG. Repair actionable Worktable validation warnings. -7. Inspect desktop/mobile and light/dark screenshots with `worktable_html_read` action `render` (or request a `preview` on create/update). Read the image and diagnostics, then correct the source. Previews disable persistent writes and external network; `partial` identifies incomplete or blocked content. If a saved write's preview fails, retry `render`, not the mutation. Separately exercise important controls in the real interface and verify that intended Record mutations survive rereading the collection. +7. Inspect desktop/mobile and light/dark screenshots with `worktable_files_render` (or request a `preview` when you write the HTML). Read the image and diagnostics, then correct the source. Previews disable persistent writes and external network; `partial` identifies incomplete or blocked content. If a saved write's preview fails, retry `worktable_files_render`, not the write. Separately exercise important controls in the real interface and verify that intended Record mutations survive rereading the collection. ## Verify the result @@ -34,5 +36,3 @@ - **Continuity:** explain the artifact without relying on the transcript, link supporting durable work, preserve user-owned content, and make the next update straightforward. Return `urlToSendInChat` as the entry point and briefly name the durable sources behind the interface. The artifact is complete when its purpose is clear, its important path works with the intended data, and the user can return through one stable link. - -On an older connection without file tool names, use `worktable_documents_read` and `worktable_documents_write` with the same advertised actions.
Full technical diff · 1 changed fields
changed /skill_md_contents
"---\nname: worktable-create-or-manage-interactive-html\ndescription: Create or improve durable visual and interactive artifacts in Worktable. Use for dashboards, trackers, calculators, mini apps, slide presentations, and other requests that benefit from a polished HTML Doc.\n---\n\n# Build HTML\n\nUse an HTML doc for an interactive tool, visual explanation, or custom view.\nKeep it understandable when opened outside the current conversation.\n\n## Choose the composition\n\n- **Presentation or visual brief:** keep the complete high-level experience in one HTML Doc. Link a narrative Doc when deeper reasoning or source notes matter independently.\n- **Board, tracker, planner, directory, or dashboard:** keep independently changing entities in Records; make the HTML Doc a focused view that subscribes to and updates those Records.\n- **Calculator or mini tool:** keep deterministic logic in the HTML. Use `worktable.state` only for interface-local drafts, filters, selections, or preferences. Create Records only when outputs need durable identity or reuse.\n- **Live external data:** request network access only when the user actually needs it. Prefer Worktable runtime APIs for Worktable data.\n\n## Build the artifact\n\n1. Discover the workspace and related artifacts. Update the existing HTML Doc when it already owns the job. A new HTML Doc needs a `lifetime`: `durable` for interfaces people will return to, `temporary` for a one-off view that only supports current work. Check a document's lifetime with `worktable_files_read`; change it later with `worktable_files_write` action `set_lifetime`.\n2. Before updating an existing HTML Doc, read its complete source with `worktable_html_read` action `read`. List open annotations with `worktable_annotations_read` filtered by its `htmlId`, inspect the context of relevant instructions, and preserve user-owned content that the request does not replace.\n3. Make the purpose and primary action clear. Use the content and task to choose the layout.\n4. Read `worktable_html_read` action `guide` with the `runtime` profile for the authoritative sandbox, bridge, permission, and data contract. Do not treat visual workflow guidance as a server security boundary.\n5. Model and seed canonical Records first when the interface depends on them. Then write one complete self-contained HTML document with the narrowest permissions that cover its actual calls.\n6. Validate Mermaid sources with `worktable_mermaid` when embedding a diagram or returned SVG. Repair actionable Worktable validation warnings.\n7. Inspect desktop/mobile and light/dark screenshots with `worktable_html_read` action `render` (or request a `preview` on create/update). Read the image and diagnostics, then correct the source. Previews disable persistent writes and external network; `partial` identifies incomplete or blocked content. If a saved write's preview fails, retry `render`, not the mutation. Separately exercise important controls in the real interface and verify that intended Record mutations survive rereading the collection.\n\n## Verify the result\n\n- **Comprehension:** use descriptive headings and a clear next action. Remove controls, metrics, and decoration that do not help the task.\n- **Visual craft:** refine typography, line length, spacing rhythm, alignment, contrast, and negative space. Use real content, responsive composition, and coherent light and dark themes through Worktable semantic variables.\n- **Interaction:** give every control a purpose and legible loading, saving, success, empty, and failure states where relevant. Record-backed actions must update canonical Records, not only local HTML.\n- **Accessibility:** use semantic headings and native controls, visible focus, keyboard operation, comfortable targets, reduced-motion support, and a non-drag path for drag-and-drop workflows.\n- **Continuity:** explain the artifact without relying on the transcript, link supporting durable work, preserve user-owned content, and make the next update straightforward.\n\nReturn `urlToSendInChat` as the entry point and briefly name the durable sources behind the interface. The artifact is complete when its purpose is clear, its important path works with the intended data, and the user can return through one stable link.\n\nOn an older connection without file tool names, use `worktable_documents_read` and `worktable_documents_write` with the same advertised actions.\n"
"---\nname: worktable-create-or-manage-interactive-html\ndescription: Create or improve durable visual and interactive artifacts in Worktable. Use for dashboards, trackers, calculators, mini apps, slide presentations, and other requests that benefit from a polished HTML Doc.\n---\n\n# Build HTML\n\nUse an HTML doc for an interactive tool, visual explanation, or custom view.\nKeep it understandable when opened outside the current conversation.\n\nUse the Worktable tools the connection lists. On a Worktable that lists the earlier grouped tools, such as `worktable_discover`, use the listed tool with the matching `request.action` instead.\n\n## Choose the composition\n\n- **Presentation or visual brief:** keep the complete high-level experience in one HTML Doc. Link a narrative Doc when deeper reasoning or source notes matter independently.\n- **Board, tracker, planner, directory, or dashboard:** keep independently changing entities in Records; make the HTML Doc a focused view that subscribes to and updates those Records.\n- **Calculator or mini tool:** keep deterministic logic in the HTML. Use `worktable.state` only for interface-local drafts, filters, selections, or preferences. Create Records only when outputs need durable identity or reuse.\n- **Live external data:** request network access only when the user actually needs it. Prefer Worktable runtime APIs for Worktable data.\n\n## Build the artifact\n\n1. Discover the workspace and related artifacts. Update the existing HTML Doc when it already owns the job. A new HTML Doc needs a `lifetime`: `durable` for interfaces people will return to, `temporary` for a one-off view that only supports current work. Check a document's lifetime with `worktable_files_read`; change it later with `worktable_files_update` and `lifetime`.\n2. Before updating an existing HTML Doc, read its complete source with `worktable_html_read` and `includeHtml: true`. List open annotations with `worktable_annotations_read` filtered by its `htmlId`, inspect the context of relevant instructions, and preserve user-owned content that the request does not replace.\n3. Make the purpose and primary action clear. Use the content and task to choose the layout.\n4. Read `worktable_guidance` with `topic: \"html\"` and the `runtime` profile for the authoritative sandbox, bridge, permission, and data contract. Do not treat visual workflow guidance as a server security boundary.\n5. Model and seed canonical Records first when the interface depends on them. Then write one complete self-contained HTML document with the narrowest permissions that cover its actual calls.\n6. Validate Mermaid sources with `worktable_mermaid` when embedding a diagram or returned SVG. Repair actionable Worktable validation warnings.\n7. Inspect desktop/mobile and light/dark screenshots with `worktable_files_render` (or request a `preview` when you write the HTML). Read the image and diagnostics, then correct the source. Previews disable persistent writes and external network; `partial` identifies incomplete or blocked content. If a saved write's preview fails, retry `worktable_files_render`, not the write. Separately exercise important controls in the real interface and verify that intended Record mutations survive rereading the collection.\n\n## Verify the result\n\n- **Comprehension:** use descriptive headings and a clear next action. Remove controls, metrics, and decoration that do not help the task.\n- **Visual craft:** refine typography, line length, spacing rhythm, alignment, contrast, and negative space. Use real content, responsive composition, and coherent light and dark themes through Worktable semantic variables.\n- **Interaction:** give every control a purpose and legible loading, saving, success, empty, and failure states where relevant. Record-backed actions must update canonical Records, not only local HTML.\n- **Accessibility:** use semantic headings and native controls, visible focus, keyboard operation, comfortable targets, reduced-motion support, and a non-drag path for drag-and-drop workflows.\n- **Continuity:** explain the artifact without relying on the transcript, link supporting durable work, preserve user-owned content, and make the next update straightforward.\n\nReturn `urlToSendInChat` as the entry point and briefly name the durable sources behind the interface. The artifact is complete when its purpose is clear, its important path works with the intended data, and the user can return through one stable link.\n"
Full snapshot data
{
"description": "Create or improve durable visual and interactive artifacts in Worktable. Use for dashboards, trackers, calculators, mini apps, slide presentations, and other requests that benefit from a polished HTML Doc.",
"included_files": [
{
"relative_path": "LICENSE",
"size_in_bytes": 1066
},
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 203
}
],
"name": "worktable-create-or-manage-interactive-html",
"skill_md_contents": "---\nname: worktable-create-or-manage-interactive-html\ndescription: Create or improve durable visual and interactive artifacts in Worktable. Use for dashboards, trackers, calculators, mini apps, slide presentations, and other requests that benefit from a polished HTML Doc.\n---\n\n# Build HTML\n\nUse an HTML doc for an interactive tool, visual explanation, or custom view.\nKeep it understandable when opened outside the current conversation.\n\nUse the Worktable tools the connection lists. On a Worktable that lists the earlier grouped tools, such as `worktable_discover`, use the listed tool with the matching `request.action` instead.\n\n## Choose the composition\n\n- **Presentation or visual brief:** keep the complete high-level experience in one HTML Doc. Link a narrative Doc when deeper reasoning or source notes matter independently.\n- **Board, tracker, planner, directory, or dashboard:** keep independently changing entities in Records; make the HTML Doc a focused view that subscribes to and updates those Records.\n- **Calculator or mini tool:** keep deterministic logic in the HTML. Use `worktable.state` only for interface-local drafts, filters, selections, or preferences. Create Records only when outputs need durable identity or reuse.\n- **Live external data:** request network access only when the user actually needs it. Prefer Worktable runtime APIs for Worktable data.\n\n## Build the artifact\n\n1. Discover the workspace and related artifacts. Update the existing HTML Doc when it already owns the job. A new HTML Doc needs a `lifetime`: `durable` for interfaces people will return to, `temporary` for a one-off view that only supports current work. Check a document's lifetime with `worktable_files_read`; change it later with `worktable_files_update` and `lifetime`.\n2. Before updating an existing HTML Doc, read its complete source with `worktable_html_read` and `includeHtml: true`. List open annotations with `worktable_annotations_read` filtered by its `htmlId`, inspect the context of relevant instructions, and preserve user-owned content that the request does not replace.\n3. Make the purpose and primary action clear. Use the content and task to choose the layout.\n4. Read `worktable_guidance` with `topic: \"html\"` and the `runtime` profile for the authoritative sandbox, bridge, permission, and data contract. Do not treat visual workflow guidance as a server security boundary.\n5. Model and seed canonical Records first when the interface depends on them. Then write one complete self-contained HTML document with the narrowest permissions that cover its actual calls.\n6. Validate Mermaid sources with `worktable_mermaid` when embedding a diagram or returned SVG. Repair actionable Worktable validation warnings.\n7. Inspect desktop/mobile and light/dark screenshots with `worktable_files_render` (or request a `preview` when you write the HTML). Read the image and diagnostics, then correct the source. Previews disable persistent writes and external network; `partial` identifies incomplete or blocked content. If a saved write's preview fails, retry `worktable_files_render`, not the write. Separately exercise important controls in the real interface and verify that intended Record mutations survive rereading the collection.\n\n## Verify the result\n\n- **Comprehension:** use descriptive headings and a clear next action. Remove controls, metrics, and decoration that do not help the task.\n- **Visual craft:** refine typography, line length, spacing rhythm, alignment, contrast, and negative space. Use real content, responsive composition, and coherent light and dark themes through Worktable semantic variables.\n- **Interaction:** give every control a purpose and legible loading, saving, success, empty, and failure states where relevant. Record-backed actions must update canonical Records, not only local HTML.\n- **Accessibility:** use semantic headings and native controls, visible focus, keyboard operation, comfortable targets, reduced-motion support, and a non-drag path for drag-and-drop workflows.\n- **Continuity:** explain the artifact without relying on the transcript, link supporting durable work, preserve user-owned content, and make the next update straightforward.\n\nReturn `urlToSendInChat` as the entry point and briefly name the durable sources behind the interface. The artifact is complete when its purpose is clear, its important path works with the intended data, and the user can return through one stable link.\n"
}SHA-256 of public snapshot: 3c5f7632973b02fdeffd86006c5769afe04fe82c7c8aa41ca6debc67f8d7e24a