Best for
- Layout, styling, CSS
- Charts, dashboards, data visualizations
- UI components, forms, modals
github/awesome-copilot/skills/pr-screenshots/SKILL.md
Embed before/after screenshots and annotated images in pull request descriptions. Covers PR description patterns, image upload for Azure DevOps and GitHub, and sizing best practices.
Decision brief
Embed before/after screenshots in pull request descriptions so reviewers can see the visual change without checking out the branch.
Compatibility matrix
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/github/awesome-copilot --skill "skills/pr-screenshots"Inspect the Agent Skill "pr-screenshots" from https://github.com/github/awesome-copilot/blob/71f7c9b1dc5044287b62fc700efc034da4065f87/skills/pr-screenshots/SKILL.md at commit 71f7c9b1dc5044287b62fc700efc034da4065f87. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
Use this skill when a PR changes something visible:
Place screenshots directly in the PR description body. Avoid wrapping them in collapse — reviewers are more likely to look at images they can see without clicking.
For PRs with several visual changes, use separate before/after pairs with headings:
Before — 1px border clash between adjacent buttons:
Before — tooltip clipped at container edge:
Permission review
The documentation includes network, browsing, or remote request actions.
$base = "https://{org}.visualstudio.com/{projectId}/_apis/git/repositories/{repoId}"The documentation includes network, browsing, or remote request actions.
Evidence record
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 92/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 38,254 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Embed before/after screenshots in pull request descriptions so reviewers can see the visual change without checking out the branch.
Use this skill when a PR changes something visible:
Place screenshots directly in the PR description body. Avoid wrapping them in <details> collapse — reviewers are more likely to look at images they can see without clicking.
**Before** — brief description of the problem:

**After** — brief description of the fix:

Keep the text brief. A sentence or two per image describing what the reader should notice. Let the image carry most of the communication.
For PRs with several visual changes, use separate before/after pairs with headings:
## Filter bar alignment
**Before** — 1px border clash between adjacent buttons:

**After** — borders overlap cleanly, hover tint added:

## Chart tooltip
**Before** — tooltip clipped at container edge:

**After** — tooltip repositions to stay visible:

<img src="url" width="600" alt="description">
Upload images as PR attachments via the REST API:
$token = az account get-access-token `
--resource "499b84ac-1321-427f-aa17-267ca6975798" `
--query accessToken -o tsv
$base = "https://{org}.visualstudio.com/{projectId}/_apis/git/repositories/{repoId}"
$url = "$base/pullRequests/{prId}/attachments/screenshot.png?api-version=7.1-preview.1"
# Use HttpClient — Invoke-RestMethod can corrupt binary data
$client = New-Object System.Net.Http.HttpClient
$client.DefaultRequestHeaders.Authorization = `
New-Object System.Net.Http.Headers.AuthenticationHeaderValue("Bearer", $token)
$content = New-Object System.Net.Http.ByteArrayContent(
, [System.IO.File]::ReadAllBytes("screenshot.png")
)
$content.Headers.ContentType = `
[System.Net.Http.Headers.MediaTypeHeaderValue]::new("application/octet-stream")
$resp = $client.PostAsync($url, $content).Result
Reference in the PR description:

Azure DevOps gotchas:
{org}.visualstudio.com NOT dev.azure.com/{org} — AzDO's markdown renderer uses .visualstudio.com. The dev.azure.com format loads noticeably slowerPOST not PUT (PUT returns 405)7.1-preview.1screenshot-v2.png)HttpClient not Invoke-RestMethod — IRM can corrupt binary data⚠️ Work in progress. GitHub's drag-and-drop image upload uses internal endpoints that require browser cookies. There's no clean public API for uploading images to PR descriptions yet.
Current workaround: Commit images to a pr-assets orphan branch and reference via blob URLs (github.com/{owner}/{repo}/blob/pr-assets/{file}?raw=true). It works but is clunky — contributions for a better approach are welcome.
<details> tags are easy to skipimage-annotations skill to add callouts when the difference isn't immediately obviousFrequently asked questions
Embed before/after screenshots in pull request descriptions so reviewers can see the visual change without checking out the branch.
The source record exposes this install command: npx skills add https://github.com/github/awesome-copilot --skill "skills/pr-screenshots". Inspect the command and pinned source before running it.
Static rules flagged network in the source; the page lists the matching lines and excerpts.
Alternatives
dancingteeth/unified-code-review
Risk-first code review for PRs and branch audits: blast-radius triage, agent-authored discipline (tests first, intent evidence), call-graph pincer for integration defects between modules, then structural code-judo bar. Use when reviewing PRs, auditing agent-written diffs, catching rubber-stamp green CI, or wiring bugs single-file review misses. Prefer over structure-only thermo-nuclear review alone. Do not use for unrelated coding tasks or as an always-on rule.
aAAaqwq/AGI-Super-Team
Conduct context-driven code reviews focusing on quality, testability, and maintainability. Use when reviewing code, providing feedback, or establishing review practices.
magnus919/agent-skills
Use this skill to reverse-engineer an existing software system, map its architecture, data flow, privacy posture, coupling, quality characteristics, and feature surface, then produce an evidence-grounded clean-room design document, PRD, or migration plan under new constraints. Use for codebase archaeology, implicit contract extraction, architecture health assessment, or decomposition-readiness analysis. Do not use for greenfield architecture design, direct code review, bug hunting, security audi
alirezarezvani/claude-skills
Adversarial code review that breaks the self-review monoculture. Use when you want a genuinely critical review of recent changes, before merging a PR, or when you suspect Claude is being too agreeable about code quality. Forces perspective shifts through hostile reviewer personas that catch blind spots the author's mental model shares with the reviewer.