You found a layout bug on staging. The header overlaps the search box on a 1280px viewport, and the fix belongs in a GitHub issue your team can triage. The usual path is a paid annotation add-on that syncs to your repo. You do not need one. Capture the screen, write what is wrong, and export markdown that pastes straight into a new issue with the screenshot embedded.
Here is the whole path, one action at a time.
Step 1: Capture the exact frame where the bug shows
Open a new review in a browser tab. No install, no extension, no signup. Click Capture screen, and the browser asks which window or screen to share. Pick the tab or window with the bug on it. The current frame is drawn to a canvas.
Drag a rectangle around the broken region. If the overlap is in the header, crop to the header and a little breathing room around it, not the entire 1440px page. A tight crop means the person reading the issue sees the problem without scrolling. The result is a single screenshot item you can comment on.
Step 2: Say what is wrong, in the reviewer's own words
Add a comment to the item. Type it, or dictate it with the browser's built-in speech recognition in Chrome or Edge. Speaking is faster for anything longer than a sentence, and it tends to produce the detail a developer actually needs: the viewport width, the browser, the steps to reach the screen.
If the bug is about one precise spot, drop a numbered pin on it. A pin pointing at the overlapping element removes the guesswork about which of three things in the crop you mean. For reports with several distinct problems, add one item per problem so each becomes its own line in the issue.
Keep the comment specific. "Header logo sits on top of the search input at 1280px in Chrome, expected 16px gap" is something a developer can act on. "Header looks off" is not. If you want a checklist of what to include, see the fields that make feedback fixable in one pass.
Step 3: Publish and get the markdown
Click Publish. The review is saved and gets a short public URL of the form /r/<slug>. Anyone with that link can read it, comment on any item, and the person who owns the review can mark each comment resolved. You can publish with no account at all; an anonymous review is kept for 30 days, and signing in later claims it permanently.
The same review is available as plain-text markdown at /r/<slug>/markdown. That is the format you paste into GitHub. It carries the screenshot, the comment, and the pin references in a structure a person and a machine can both read. If you want the mechanics of that export, capturing a screen to markdown walks it end to end.
Step 4: Paste it into a new GitHub issue
Open your repo, click New issue, and paste the markdown into the body. GitHub renders the heading, the comment, and the embedded image inline. The title of the issue can be the bug in one line: "Header overlaps search box at 1280px." Add a needs-triage label so it lands in the right column when your team sorts the backlog.
Because the markdown includes a public link back to the full review, anyone on the issue can open the original capture, read every item, and post a comment there if they need clarification. The issue stays clean; the discussion has somewhere to go. Details on wiring reviews to your repo live on the GitHub integration page.
When to link instead of paste
If the report has ten items, do not dump all ten into one issue. Paste the top one and drop the review link, then file separate issues from the rest. The public URL opens on any device with no app, so a teammate reviewing on a phone sees the same thing you did.
For repos where a developer or an AI coding agent will pick up the fix, the markdown export is the input that reads cleanly. It is not a video someone has to scrub through, and it is not a screenshot with no words attached. If your team runs the fix through an agent, what an agent-readable bug report contains shows how the same export feeds that workflow.
The whole loop in one tab
Capture, comment, publish, paste. No add-on subscription, no extension your IT team has to approve, no reviewer account. The output serves the issue tracker, the developer reading it, and anyone who opens the link later. If you file bugs regularly, keep a reusable QA bug report template so every issue lands with the same fields your triage needs.
Next time a bug shows up on staging, capture the frame before you switch tabs. The issue writes itself from there.