update-screenshots

$npx mdskill add microsoft/vscode/update-screenshots

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`](../../../test/componentFixtures/blocks-ci-screenshots.md), and that file **is** committed. When those hashes change, CI fails and you must update the file.

SKILL.md

.github/skills/update-screenshotsView on GitHub ↗
---
name: update-screenshots
description: 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.
---

# 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`](../../../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`](../../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 the `vscode-large-runners-ubuntu-8-core` Linux runners. 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:

```bash
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:

```bash
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:

```bash
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:

```bash
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:

```md
#### editor/inlineChatZoneWidget/InlineChatZoneWidget/Dark
![screenshot](https://hediet-screenshots.azurewebsites.net/images/<NEW_HASH>)
```

The file is generated by [`build/lib/screenshotBlocksCi.ts`](../../../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:

```bash
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:

```bash
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.

More from microsoft/vscode

SkillDescription
accessibilityPrimary 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.
act-on-feedbackAct on user feedback attached to the current session. Use when the user submits feedback on the session's changes via the Submit Feedback button.
agent-customization**WORKFLOW SKILL** — Create, update, review, fix, or debug VS Code agent customization files (.instructions.md, .prompt.md, .agent.md, SKILL.md, copilot-instructions.md, AGENTS.md). USE FOR: saving coding preferences; troubleshooting why instructions/skills/agents are ignored or not invoked; configuring applyTo patterns; defining tool restrictions; creating custom agent modes or specialized workflows; packaging domain knowledge; fixing YAML frontmatter syntax. DO NOT USE FOR: general coding questions (use default agent); runtime debugging or error diagnosis; MCP server configuration (use MCP docs directly); VS Code extension development. INVOKES: file system tools (read/write customization files), ask-questions tool (interview user for requirements), subagents for codebase exploration. FOR SINGLE OPERATIONS: For quick YAML frontmatter fixes or creating a single file from a known pattern, edit the file directly — no skill needed.
agent-host-chat-contributionsBuild and review cross-cutting agent-host chat behavior through lifecycle contributions. Use when adding turn lifecycle side effects, prompt or context injection, restored-history transformation, protocol-action observation, or when reviewing changes that add code to AgentSideEffects or AgentService.
agent-host-e2e-testsUse when writing, recording, updating, validating, or troubleshooting Agent Host end-to-end and real-provider integration tests under src/vs/platform/agentHost/test/node/e2e and providerIntegration. Covers adding a cross-provider test, re-recording fixtures after an SDK bump, required cross-platform Azure validation, gating non-deterministic or platform-specific tests, and diagnosing replay cache misses.
agent-host-logsAnalyze Agent Host debug log exports. Use when given an ah-logs or ahp-logs zip/folder, an Export Agent Host Debug Logs bundle, events.jsonl, AHP JSONL transport logs, Agent Host.log, remote-agenthost.log, or copilot-logs.
author-contributionsIdentify 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.
auto-perf-optimizeRun agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.
azure-pipelinesUse 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.
build-champ-triageFind out why a build has failed