Update to Demo Videos

{
  "description": "Share demo videos on GitHub, GitLab, or another destination. Use for a single demo or a before-and-after comparison.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 180
    },
    {
      "relative_path": "references/github.md",
      "size_in_bytes": 2520
    },
    {
      "relative_path": "references/gitlab.md",
      "size_in_bytes": 1240
    }
  ],
  "name": "share-demo-video",
  "skill_md_contents": "---\nname: share-demo-video\ndescription: Share demo videos on GitHub, GitLab, or another destination. Use for a single demo or a before-and-after comparison.\n---\n\n# Share a demo video\n\nWhen the user is working on a PR or MR, upload and include the demo video there as part\nof completing the work. For other destinations, use the one the user requested. Ask\nonly if the destination or audience is unclear. If the user requests only a draft,\nkeep it unpublished; attachments can become accessible before a comment is posted.\n\n## Choose what to show\n\nUse **Before / After** when both recordings show the same task on the original and\nchanged versions. Keep the app state, data, viewport, and pacing comparable where\npossible. Explain what happened in each video and identify the versions tested. Show\nfailures as they occurred. Do not use an unrelated older video as the baseline.\n\nFor a new feature, or when there is no baseline, show **Result**. Explain what the video\nshows and mention any important limitations. Do not add an empty Before column or imply\nthat a baseline exists. Separate operating systems or scenarios when that makes the\ncomparison easier to understand.\n\n## Format the comparison\n\nFor two related videos, use a two-column table with the players in the same row. This\napplies to Before / After, platform checks, and two workflows. Label each column for\nwhat it shows; two different workflows are not a Before / After comparison.\n\n```markdown\n### Theme switching\n\n| Before | After |\n| --- | --- |\n| Selecting Dark leaves the sidebar light. | Selecting Dark updates both panels. |\n| [Watch before](BEFORE_URL) | [Watch after](AFTER_URL) |\n| PLATFORM, VERSION_A | PLATFORM, VERSION_B |\n```\n\nUse verified upload URLs and describe what the videos show. GitHub attachment links in\nthe media row can render as players inside the cells; see the [GitHub guide](references/github.md).\nFor GitLab, use image Markdown with the returned upload URLs in that row. Check that\nboth players appear inside their cells, not below a table containing only descriptions.\nIf the destination does not render players in cells, keep labeled links or linked\npreviews in the table. Use stacked players when side-by-side viewing is unsuitable or\nthe user requests it, and explain that layout choice.\n\nFor a single video, use one heading, a sentence explaining the action and result, and one\nplayer or labeled link. Add a still preview if it helps readers or provides a fallback\nfor an unsupported player. Host preview images where the intended audience can access\nthem.\n\n## Prepare the video\n\nUse [Create Demo Video](../create-demo-video/SKILL.md) if the recording needs editing.\nCheck the final video for readability and private information. Check the preview frame,\ncaptions, audio if present, and filenames too. Keep raw footage private unless the user\nasked to share it.\n\nPrefer the plugin's VP9 `.webm` output. Keep the extension and use `video/webm` when an\nupload API needs a MIME type. Check the destination's file size limit and test browser\nplayback. A destination that accepts WebM may not play every WebM video. Do not silently\nchange codecs, rename WebM to MP4, or use another host to get around a failed upload.\n\nChoose a preview frame that shows what the viewer should notice, such as the failure in\nBefore or the result in After. If rendering with Cirro, set `edit.cover.at_ms` to that\nframe on the story timeline. Cirro places the composed frame before the video. A codec\nkeyframe does not select the host's thumbnail. Check the hosted preview. If the host\nchooses a different frame, use its thumbnail option or link a separate preview image if\navailable.\n\n## Upload and describe\n\nFor GitHub, read [Publish to GitHub](references/github.md). For GitLab, read\n[Publish to GitLab](references/gitlab.md). Use the repository's host, including its\nenterprise or self-managed host. Check installed CLI help before using a flag; versions\nand host capabilities differ. Use authenticated tools without printing tokens.\n\nUse a supported attachment flow or an existing integration. For another host, check\naudience access, link durability, and embedding support.\n\nConfirm the repository or project and audience before uploading. Use a private\ndestination for private material. Do not assume that an externally hosted attachment is\nprivate because the PR is private. Upload each final file once and reuse its durable\nURL. Keep temporary signed URLs, credentials, local paths, and expiring CI artifacts out\nof the description.\n\nFor an existing PR or MR, keep unrelated description content and follow its template. If\nthe user asks for a comment, post a comment. Add a short heading and explain the task,\nresult, and any platform or version details needed to understand the video. Say what the\nviewer should notice instead of only saying “it works.”\n\n## Check and return\n\nCheck the published page, not just the submitted Markdown. Check the players or links,\npreviews, table layout, and access for the intended audience. If inline playback does\nnot work, use a labeled link or linked preview instead of a blank player. Reuse existing\nupload URLs when fixing formatting.\n\nReturn the published destination and mention any limitations. If you cannot verify\naccess for the intended audience, say so. If publishing is blocked or the user requested\nonly a draft, return the prepared files and copy-ready Markdown. Label it as a draft.\n"
}