← WorktableCONTENT HISTORY

Update to Worktable

Snapshot Oct 28, 2026 · 13:02 UTC · version 0.1.5

Collection source: downloaded plugin package.

WHAT CHANGED

Instructions updated for worktable-create-or-manage-interactive-html

Skill instructions — Now says: `worktable_files_read`; change it later with `worktable_files_write` action `set_lifetime`. On an older connection without file tool names, use...

Observed in instructions or declared skills. Runtime behavior has not been tested.

Save Worktable and check future changes in Following.

Up to 10 plugins free · no card required.

All fields and original values.

Skill instructions

Before

Oct 24, 2026 · 13:45 UTC

`worktable_documents_read`; change it later with `worktable_documents_write` action `set_lifetime`.

After

Oct 28, 2026 · 13:02 UTC

`worktable_files_read`; change it later with `worktable_files_write` action `set_lifetime`. On an older connection without file tool names, use `worktable_documents_read` and `worktable_documents_write` with the same advertised actions.

Compare saved observations

Download comparison JSON

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -17,7 +17,7 @@
 
 ## 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_documents_read`; change it later with `worktable_documents_write` action `set_lifetime`.
+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.
 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.
@@ -34,3 +34,5 @@
 - **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

BEFORE
"---\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_documents_read`; change it later with `worktable_documents_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"
AFTER
"---\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"
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\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"
}

SHA-256 of public snapshot: 93d3b1cde57053d3d24dbd90f8be218b4afcee28b26305684a22d3b6b722d587