update-screenshots
Update the committed blocks-ci screenshot hashes after the "Screenshots & Tests" check fails, or investigate a screenshot diff reported on a PR. Use when asked to update, accept, or refresh component screenshot baselines from CI. This skill should be run as a subagent.
- Installs
- 3K
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/microsoft/vscode --skill update-screenshots- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads update-screenshots automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Update Component Screenshots from CI
Screenshot images are not stored in the repository — they live in an external service (hediet-screenshots.azurewebsites.net), keyed by commit SHA. But a subset of fixtures is pinned by hash in test/componentFixtures/blocks-ci-screenshots.md, and that file is committed. When those hashes change, CI fails and you must update the file.
Two different outcomes, only one of which blocks
The Screenshots & Tests job in .github/workflows/component-fixtures.yml produces two independent results:
| Result | Blocking? | Action |
|---|---|---|
| Screenshot diff report (PR comment with before/after images) | No — informational | Review the visuals. Nothing to commit. |
| blocks-ci hash mismatch | Yes — fails the check | Update blocks-ci-screenshots.md and commit. |
A fixture opts into the blocking gate with labels: { kind: 'screenshot', blocksCi: true }. Only those fixtures appear in blocks-ci-screenshots.md.
The failure looks like this:
##[error]blocks-ci screenshot hashes do not match committed file. See PR comment or job summary for the updated content.
Step 1: Get the expected hashes from CI
Never regenerate the hashes locally. They are hashes of the rendered PNG bytes, produced on
ubuntu-latest. Rendering on macOS or Windows yields different bytes and therefore different hashes, so locally generated values will fail CI. Always copy the values from the CI job.
Three surfaces carry the same content — use whichever is handy:
- The PR comment titled "blocks-ci screenshots changed" (non-fork PRs only) — contains the full updated file plus a patch.
- The job summary, which gets the identical body and is the only surface fork PRs receive.
- The job log, whose final step prints a unified diff:
gh api repos/microsoft/vscode/actions/jobs/<JOB_ID>/logs > "$TMPDIR/ci-job-log.txt"
grep -n '##\[error\]' "$TMPDIR/ci-job-log.txt"
Find the failed job id with:
gh pr checks <PR> --json name,link,bucket --jq '.[] | select(.name == "Screenshots & Tests")'
Step 2: Verify the change is intentional before accepting it
This gate exists to catch unintended layout regressions, so accepting new hashes without looking at the images defeats its purpose. The images are publicly fetchable by hash, so pull both the old (committed) and new (from CI) versions and compare:
curl -sL -o old.png "https://hediet-screenshots.azurewebsites.net/images/<OLD_HASH>"
curl -sL -o new.png "https://hediet-screenshots.azurewebsites.net/images/<NEW_HASH>"
Then view them, and localize the change rather than eyeballing full screenshots — the delta is often only a pixel or two:
python3 -c "
from PIL import Image, ImageChops
a = Image.open('old.png').convert('RGB'); b = Image.open('new.png').convert('RGB')
print('diff bbox:', ImageChops.difference(a, b).getbbox())
"
Confirm the delta matches what the PR intends. If the fixture is unrelated to the change, or the shift is larger than expected, treat it as a regression and fix the code instead of the hashes.
Step 3: Apply and commit
Edit only the changed lines in test/componentFixtures/blocks-ci-screenshots.md, replacing the old hash in the image URL with the new one:
#### editor/inlineChatZoneWidget/InlineChatZoneWidget/Dark
The file is generated by build/lib/screenshotBlocksCi.ts and compared byte-for-byte, so keep the <!-- auto-generated by CI — do not edit manually --> header, the #### <fixtureId> / image-link pairing, the blank line between entries, and the fixtureId sort order intact. Verify your edit is the exact inverse of the diff CI reported:
git diff test/componentFixtures/blocks-ci-screenshots.md
Then commit and push. The check re-runs and should pass; hashes on main become the new baseline after merge.
Investigating further
Raw captured images and the manifest for a run are uploaded as an artifact:
gh run download <RUN_ID> --name screenshots --dir .tmp/screenshots
manifest.json maps each fixtureId to its imageHash and any render errors.
Related failures from the same job
The check also fails if a fixture failed to render (Fail if fixtures had errors) or if the Playwright fixture tests failed. Those are genuine bugs — updating hashes will not help. Look for ::error::<fixtureId>: in the log, and download the playwright-test-results artifact for test failures.
FAQ
What does the update-screenshots skill do?
Update the committed blocks-ci screenshot hashes after the "Screenshots & Tests" check fails, or investigate a screenshot diff reported on a PR. Use when asked to update, accept, or refresh component screenshot baselines from CI. This skill should be run as a subagent.
How do I install update-screenshots?
Run npx skills add https://github.com/microsoft/vscode --skill update-screenshots in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/update-screenshots/ (personal) or .claude/skills/update-screenshots/ (project).
Which AI agents can use update-screenshots?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is update-screenshots safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains update-screenshots?
It is published by microsoft in microsoft/vscode, and it is an official skill from the maker of the technology it covers. It has 3,001 recorded installs.
More from microsoft/vscode
memory-leak-audit
microsoft/vscode
Audit code for memory leaks and disposable issues. Use when reviewing event listeners, DOM handlers, lifecycle callbacks, or fixing leak reports. Covers addDisposableListener, Event.once, MutableDisposable, DisposableStore, and onWillDispose patterns.
azure-pipelines
microsoft/vscode
Use when validating Azure DevOps pipeline changes for the VS Code build. Covers queueing builds, checking build status, viewing logs, and iterating on pipeline YAML changes without waiting for full CI runs.
accessibility
microsoft/vscode
Primary accessibility skill for VS Code. REQUIRED for new feature and contribution work, and also applies to updates of existing UI. Covers accessibility help dialogs, accessible views, verbosity settings, signals, ARIA announcements, keyboard navigation, and ARIA labels/roles.
sessions
microsoft/vscode
Core principles and workflow router for changes to the Agents Window under src/vs/sessions.
author-contributions
microsoft/vscode
Identify all files a specific author contributed to on a branch vs its upstream, tracing code through renames. Use when asked who edited what, what code an author contributed, or to audit authorship before a merge. This skill should be run as a subagent — it performs many git operations and returns a concise table.
fix-errors
microsoft/vscode
Guidelines for fixing unhandled errors from the VS Code error telemetry dashboard. Use when investigating error-telemetry issues with stack traces, error messages, and hit/user counts. Covers tracing data flow through call stacks, identifying producers of invalid data vs. consumers that crash, enriching error messages for telemetry diagnosis, and avoiding common anti-patterns like silently swallowing errors.
Popular devops & cloud skills
microsoft-foundry
microsoft/azure-skills
Build, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and resources end to end. USE FOR: foundry, azd ai agent, azd provision/deploy, hosted agent scaffold/develop/run/deploy/troubleshoot, prompt agent create, managed harness agent create, GitHub Copilot harness agent, create agent, update agent, add tool to agent, invoke agent, agent insights, evaluate agent, batch eval, continuous eval, continuous monitoring, agent CI/CD, optimize prompt, improve prompt, optimize agent instructions, Agent Optimizer scaffold, dataset curation from traces, deploy model, model fine-tuning (SFT/DPO/RFT), Foundry project, RBAC, role assignment, permissions, quota, capacity, region, deployment failure, AI Services, create Foundry resource, knowledge index, customize deployment, onboard, availability, training-data, grader, distillation, large file upload. DO NOT USE FOR: Azure Functions, App Service, general Azure deploy (use azure-deploy), general Azure prep (use azure
azure-diagnostics
microsoft/azure-skills
Debug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deployment failure, troubleshoot container apps, container app 503 or target port mismatch, troubleshoot functions, function telemetry missing or stopped after a config/connection-string change, troubleshoot AKS, VM RDP, Linux SSH, VM black screen, can't connect to VM, reset VM password, NSG or firewall blocking, kubectl cannot connect, kube-system/CoreDNS failures, pod pending, crashloop, node not ready, upgrade failures, analyze logs, KQL, insights, image pull failures, cold start issues, health probe failures, resource health, root cause of errors, troubleshoot event hubs, troubleshoot service bus, messaging SDK error, AMQP connection failure, message lock lost, lock renewal during long-running processing, service bus dead letter.
azure-prepare
microsoft/azure-skills
Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azd infrastructure, modernize app for Azure with azd, deploy with azd, function app, timer trigger, service bus trigger, event-driven function, managed identity, generate Bicep, generate Terraform, create and deploy to Azure.
azure-ai
microsoft/azure-skills
Use for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybrid search, speech-to-text, text-to-speech, transcription, OCR. WHEN: AI Search, query search, vector search, hybrid search, semantic search, speech-to-text, text-to-speech, transcribe, OCR, convert text to speech.
azure-deploy
microsoft/azure-skills
Execute Azure deployments for ALREADY-PREPARED applications that have existing .azure/deployment-plan.md and infrastructure files. DO NOT use this skill when the user asks to CREATE a new application — use azure-prepare instead. This skill runs azd up, azd deploy, terraform apply, and az deployment commands with built-in error recovery. Requires .azure/deployment-plan.md from azure-prepare and validated status from azure-validate. WHEN: "run azd up", "run azd deploy", "execute deployment", "push to production", "push to cloud", "go live", "ship it", "bicep deploy", "terraform apply", "publish to Azure", "launch on Azure". DO NOT USE WHEN: "create and deploy", "build and deploy", "create a new app", "set up infrastructure", "create and deploy to Azure using Terraform" — use azure-prepare for these.
azure-validate
microsoft/azure-skills
Pre-deployment validation for Azure readiness. Run deep checks on configuration, infrastructure (Bicep or Terraform), RBAC role assignments, managed identity permissions, and prerequisites before deploying. WHEN: validate my app, check deployment readiness, run preflight checks, verify configuration, check if ready to deploy, validate azure.yaml, validate Bicep, test before deploying, troubleshoot deployment errors, validate Azure Functions, validate function app, validate serverless deployment, verify RBAC roles, check role assignments, review managed identity permissions, what-if analysis, validate Container Apps deployment.