← UserorbitCONTENT HISTORY

Update to Userorbit

Snapshot Oct 29, 2026 · 19:12 UTC · version 1.0.16

Collection source: downloaded plugin package.

WHAT CHANGED

Instructions updated for release-review

Skill instructions — Now says: Announcement and article draft tools save or edit unpublished, unscheduled drafts only. Other operations may be available with separate permissions; use them...

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

Save Userorbit and check future changes in Following.

Up to 10 plugins free · no card required.

All fields and original values.

Skill instructions

Before

Oct 29, 2026 · 12:07 UTC

The public launch supports saving and editing unpublished, unscheduled drafts only. Publish, schedule, send, or edit published content in Userorbit; explain the available draft workflow instead of claiming those actions are supported here.

After

Oct 29, 2026 · 19:12 UTC

Announcement and article draft tools save or edit unpublished, unscheduled drafts only. Other operations may be available with separate permissions; use them only for an explicitly requested action and never imply a draft was published o...

Compare saved observations

Download comparison JSON

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -15,4 +15,4 @@
 
 Offer an appropriate next action in Userorbit. If saving is requested, resolve the target announcement collection using available tools. Saving a draft is separate from publication: do not set publication, scheduling, or notification fields for a draft. Follow the connected tool's actual schema and verify the saved state. Return the saved announcement's tool-provided link with a clear label such as “Open saved draft”; do not claim it was saved without a successful write result. Before editing a saved announcement, read it and send its numeric revision as `lastRevision` when the tool supports that field. If the revision changed, re-read and reconcile before retrying. Updating tours or articles, publishing content, and notifying users require authorization for those actions; a release review alone authorizes suggestions.
 
-The public launch supports saving and editing unpublished, unscheduled drafts only. Publish, schedule, send, or edit published content in Userorbit; explain the available draft workflow instead of claiming those actions are supported here.
+Announcement and article draft tools save or edit unpublished, unscheduled drafts only. Other operations may be available with separate permissions; use them only for an explicitly requested action and never imply a draft was published or sent.
Full technical diff · 1 changed fields

changed /skill_md_contents

