How to Record Your Screen for a Code Review
Async code reviews are clearer when you record your walkthrough instead of leaving only written comments. Here is how to record a code review with ScreenKit in five minutes.
Written code review comments are often ambiguous. “This could be cleaner” or “check the error handling here” lands differently depending on the reviewer’s tone and the reader’s context. A two-minute screen recording of you walking through the code, saying what you actually mean, removes that ambiguity entirely.
Recorded code reviews aren’t a replacement for inline comments — they work alongside them. The recording handles the big-picture feedback (“here’s how I’d approach this section differently”), and the inline comments handle the specific line-by-line notes. The result is a review that’s both faster to write and easier to act on.
Here’s how to record one.
What to include in a recorded code review
A useful code review recording typically covers:
- Your overall read of the change — what does this PR do, and does the approach make sense?
- The parts you’d change — explained in your own words, not just a comment
- The parts you specifically liked — context for what you kept vs. what you’d revise
- Questions for the author — easier to ask clearly in a recording than in a comment thread
Keep it under five minutes for most reviews. Longer recordings lose viewers and dilute the feedback.
Step 1: Open the PR in your browser
Code review recordings work best when your viewer can see exactly what you’re looking at. Pull up the PR diff in your browser — GitHub, GitLab, Bitbucket, or whatever your team uses. If you’re reviewing locally, open the diff in your IDE or terminal.
Step 2: Start ScreenKit and choose your source
Click the ScreenKit icon in your Chrome toolbar. For a PR review, choose Browser Tab as your source — this captures only the code review interface without revealing anything else on your screen. If you want to show your IDE alongside the PR, choose Application Window and select your editor.
Turn on your microphone. System audio isn’t usually needed for a code review recording.
Optionally, enable the camera bubble if a face on screen helps convey tone — sometimes a brief “this is actually a minor thing” reads more clearly with a person saying it than as a note the reader might interpret as serious feedback.
Step 3: Record the walkthrough
Hit record and walk through the PR the way you’d narrate it to the author in person:
- Scroll through the diff from top to bottom, pausing at sections you want to comment on
- Read the code aloud as you go — this keeps the recording useful for someone who isn’t looking at the screen at the same time
- Circle or highlight key sections using ScreenKit’s live annotation tools (draw arrows, add boxes) to point precisely to the line you’re talking about
- Say what you mean directly: “I’d extract this into a helper because…” is more useful than “this seems long”
Don’t worry about retakes. A stumble or a rephrase is fine — this is a review, not a polished demo. The author wants your actual thinking, not a produced video.
Step 4: Stop, annotate, and share
When you finish, stop the recording and drop into ScreenKit’s preview. You can add static annotations (shapes, text labels) to specific moments if you want to mark something you didn’t catch live.
Export the recording as a WebM file and attach it to the PR directly — GitHub, GitLab, and Linear all accept video attachments in comments. Or copy it to clipboard and paste it into a Slack message to the author.
Add a brief written note alongside the recording:
“Recorded a 3-minute walkthrough — main feedback is in 1:10–2:30. Left inline comments for the specific line changes.”
This makes the recording skimmable: reviewees can jump directly to the relevant section instead of watching from the start.
Why this is faster than writing long comments
Writing a detailed code review comment is cognitively expensive. You have to compress something visual and contextual — “this function is trying to do three things” — into precise prose that can’t be misread. A recording lets you point and talk, which is how you’d explain it in person.
Reviewees also act on recorded feedback more quickly. There’s less ambiguity about intent, less back-and-forth to clarify what a comment meant, and a lower chance that a long written comment gets skimmed instead of read.
Privacy
ScreenKit processes your recording entirely on your device. The video file never goes to a server. You control where it ends up — you attach it to the PR yourself. For code reviews that touch sensitive internal systems, that matters.
Ready to try it? Add ScreenKit to Chrome and record your next code review instead of writing it.