Slideshot

Slideshot

Use this skill when the task is to record a demo video of a feature or specified user flow of a web application. Slideshot lets you kick off a new recording run, refine the run goal, manage saved target-app credentials, inspect run status, fetch artifacts, or send product feedback.

> Freshness check: If more than 30 days have passed since the last-updated date in the frontmatter above, tell the user this skill may be outdated and point them to the update table below.

Keeping this skill updated

Source: github.com/slideshot/skills

| Installation | How to update | | --- | --- | | Codex plugin | codex plugin marketplace upgrade slideshot-skills, then update the installed Slideshot plugin from the Codex plugin directory | | Claude Code plugin | /plugin marketplace update slideshot-skills then /plugin update slideshot@slideshot-skills | | Cursor plugin | Update the installed Slideshot plugin from Cursor, or replace the local copy under ~/.cursor/plugins/local/slideshot and reload Cursor | | npx skills | npx skills update | | Manual | Pull the latest repo and re-upload or re-copy skills/slideshot/ into your skill directory |

Choose a runtime

Slideshot exposes the same workflow through two runtimes. Pick one at the start of the session and use it consistently — do not mix invocations between them in a single recommendation.

• MCP runtime — if slideshot.* MCP tools are available in this session (create_run, get_run, list_runs, cancel_run, submit_run_input, list_run_artifacts, fetch_brand, list_brand_guidelines, create_brand_guideline, set_default_brand_guideline, delete_brand_guideline, list_credentials, create_credential, update_credential, set_default_credential, delete_credential, submit_feedback), use them. See [references/mcp.md](references/mcp.md) for tool argument shapes, OAuth handling, and credential examples.
• CLI runtime — otherwise, invoke the public slideshot-cli npm package via npx -y slideshot-cli .... See [references/cli.md](references/cli.md) for command syntax, API-key auth, and JSON option examples.

If neither MCP tools nor a shell are available, tell the user the Slideshot connector is not connected and stop. Do not invent another execution path.

Core workflow

1. Make sure the user is authenticated into Slideshot before starting. Auth specifics differ between runtimes — see the matching runtime reference.
2. Before creating a run, confirm:

• The target URL.
• Whether the app requires login.
• The flow the user wants recorded, in enough detail to write a single coherent goal.

1. Creating a run is billable and produces a user-facing video. Wrong assumptions waste both time and money. Before calling the create-run tool / command:

• You MUST ask the user about each create-run decision below unless the user already provided it.
• Never invent values on the user's behalf. If the user has no preference for an option, omit it instead of guessing.
• Treat reusable visual styling as a brand guideline first, not one-off run options.
• List saved brand guidelines for the target URL/domain before proposing manual visual settings. If a matching guideline exists, summarize its values and ask the user to confirm before using it.
• If no suitable guideline exists, fetch brand information for the target URL when the runtime supports it (fetch_brand in MCP or brand fetch in the CLI). Use that output only to make your proposed brand-guideline choices more relevant.
• Do not treat fetched brand information as confirmed user intent. Present the relevant options and recommendations, then wait for the user to confirm before creating a saved brand guideline or using it on a run.
• Do not call create-run in the same turn as the user's initial request when any of the choices below are still unspecified. Ask first, then call after the user responds.
• For login-required runs, do not omit options.auth. Set it explicitly to default or to a specific saved credential after confirming the user's intent. Omitting auth for a login-required flow is a bug, not a default.
• For branded runs, set options.brand to default or saved after confirmation. Do not set video.background, video.size, video.cursor, intro.template, intro.style, or intro.content.logoUrl on the run when a saved brand guideline is used. A saved guideline's intro still does not appear unless the run includes options.intro.
• After creating a brand guideline, verify it exists before creating the run. Use the returned guideline id when available, or list guidelines for the target domain and confirm the expected label/default status appears. If verification fails or is ambiguous, stop instead of creating the run.

Pre-create-run confirmation gate: do not call create-run until each category has an explicit answer. If any item is unanswered, stop and ask the next focused question.

