How to Keep a Repro Command Next to Its Screenshot

A bug report is a contract between the reporter and the maintainer. The reporter says "this command, run on this system, produces this output, which is wrong". The maintainer says "I will try to reproduce it". The report has to give the maintainer enough to reproduce: the command, the environment, and the observed output. The command without the observed output is half a report — the maintainer runs the command, sees some output, and does not know whether what they see is the bug. The screenshot without the command is the other half — the maintainer sees the wrong output but does not know how to produce it. The two artifacts belong together. This guide covers the workflow for keeping a repro command next to its screenshot, so the pair can be dropped into an issue in one action.

For neighbouring topics, see monorepo paths are long: pin the ones you use, AI coding assistants and the clipboard, and best clipboard habits for developers in 2026. For screenshot handling, see how to keep the last ten screenshots handy and QA testers: staging repro data and screenshots.

What a repro pair is

A repro pair is the command and its observed output, kept as a unit. The command is text; the observed output is either text (a log, a stack trace) or an image (a screenshot of a UI bug, a chart that renders wrong). The pair is what the maintainer needs to reproduce the bug.

A text-only pair is straightforward: the command and the log go into the issue description as fenced code blocks. The maintainer copies the command, runs it, and compares the output to the log. This is the standard pattern for backend bugs.

A pair that includes a screenshot is harder. The screenshot is a binary file; it cannot be pasted inline as text. The issue's attachment system handles the binary, but the screenshot and the command need to be referenced together, so the maintainer sees them as a unit rather than as separate artifacts.

The pattern that works: a notes file (or a gist) holds the command and the screenshot path together. When the issue is filed, the screenshot is uploaded as an attachment, and the issue description references both the command (as a code block) and the screenshot (as an inline image).

The staging workflow

The workflow that produces a repro pair:

1. Reproduce the bug. Run the command in a terminal, observe the wrong output.
2. Capture the screenshot. Win+Shift+S places the snip on the clipboard. Snipping Tool can also save directly to a file.
3. Save the screenshot to a file. Open an image editor (Paint, Paint.NET, Photoshop), paste, save as PNG with a descriptive name: repro-header-overflow.png.
4. Save the command to a file. Open a text editor, paste the command, save with a matching name: repro-header-overflow.txt or repro-header-overflow.sh.
5. Optionally, save the observed output as text. If the bug produces terminal output (a stack trace, a wrong value), save that too: repro-header-overflow.log.
6. Reference both in the issue. Attach the screenshot, paste the command as a code block, paste the log as a code block.

The naming convention is what makes the pair findable later. repro-header-overflow is the bug; the three files are the artifacts of that bug. When the bug is fixed, the files can be deleted or archived together.

Using a clipboard shelf to stage the pair

A clipboard shelf (Edge-Drop or similar) is a natural fit for this workflow because it holds text and images side by side. The workflow:

1. Reproduce the bug.
2. Copy the command (Ctrl+C in the terminal). The command lands on the shelf as a text card.
3. Capture the screenshot (Win+Shift+S). The screenshot lands on the shelf as an image card.
4. Optionally, copy the log output. The log lands on the shelf as a second text card.
5. The shelf now holds the pair, with the command and the screenshot visible together.
6. When filing the issue, drag the screenshot from the shelf into the issue's attachment uploader. Click the command card on the shelf to copy, then paste into the issue's code block.

The shelf's value is that the pair is visible as a pair. The developer can see the command and the screenshot together, which makes it harder to forget one of them. The shelf also holds the pair across the time it takes to open the issue tracker and start writing the report.

For more on this pattern, see how to drag an item out of Edge-Drop into any app and how to keep the last ten screenshots handy.

The 4 MB screenshot limit

Windows clipboard history caps each item at 4 MB. A screenshot of a single window is typically 200-600 KB and fits comfortably. A screenshot of a full 4K monitor can be 2-3 MB and still fits. A screenshot of a multi-monitor setup, or a high-DPI capture with transparency, can exceed 4 MB and be silently dropped from history.

When the screenshot is too large for history, the workflow has to use the file path instead:

1. Capture with Snipping Tool's Save As, saving directly to a file.
2. Copy the file's path (Shift+right-click → Copy as path).
3. The path is on the clipboard; the screenshot itself is in the file.

Pasting the path into an issue's attachment uploader does not work — the uploader expects a file, not a path. The path is for the developer's reference, to find the file when uploading. The upload itself uses the file picker, with the path pasted into the file name field to navigate to the file.

