View file changes

View file changes in Git — with the four heights of help laid out: do it now, make it easier for the next person to accept, work out the right move when you are stuck, and learn the pattern so it stops coming back.

4prompt heights
Open it in the interactive atlas →

The four heights

The same task, four distances: today's deadline, the next reviewer, the stuck moment, the pattern.

Execute — do the immediate task

+
I need to show Priya in QA what changed in the service before the build goes out. Generate a short…
I need to show Priya in QA what changed in the service before the build goes out. Generate a short email and an inline diff she can read: list only files with substantive edits, show each file’s changed functions or paragraphs with added and removed lines, and flag any TODOs or behavior changes. Include a one-line summary for the release notes that I can paste into Slack.

Improve — make it easier to accept

+
Before I hand this to the release reviewer, make the file changes easy to approve: put a…
Before I hand this to the release reviewer, make the file changes easy to approve: put a one-sentence impact summary at the top, surface any API or config surface changes first, collapse whitespace or formatting-only edits, and highlight any lines that could break backward compatibility. Show how I should annotate the diff for reviewers.

Decide — diagnose the stuck moment

+
I just ran the unit tests and one behavior failed after the edits in service/auth.py. Ben in…

I ran a quick local test and something that used to pass now fails after my edits

I just ran the unit tests and one behavior failed after the edits in service/auth.py. Ben in Staging will blame the API change. I’m not sure which of my changed functions caused it and whether it’s a test or code regression. Show the quickest diagnosis steps I should run locally, what to tell Ben in the bug report, and the one next change to try if the failure looks like a behavioral regression.

Become — change the pattern

+
Across the last six sprints I keep losing review cycles to formatting and unrelated changes buried…

I keep getting late review comments that my diffs are noisy and slow approvals

Across the last six sprints I keep losing review cycles to formatting and unrelated changes buried in my commits. Help me form three habits to stop this pattern: how to prepare my working tree before I open a review, how to structure commits so reviewers see intent, and a checklist to run before pushing. Make each habit actionable for a small team of five.

Next to this one

Other version control work people do in Git.

Every task here came from the work, not from a feature list — which is why the prompts name what you want done and never the button that does it. The tool changes; the work does not.
Copyright © LLOS.ai · 2026 — original pedagogy, voice, and design — all rights reserved.

The rest of the map

Same library, five ways in.