• Target URL.
• Login handling: no login, default saved credential for the target hostname, or a specific saved credential.
• Goal: one coherent flow with a clear visible end state.
• Brand guideline handling: use a matching default/saved guideline, create a new guideline, or explicitly proceed without saved brand styling. If creating a guideline, walk through every field in [Brand guideline guidance](#brand-guideline-guidance) before creating it.
• Blur visible emails during recording. This is per-run, not part of a brand guideline.
• Show keyboard shortcuts in the demo video. This is per-run, not part of a brand guideline.
• Intro card handling: skip intro, opt into a saved brand intro, create a brand guideline intro, or explicitly use a one-off unsaved intro. If the confirmed brand guideline has an intro, summarize its template/style and ask whether to opt into that intro for this run. If they decline, omit options.intro. If they accept, collect the per-run intro.content.text for text-based templates; for logo-only templates, pass intro: {} to opt in.
• Export demo.gif as well as MP4 (default false, opt-in only).

Ask the questions one category at a time where practical, and explain what each option does instead of just naming the field. When a structured question tool is available in the runtime (e.g. AskUserQuestion, request_user_input), prefer it over free-text prompts so the user can pick from concrete options. Even if a tool allows multiple questions in one call, all gate categories above must be answered before create-run.

Before calling create-run, show the exact options object you intend to send and ask for confirmation. For a saved-brand run, explicitly point out that options.brand references the saved guideline and that reusable visual fields are intentionally absent. The final create-run options must not include video.background, video.size, video.cursor, intro.template, intro.style, or intro.content.logoUrl when options.brand.source is default or saved.

Anti-pattern: immediately calling list_credentials, list_brand_guidelines, and create_run for a request without first confirming credential and brand-guideline choices. Do this instead: ask focused follow-up questions covering each still-unspecified auth, brand guideline, per-run video, intro, and artifact option. Only call create-run after the user has answered. Anti-pattern: calling create-run with inline intro.template, intro.style, video.background, video.size, or video.cursor JSON when no brand guideline exists for the target domain and the user did not explicitly decline saving one. Do this instead: ask whether to create a saved brand guideline first, then reference it from the run with options.brand. Anti-pattern: calling create-run with no options.brand, or with options.brand: { "source": "none" }, because no matching guideline exists or the user did not mention branding. Do this instead: treat brand handling as unanswered until the user chooses a saved/default guideline, creates a new guideline, or explicitly proceeds without saved brand styling. Anti-pattern: after creating or selecting a brand guideline, copying the same video.background, video.size, video.cursor, intro.template, intro.style, or intro.content.logoUrl values into the next create-run options. Do this instead: verify the saved guideline exists, then create the run with options.brand: { "source": "default" } or options.brand: { "source": "saved", "id": "" } and only pass run-specific fields such as auth, video.blur_emails, video.shortcuts, intro.content.text, and artifacts.gif.

1. Before creating the run, do brand-guideline preflight:

• List saved brand guidelines and look for one whose registered domain matches the target URL's registered domain.
• Prefer the matching default guideline when one exists. The brand source for that case is default.
• To pin a specific guideline, reference it by id with brand source saved.
• Summarize the candidate guideline before asking for confirmation: label, id, domain, default status, logo URL, video background, output size, content layout, cursor style, and intro template/style. Make clear that the intro is available but not applied unless the user opts into it for this run.
• No saved guideline found does not mean unbranded is selected. Brand handling remains unanswered until the user chooses to create a guideline, use an existing guideline, or proceed without saved brand styling.
• If no guideline exists and the user wants custom styling, create a saved brand guideline first. Use [Brand guideline guidance](#brand-guideline-guidance). Then verify it exists and reference it from the run instead of copying the reusable visual fields into create_run.
• If the user explicitly wants a one-off run without saved brand styling, use options.brand: { "source": "none" } or omit brand, then only set manual visual fields they explicitly confirmed.

1. If the demo requires login, do credential preflight before creating the run:

• List saved credentials and look for one whose domain matches the target URL hostname.
• Prefer the matching default credential when one exists. The auth source for that case is default.
• To pin a specific credential, reference it by id with auth source saved.
• For genuinely public flows, use auth source none (or omit auth entirely).
• If no suitable saved credential exists, prefer asking the user to add it securely in the web app at app.slideshot.ai instead of pasting long-lived secrets into chat. Only create credentials from chat when the user explicitly asks for it.
• Keep the run target URL hostname aligned with the credential domain. Credential matching is hostname-based.
• For login-required runs, set options.auth explicitly. Do not leave it unset and assume the runtime will pick something sensible.

1. Write one strong goal per run that describes a single coherent demo path with a clear visible end state. If the description is underspecified, ask 1–2 focused follow-up questions before creating the run.

• If the user needs multiple flows, kick off each recording run one by one. The runs enter the queue and are processed in order.

1. After creating a run:

• Tell the user the run_id returned by the runtime.
• Tell the user to monitor that specific run in the web app at https://app.slideshot.ai/?runId=.
• If multiple runs were created, give one per-run URL for each run, not a generic runs list.
• Do not poll for run status in a loop. Stop and wait for the user to ask you to inspect a run, provide input for a run, cancel it, or fetch artifacts after completion.

1. When the user later asks you to inspect a specific run, branch on its status:

• succeeded: list artifacts and surface or download the requested files.
• awaiting_input: surface the prompt to the user and continue with the same run via the runtime's input mechanism. This is the right path for OTPs and magic-link codes — never start a new run for these.
• failed or cancelled: report the error and the likely cause, then offer to retry with a better goal, corrected credentials, or different options. Change one thing at a time on retry.
• queued, running, anything in progress: report status and stop. Do not poll.

1. To stop a run that is clearly wrong, duplicate, or no longer wanted, cancel it. Only do this when the user explicitly asks or when the run is obviously off-target.
2. When a run failure looks like a Slideshot bug or product gap, offer to send feedback and include the related run id. You can also send feedback for general feature requests or product frustration even when no specific run failed.
3. Avoid redundant reruns. If a run already succeeded, fetch its artifacts instead of creating another one. If a run is awaiting input, continue it instead of replacing it. List recent runs first if you need to find an existing one before starting a fresh one.

Goal-writing guidance

A good Slideshot goal gives the runner enough detail to normalize the task into concrete success criteria without guessing.

Include:

• The exact product flow to show, in order.
• The intended starting state if it matters, especially authentication state, workspace, or seeded data.
• The visible end state that should be on screen when the demo finishes.
• Important interaction details such as opening a modal, using a keyboard shortcut, or showing a specific chart or settings panel.
• Visual or capture constraints that materially affect the output, such as blurred emails or shortcut overlays.
• Any specific wait time that matters for the demo.

Avoid:

• Vague requests like "show the app" or "make a demo of onboarding".
• Bundling unrelated journeys into one run when separate runs would be clearer.
• Omitting critical blockers such as required credentials, tenant/workspace choice, or prerequisite records the flow depends on.

If the request is underspecified, ask 1–3 focused follow-up questions about the desired flow before creating the run.

Strong examples

Sign in to https://app.example.com, open the existing "Q2 Pipeline" workspace, create a report named "Weekly Revenue", apply the last-30-days filter, and end on the analytics dashboard with the revenue chart fully visible.

Open the pricing page, scroll through the plan cards, open the enterprise contact modal, fill the work email field, and stop with the modal confirmation state visible. Blur any visible email addresses in the recording.

Weak examples

Show the product.

Go through onboarding, settings, billing, analytics, and admin.

Brand guideline guidance

A brand guideline is a reusable visual configuration for a registered domain. Treat it like saved credentials: check for an existing matching object first, summarize it, confirm with the user, then reference it from create_run by options.brand.

Anti-pattern: when no guideline exists, collecting intro template, background, text color, cursor, or video size choices and putting them straight into options.intro or options.video on the run. Do this instead: offer to save those reusable choices as a brand guideline for the target domain, then opt that run into the guideline with options.brand and only pass per-run intro content through options.intro.

Saved brand guidelines store:

• label: a human-readable name.
• domain: the registered domain; subdomains and URLs normalize to the registered domain.
• logo_url: optional absolute http:// or https:// logo URL.
• video.background: optional solid or gradient background behind the captured browser content.
• video.size: optional output dimensions and inner co

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: slideshot
• Source: slideshot/skills
• License: MIT

Install and usage instructions live in the source repository linked above.