For more on the 4 MB limit, see Windows clipboard 4 MB cap: what gets dropped and why your huge screenshot never appears in Win+V.

The Markdown issue pattern

For an issue filed in a Markdown-aware tracker (GitHub, GitLab, Azure DevOps), the pattern for the issue body:

## Repro

Run the following command:

npm run build -- --target=production

Observed output (screenshot):

![Header overflow](repro-header-overflow.png)

The header at the top of the page is wider than its container, causing the
right side to be clipped.

## Expected

The header should fit within the container at all viewport widths.

## Environment

- OS: Windows 11 23H2
- Node: 20.10.0
- Browser: Chrome 126

The screenshot is referenced by relative path (repro-header-overflow.png) if the screenshot is in the same repository, or by URL if the screenshot was uploaded to the issue tracker's attachment system.

The gist alternative

For a repro pair that will be shared outside an issue tracker — for example, in a Slack DM to a colleague — a gist is a better fit. The gist holds the command and the observed output as separate files in one gist, with one URL. The screenshot, if any, has to be uploaded separately (gists do not support image files; they are text-only).

The pattern for a text-only repro:

1. Create a gist with two files: repro.sh (the command) and output.log (the observed output).
2. Share the gist URL in the chat.
3. The colleague opens the gist, sees both files, can copy the command and run it.

For a repro that includes a screenshot, the gist holds the command and the log; the screenshot is uploaded to a separate image host (Imgur, Cloudinary, the team's screenshot tool) and linked from the gist. This is more steps than the issue-tracker pattern, but it works for chat-based sharing.

For more on gists, see gists vs clipboard for sharing throwaway code.

Pairing with environment info

The repro pair (command + screenshot) is incomplete without environment info. The maintainer needs to know the OS, the runtime versions, the browser (if applicable), and any relevant configuration. The environment info is usually a short list at the bottom of the issue:

- OS: Windows 11 23H2
- Node: 20.10.0
- App version: 1.2.3
- Feature flag: payment_retry_v2=on

A developer who files many bugs can keep a template for the environment info in a notes file or pinned in the clipboard. The template is copied into the issue and updated per bug. This saves typing and reduces the chance of omitting a relevant detail.

For more on this pattern, see QA testers: staging repro data and screenshots and meeting notes: capture now, file later.

When the repro involves a sequence

Some bugs require a sequence of commands, not a single command. The pattern: a small script that runs the sequence, with comments explaining each step. The script is the repro command; the screenshot is the observed output at the end of the sequence.

# Set up the test database
npm run db:reset

# Seed with the problematic data
npm run db:seed -- --file=test-data/header-overflow.json

# Start the dev server
npm run dev

# In a browser, navigate to http://localhost:3000/dashboard
# Observe the header overflow (see screenshot)

The script is saved as a file and attached to the issue or gist. The maintainer runs the script and reproduces the bug. The screenshot is the visual evidence that the script's output is the bug being reported.

A short checklist

• Pair the repro command with its screenshot. The two artifacts belong together.
• Use a clipboard shelf to stage the pair, with text and image visible side by side.
• For screenshots over 4 MB, save to a file and copy the path instead of using the clipboard.
• Reference both artifacts in the issue body, with the command in a code block and the screenshot as an inline image.
• Include environment info with every repro pair.
• For chat-based sharing, use a gist for the command and log; upload the screenshot separately.

Related reading

• AI Coding Assistants and the Clipboard
• When CopyQ Commands Beat Any Shelf
• Best Clipboard Habits for Developers in 2026
• Clipboard Tools on Multi-Monitor Windows Setups

Sources

• Microsoft Support — Capture a snip with Snipping Tool — official Snipping Tool documentation, including the Save As dialog used to write screenshots directly to files for repro pairing
• GitHub Docs — Attaching files to issues and pull requests — official guidance for attaching screenshots and other files to GitHub issues
• GitHub Docs — Basic writing and formatting syntax — official Markdown reference, including the fenced code block and inline image syntax used in repro issue bodies
• Microsoft Learn — Clipboard formats (Win32) — official reference for CF_UNICODETEXT and CF_DIB, the clipboard formats that carry the command and the screenshot respectively
• Microsoft Support — Using the clipboard on Windows — official statement of the 25-item history and the 4 MB per-item limit that affects large screenshots

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support