Update to Velocity

{
  "description": "Upload user-supplied images or videos to Velocity and attach them to social posts. Use for post-media preparation and attachment, not media generation or image editing.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 107
    }
  ],
  "name": "media",
  "skill_md_contents": "---\nname: media\ndescription: \"Upload user-supplied images or videos to Velocity and attach them to social posts. Use for post-media preparation and attachment, not media generation or image editing.\"\n---\n\n# Post Media\n\nUse the authenticated Velocity MCP tools and their current schemas. Act within the user-requested workspace and scope. If tools are unavailable or authentication is required, explain the connection issue; do not substitute fabricated results.\n\nInspect upload_media's current schema. For a ChatGPT composer attachment, pass the actual host file reference in its supported file input. When an attachment is accessible as a file in code execution, use prepare_media_upload: calculate the original file byte count and SHA-256 programmatically, request an upload URL with its filename and MIME type, then HTTP PUT the original binary bytes from code execution to that exact URL using the returned Content-Type header. Use the successful PUT response media_url for the post. Never print the upload URL or its token to the user. Do not hand-transcribe base64. If code execution cannot reach the upload URL, report that limitation. Other clients can use a reachable user-provided URL or supported base64 input with the correct filename and MIME type. Base64 is suitable only when a programmatic bridge can pass the exact bytes directly; do not transcribe large encoded files through model output. If the host exposes only a sandbox file path and no supported file-transfer bridge, stop that upload attempt promptly and offer a user-provided downloadable URL or an upload through Velocity. Do not try third-party file hosts or substitute a visually similar public image. Never invent attachment bytes, use a sandbox path as a public URL, or substitute another image. If the host cannot transfer the attachment, explain the limitation. Do not claim to generate or transform media. Report the media type and upload/attachment outcome; show a media link only when useful or requested, never a raw storage path. To attach it, resolve the exact post with list_posts/search and get_post, and check list_connected_accounts before the write. Use attach_media according to its schema; preserve existing media unless replacement was requested. Read get_post to verify the attachment. An upload alone does not schedule or publish a post. If upload succeeds but attachment fails, explain both outcomes; do not claim the uploaded object was removed without a supported deletion operation.\n\n## User-facing results\n\nKeep post, account, brand and platform IDs, raw JSON and storage paths out of ordinary replies. Use platform and @handle, brand name, a caption excerpt, media type/count, readable status, and dates in the user's timezone. Resolve missing account labels with list_connected_accounts; do not guess. Keep exact IDs in tool calls for follow-up actions. Show technical identifiers only when explicitly requested for diagnostic or integration work. Distinguish queued/scheduled from published, and summarize errors with the next useful action. Use only verified media and published links returned by tools; never substitute an illustrative web image or invent a link from an ID.\n"
}