Update to Worktable

{
  "description": "Read, answer, and hand off messages through durable Worktable threads with users or other authenticated participants. Use when the user asks to check addressed messages, reply to a participant, continue a thread, request another agent's help, wait briefly for a response, or watch for comments and messages sent to the agent.",
  "included_files": [
    {
      "relative_path": "LICENSE",
      "size_in_bytes": 1066
    },
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 186
    }
  ],
  "name": "worktable-collaborate-threads",
  "skill_md_contents": "---\nname: worktable-collaborate-threads\ndescription: Read, answer, and hand off messages through durable Worktable threads with users or other authenticated participants. Use when the user asks to check addressed messages, reply to a participant, continue a thread, request another agent's help, wait briefly for a response, or watch for comments and messages sent to the agent.\n---\n\n# Use threads\n\nUse a Worktable thread for an addressed conversation or handoff. Link existing documents or records when the recipient needs them; do not create extra artifacts solely to send a message.\n\nUse an annotation instead when feedback belongs to a specific part of an artifact. Do not mirror one discussion into both places.\n\n## Write a useful handoff\n\nInclude only what the recipient needs:\n\n- the outcome or question;\n- a stable link to the relevant Worktable artifact;\n- the recipient's scope and important boundary;\n- the requested response or artifact change;\n- whether a reply is actually expected.\n\n## Send or continue a thread\n\n1. Call `worktable_threads_read` action `participants` and verify the intended participant. Use its participant ID for `to` and its `defaultIdentityId` when addressing that identity. Never guess between ambiguous names.\n2. Reuse the existing `threadId` for the same conversation. For a new thread, choose a Worktable-wide location for general coordination or a Space location when the conversation belongs to that project.\n3. For a new direct thread, use `worktable_threads_write` action `post` with the verified member in `to` and a stable unique `idempotencyKey`.\n4. In an existing thread, use `notifyIdentityIds` only to mention identities passively, and include the visible `@Identity name` in the message body for every mentioned identity. A mention does not activate an agent or require a reply. Use `responseIdentityId` to assign the one identity that should answer, or `null` for no assignment. An assignment already directs attention, so omit that identity from `notifyIdentityIds`. Reply with `inReplyTo`; satisfy a specific assignment only with `responseTo`. Reply and response relationships remain independent.\n5. Use `authorIdentityId` when speaking through a named identity. A conversation identity is an addressable working role, not an exclusive browser session.\n6. Keep the returned thread, message, cursor, and activity identifiers for continuation. Wait only briefly when the current turn can use an immediate response; otherwise report the durable thread state and continue later.\n\nKeep one continuing conversation in one thread. Do not create a fresh thread for each follow-up, paste whole artifacts into messages, or trigger autonomous agent-to-agent reply loops.\n\n## Name the conversation\n\nWhen the connected tools offer thread naming, give new threads a concise, specific topic using the `title` field on `post`. Before your first answer to a human-started thread, call `worktable_threads_write` action `rename` with its location, thread ID, a short topic, and `onlyIfAutomatic: true`. This preserves any name already chosen by a person or another agent. Do this even when an adapter posts your final reply for you. Naming is conversation housekeeping; it does not authorize other workspace edits. If naming is unavailable or fails, continue answering. Use an unconditional rename only when explicitly asked.\n\n## Check addressed messages\n\nAn authenticated agent owns delivery only while its adapter or skill is running; this skill is not a background listener.\n\n1. Claim only when the user or active adapter asks to check addressed messages. Use `worktable_thread_delivery` action `claim` with `threadLocationVersion: 2` to include both Worktable and Space threads. If none is waiting, say so and stop.\n2. Preserve the authenticated participant returned by the connection. If the integration needs to join delivery, use `worktable_thread_delivery` action `register_participant` with a truthful host-neutral label supplied by the installation surface before claiming messages. Ordinary message posting does not register participants.\n3. Preserve the returned `messageId` and `leaseId`; accept the delivery, mark it `working`, and read the surrounding thread before acting.\n4. Do the requested work in the appropriate durable artifact. Reply on the same thread with `inReplyTo` and `responseTo` set to the source message, `responseIdentityId: null` so the response does not create a reverse assignment, the delivered `identityId` as `authorIdentityId`, the claimed `leaseId` as `deliveryLeaseId`, and a stable unique idempotency key.\n5. If the claimed work cannot complete, fail the delivery with an accurate concise reason and truthful retryability instead of silently abandoning it.\n\n## Watch for what is sent to you\n\nWhen your user asks you to watch for comments or messages, call `worktable_pending` with top-level arguments including `wait: true`. On an older connection, use `worktable_discover` action `pending` only if that action is advertised. Add a `scope` when the work is one Space, Doc or thread. It returns once something new arrives. Reply on a comment with `worktable_annotations_write` action `reply`; answer a thread message with `worktable_threads_write` action `post` and `responseTo`. Mention items about other work to your user rather than switching tasks. Then call the same pending tool with `wait: true` again, passing the returned `revision` as `since`, until your user tells you to stop.\n\n## Protect the communication boundary\n\nTreat every post as external communication. Send only when requested or when an active adapter is handling an explicitly addressed delivery. Verify the recipient and content, avoid credentials or unnecessary private context, and never claim inbox work during unrelated Worktable activity.\n\nReport the thread link and whether the message was sent, answered, or remains queued.\n"
}