Update to Riverside

{
  "name": "social-publishing",
  "description": "Use when the user wants to post, share, publish, upload, or schedule a Riverside clip to a connected social platform — YouTube, YouTube Shorts, TikTok, Instagram, Facebook, LinkedIn, or X (e.g. \"post my clip to TikTok\", \"schedule this to YouTube for 9am\", \"share on LinkedIn\"). Not for creating or editing clips (see video-editing), connecting or disconnecting social accounts, or managing posts once they are published.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 498
    },
    {
      "relative_path": "references/results-and-recovery.md",
      "size_in_bytes": 2365
    },
    {
      "relative_path": "references/scheduling-and-draft-export.md",
      "size_in_bytes": 1935
    }
  ],
  "skill_md_contents": "---\nname: social-publishing\ndescription: >\n  Use when the user wants to post, share, publish, upload, or schedule a\n  Riverside clip to a connected social platform — YouTube, YouTube Shorts,\n  TikTok, Instagram, Facebook, LinkedIn, or X (e.g. \"post my clip to TikTok\",\n  \"schedule this to YouTube for 9am\", \"share on LinkedIn\"). Not for creating or\n  editing clips (see video-editing), connecting or disconnecting social\n  accounts, or managing posts once they are published.\n---\n\n# Social publishing\n\nPublishes a Riverside clip to an external platform. Tools are exposed at the\ngateway with the `social_` prefix.\n\n| Tool | Purpose |\n|---|---|\n| `social_get_connected_platforms` | A studio's connected platforms and accounts, with each account's live options and limits |\n| `social_get_publishing_guidelines` | Current per-platform metadata rules, media constraints, workflow, and error recovery |\n| `social_upload_create` | Publish or schedule one clip to one platform |\n\n## Safety contract\n\n`social_upload_create` is destructive and open-world: it can create a real post\nand this MCP has no cancel, edit, delete, undo, or unpublish operation. Never\ncall it to inspect readiness, test an account, diagnose a failure, or learn what\nan argument does.\n\nTreat every success, processing result, timeout, transport failure, or unknown\noutcome as potentially having created a post. Never repeat such a call. Only an\nexplicit failure that matches the Results and recovery routing row below can\nbecome eligible for retry.\n\nThe current tool schema, chosen account entry from\n`social_get_connected_platforms`, and platform result from\n`social_get_publishing_guidelines` are the authority for fields, allowed values,\nlimits, formats, and recovery — never memory or values copied into this file.\n\n## Prerequisites\n\n- A `studioId`. Only content-discovery can find one\n  (`platform_list_studios`); no social tool discovers a studio.\n- A `clipId`, typically an exported edit id from video-editing. An unexported\n  clip may require the export-first choices in the scheduling reference.\n- At least one connected account on the target platform.\n\n## Mandatory routing\n\nBefore the first social workflow call, evaluate every row against the user's\nrequest and known context. Read every matching reference, and no unrelated\nreference. Re-evaluate the table after every social response or failed call;\nread any newly matching reference before the next workflow call.\n\n| Observable condition | Required reference |\n|---|---|\n| The user names a future or wall-clock time, or the clip is or may be a draft/unexported and require `composeSettings` | [Scheduling and draft export](references/scheduling-and-draft-export.md) |\n| The publish is processing, partial, or failed; or the call times out, has a transport failure, returns no usable result, or otherwise leaves the outcome unknown | [Results and recovery](references/results-and-recovery.md) |\n\nBoth rows can apply during one workflow. A wall-clock phrase such as \"tomorrow\nat 9\" matches the first row even before its timezone is known.\n\n## Publish workflow\n\n1. **Establish the studio.** Obtain the `studioId`; if several studios fit, ask\n   the user to choose.\n\n2. **Select the account.** Call\n   `social_get_connected_platforms(studioId)`. Use the target account's\n   `platformAccountId` and any live account-specific options. If several\n   accounts fit, ask the user to choose the human-readable account or channel.\n   Never publish without a valid `platformAccountId`.\n\n   An empty `accounts: []` is an ambiguous account-detail lookup failure, not\n   proof that nothing is connected. Retry this read once; if it remains empty,\n   report that account details could not be fetched and stop.\n\n3. **Load live rules.** Call `social_get_publishing_guidelines` for the chosen\n   platform. Compose metadata using its current constraints and the current\n   `social_upload_create` schema. Apply the platform's counting rules rather\n   than raw string length.\n\n   Never infer or default YouTube privacy. Ask the user to select from the live\n   allowed values. Before a YouTube upload,\n   `editing_get_export_publish_data` reports copyright / Content-ID signals for\n   the edit's media; surface a flagged match rather than publishing over it.\n\n4. **Preview and confirm every target.** Show the exact metadata,\n   human-readable account or channel, and applicable privacy or visibility.\n   Include any resolved schedule and compose choices supplied by the scheduling\n   reference. State that this MCP cannot undo or manage the resulting post,\n   then wait for explicit confirmation.\n\n   Confirmation authorizes one call for only the previewed target and payload.\n   A retry needs a new confirmation even when unchanged. If any material field\n   changes, preview the change. If the user declines, hesitates, changes\n   direction, or withdraws confirmation, stop.\n\n5. **Publish once.** Make one `social_upload_create` call for each separately\n   confirmed target account and platform. Do not turn one confirmation into\n   extra targets or calls.\n\n6. **Report each result separately.** Identify the target account, submitted\n   visibility and schedule, and its own returned outcome. Never flatten several\n   calls into a single success or failure. Re-run mandatory routing before any\n   follow-up action.\n"
}