CI Component Screenshot Baseline Investigator
Investigate component screenshot differences from CI comments and captured artifacts.
The skill identifies an external Azure screenshot service and gives a CI-artifact download path, but it does not disclose data flow, access scope, sensitive-screenshot handling, user confirmation, rollback, or safe commit boundaries. Its description says to commit baselines while the body says no manual update is needed, so permissions and behavioral boundaries are unclear and points are deducted.
The procedure is concise and includes a concrete download command, but it assumes an authenticated, available gh CLI, GitHub permissions, and a valid run ID. It provides no diagnostic or recovery guidance for missing artifacts, authorization failures, network errors, or comparison failures. The description contradicts the body about committing baselines, and no skill-specific tests are supplied; the static cap therefore applies.
The trigger and primary scenario are clear: investigate component screenshot differences reported by CI. However, inputs, outputs, non-fit cases, comparison tooling, and decision criteria are incomplete. The workflow depends on GitHub CI, GitHub CLI, and an overseas Azure service, which may reduce reachability for mainland-China users, so points are deducted.
The name and scenario are broadly aligned, the document is concise, and it explains the baseline-storage and Git LFS changes. It lacks installation notes, CLI version requirements, parameter constraints, example outputs, FAQs, limitation disclosure, version/change history, and explicit maintenance ownership. Repository context supplies MIT licensing and Microsoft provenance, but that does not fill the skill's governance gaps.
It can help a user obtain raw CI screenshots for manual investigation, but it does not accomplish the described task of updating and committing baselines. It gives no local comparison method, acceptance criteria, or remediation workflow, leaving substantial manual work and limiting marginal value.
The skill supplies an auditable command and describes the external service, while repository context indicates CI-based screenshot management. However, there is no skill-specific workflow, test suite, fixed service response, or reproducible output covering the key path, and no execution was performed during this static review, so evidence is limited.
- The metadata and body directly conflict on whether baselines should be committed; confirm whether the actual goal is artifact investigation or repository modification.
- The command depends on gh authentication, a valid run ID, GitHub artifact permissions, and Azure reachability; no failure diagnostics or mainland-China alternative are provided.
- Downloaded screenshots may contain project code or UI data, but the document gives no storage, cleanup, or sensitive-data handling guidance.
What does this skill do, and when should you use it?
This skill is for investigating visual differences reported by component screenshot tests and examining screenshots from a CI run. Screenshot baselines are no longer stored in the repository; an external service at hediet-screenshots.azurewebsites.net manages them. After a merge to the `main` branch, screenshots from the merge commit become the new baselines automatically, so manual baseline updates or commits are normally unnecessary. It fits development workflows that need to review PR comparisons, download raw screenshots, and compare them locally.
When the Checking Component Screenshots GitHub Action detects changes, it directs the user to inspect the before/after comparison in the PR comment; it uses gh run download <run-id> --name screenshots --dir .tmp/screenshots to download the CI artifact named screenshots; and it explains that the complete set of captured screenshots can be compared locally. It does not instruct users to write baselines back to test/componentFixtures/.screenshots/baseline/, and it does not use Git LFS for screenshot storage.
- A developer reviews a PR comment when the `Checking Component Screenshots` Action reports a component visual difference.
- A developer downloads the `screenshots` artifact to inspect raw captured images outside the PR comparison.
- A maintainer compares the complete CI screenshot set locally before deciding whether a component visual change is expected.
- A team maintains screenshot tests while keeping baseline images out of the Git repository and managed by an external service.
What are this skill's strengths and limitations?
- Defines a focused investigation flow based on PR before/after comparisons and CI screenshot artifacts.
- Uses an external service keyed by commit SHA instead of storing baseline images in the repository.
- Removes Git LFS from screenshot storage.
- Provides a directly executable GitHub CLI command for downloading the artifact.
- The documented scope is investigation; it does not provide a dedicated fix or local comparison command.
- It requires network access to CI resources, PR comments, and the external screenshot service.
- It requires GitHub CLI, while authentication, permissions, and retry behavior are not documented.
- The source does not state the external screenshot service's pricing, availability guarantees, or retention policy.
How do you install this skill?
The skill is located at .github/skills/update-screenshots/SKILL.md in the VS Code repository. You can clone the repository with git clone https://github.com/microsoft/vscode.git and keep the skill at .github/skills/update-screenshots/. The source does not document client-specific registration, installation, or configuration steps, and it lists no additional package-installation command.
How do you use this skill?
Run it as a subagent when the component screenshot Action reports differences, for example: Investigate the CI component screenshot differences and download the screenshot artifact for local comparison. First inspect the PR comment from CI; when raw images are needed, run gh run download <run-id> --name screenshots --dir .tmp/screenshots. Do not manually commit screenshot baselines: the source says that the merge commit becomes the new baseline after merging to main.
How does this skill compare with similar options?
Compared with the former flow described in the source, screenshots are no longer stored in test/componentFixtures/.screenshots/baseline/ or through Git LFS; an external screenshot service manages them by commit SHA instead. The skill retains CI artifact download and local investigation steps, but no longer requires a manual baseline commit.