BEFORE
"---\nname: release-review\ndescription: Turn completed Userorbit feature requests into changelog or release-note drafts, or review supplied release notes for relevant customer onboarding, product tour, checklist, and help center updates. Use when the user asks to work with Userorbit; do not claim access to an automatic release feed.\n---\n\nUse only the connected Userorbit tools exposed in this chat. Do not use local API credentials, direct HTTP requests, browser automation, or another account as a fallback. If a required operation is missing or denied, explain the connected-tool limitation and ask for the missing source or an appropriate connection; do not broaden grants automatically.\n\nFor release notes, start with `userorbit_completed_feedback` when available; it fixes status to `completed` and accepts the requested board, creation-date range, limit, and offset. If it is unavailable, use an exposed feedback list operation with status `completed`. In the public profile this is `userorbit_feedbacks_list`; in a legacy profile use `userorbit_feedbacks_read` (or the read-only `userorbit_feedbacks`) with action `list` and params containing the filters. Omit search when listing by status. Do not send an empty unified search or guess keywords to reconstruct a completed-status list. `userorbit_context` returns grant-filtered release-note tool routes when orientation is needed; it does not make a missing tool callable.\n\nFollow `pageInfo.nextOffset` until the required scope is covered. A full page without a total means possibly more results. Use list content when it supplies sufficient evidence; inspect only relevant candidate records whose detail is needed, rather than fetching every search match. Completed status is evidence of completion, not a deployment timestamp: do not infer that every returned item shipped in that period. Use supplied release notes or explicit shipment evidence to establish release scope; label an unconfirmed list as candidate release items. Ask for release scope when needed.\n\nFor a release review, use the release notes or records supplied by the user. Inspect relevant existing tours and tour steps, onboarding checklists, and help articles through the available Userorbit tools. Connect suggestions only to actual behavior changes. A backend fix may need no customer-facing update. Do not suggest all surfaces for every release.\n\nShow the release-note draft or a table of suggested changes directly in chat. Identify the existing asset, relevant release change, and proposed replacement text or steps. Cite supporting records with the URLs returned by the tools, including `recordLinks` where present; otherwise use the returned titles and identifiers. Never invent source or edit links. Separate confirmed behavior from assumptions and unresolved questions.\n\nOffer an appropriate next action in Userorbit. If saving is requested, resolve the target announcement collection using available tools. Saving a draft is separate from publication: do not set publication, scheduling, or notification fields for a draft. Follow the connected tool's actual schema and verify the saved state. Return the saved announcement's tool-provided link with a clear label such as “Open saved draft”; do not claim it was saved without a successful write result. Before editing a saved announcement, read it and send its numeric revision as `lastRevision` when the tool supports that field. If the revision changed, re-read and reconcile before retrying. Updating tours or articles, publishing content, and notifying users require authorization for those actions; a release review alone authorizes suggestions.\n\nThe public launch supports saving and editing unpublished, unscheduled drafts only. Publish, schedule, send, or edit published content in Userorbit; explain the available draft workflow instead of claiming those actions are supported here.\n"
AFTER
"---\nname: release-review\ndescription: Turn completed Userorbit feature requests into changelog or release-note drafts, or review supplied release notes for relevant customer onboarding, product tour, checklist, and help center updates. Use when the user asks to work with Userorbit; do not claim access to an automatic release feed.\n---\n\nUse only the connected Userorbit tools exposed in this chat. Do not use local API credentials, direct HTTP requests, browser automation, or another account as a fallback. If a required operation is missing or denied, explain the connected-tool limitation and ask for the missing source or an appropriate connection; do not broaden grants automatically.\n\nFor release notes, start with `userorbit_completed_feedback` when available; it fixes status to `completed` and accepts the requested board, creation-date range, limit, and offset. If it is unavailable, use an exposed feedback list operation with status `completed`. In the public profile this is `userorbit_feedbacks_list`; in a legacy profile use `userorbit_feedbacks_read` (or the read-only `userorbit_feedbacks`) with action `list` and params containing the filters. Omit search when listing by status. Do not send an empty unified search or guess keywords to reconstruct a completed-status list. `userorbit_context` returns grant-filtered release-note tool routes when orientation is needed; it does not make a missing tool callable.\n\nFollow `pageInfo.nextOffset` until the required scope is covered. A full page without a total means possibly more results. Use list content when it supplies sufficient evidence; inspect only relevant candidate records whose detail is needed, rather than fetching every search match. Completed status is evidence of completion, not a deployment timestamp: do not infer that every returned item shipped in that period. Use supplied release notes or explicit shipment evidence to establish release scope; label an unconfirmed list as candidate release items. Ask for release scope when needed.\n\nFor a release review, use the release notes or records supplied by the user. Inspect relevant existing tours and tour steps, onboarding checklists, and help articles through the available Userorbit tools. Connect suggestions only to actual behavior changes. A backend fix may need no customer-facing update. Do not suggest all surfaces for every release.\n\nShow the release-note draft or a table of suggested changes directly in chat. Identify the existing asset, relevant release change, and proposed replacement text or steps. Cite supporting records with the URLs returned by the tools, including `recordLinks` where present; otherwise use the returned titles and identifiers. Never invent source or edit links. Separate confirmed behavior from assumptions and unresolved questions.\n\nOffer an appropriate next action in Userorbit. If saving is requested, resolve the target announcement collection using available tools. Saving a draft is separate from publication: do not set publication, scheduling, or notification fields for a draft. Follow the connected tool's actual schema and verify the saved state. Return the saved announcement's tool-provided link with a clear label such as “Open saved draft”; do not claim it was saved without a successful write result. Before editing a saved announcement, read it and send its numeric revision as `lastRevision` when the tool supports that field. If the revision changed, re-read and reconcile before retrying. Updating tours or articles, publishing content, and notifying users require authorization for those actions; a release review alone authorizes suggestions.\n\nAnnouncement and article draft tools save or edit unpublished, unscheduled drafts only. Other operations may be available with separate permissions; use them only for an explicitly requested action and never imply a draft was published or sent.\n"
Full snapshot data
{
  "description": "Turn completed Userorbit feature requests into changelog or release-note drafts, or review supplied release notes for relevant customer onboarding, product tour, checklist, and help center updates. Use when the user asks to work with Userorbit; do not claim access to an automatic release feed.",
  "included_files": [],
  "name": "release-review",
  "skill_md_contents": "---\nname: release-review\ndescription: Turn completed Userorbit feature requests into changelog or release-note drafts, or review supplied release notes for relevant customer onboarding, product tour, checklist, and help center updates. Use when the user asks to work with Userorbit; do not claim access to an automatic release feed.\n---\n\nUse only the connected Userorbit tools exposed in this chat. Do not use local API credentials, direct HTTP requests, browser automation, or another account as a fallback. If a required operation is missing or denied, explain the connected-tool limitation and ask for the missing source or an appropriate connection; do not broaden grants automatically.\n\nFor release notes, start with `userorbit_completed_feedback` when available; it fixes status to `completed` and accepts the requested board, creation-date range, limit, and offset. If it is unavailable, use an exposed feedback list operation with status `completed`. In the public profile this is `userorbit_feedbacks_list`; in a legacy profile use `userorbit_feedbacks_read` (or the read-only `userorbit_feedbacks`) with action `list` and params containing the filters. Omit search when listing by status. Do not send an empty unified search or guess keywords to reconstruct a completed-status list. `userorbit_context` returns grant-filtered release-note tool routes when orientation is needed; it does not make a missing tool callable.\n\nFollow `pageInfo.nextOffset` until the required scope is covered. A full page without a total means possibly more results. Use list content when it supplies sufficient evidence; inspect only relevant candidate records whose detail is needed, rather than fetching every search match. Completed status is evidence of completion, not a deployment timestamp: do not infer that every returned item shipped in that period. Use supplied release notes or explicit shipment evidence to establish release scope; label an unconfirmed list as candidate release items. Ask for release scope when needed.\n\nFor a release review, use the release notes or records supplied by the user. Inspect relevant existing tours and tour steps, onboarding checklists, and help articles through the available Userorbit tools. Connect suggestions only to actual behavior changes. A backend fix may need no customer-facing update. Do not suggest all surfaces for every release.\n\nShow the release-note draft or a table of suggested changes directly in chat. Identify the existing asset, relevant release change, and proposed replacement text or steps. Cite supporting records with the URLs returned by the tools, including `recordLinks` where present; otherwise use the returned titles and identifiers. Never invent source or edit links. Separate confirmed behavior from assumptions and unresolved questions.\n\nOffer an appropriate next action in Userorbit. If saving is requested, resolve the target announcement collection using available tools. Saving a draft is separate from publication: do not set publication, scheduling, or notification fields for a draft. Follow the connected tool's actual schema and verify the saved state. Return the saved announcement's tool-provided link with a clear label such as “Open saved draft”; do not claim it was saved without a successful write result. Before editing a saved announcement, read it and send its numeric revision as `lastRevision` when the tool supports that field. If the revision changed, re-read and reconcile before retrying. Updating tours or articles, publishing content, and notifying users require authorization for those actions; a release review alone authorizes suggestions.\n\nAnnouncement and article draft tools save or edit unpublished, unscheduled drafts only. Other operations may be available with separate permissions; use them only for an explicitly requested action and never imply a draft was published or sent.\n"
}

SHA-256 of public snapshot: afe172d8db983e69531981ca83dc3b74783d06b28b73f1b3e1219c12744b72ab