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 the visual history right now — show the branch graph for this repo so I can see merges and…
Execute — do the immediate task
+I need the visual history right now — show the branch graph for this repo so I can see merges and where feature work diverged. Run the history with dates and short commit messages, laid out in a graph I can scan in my terminal, starting from HEAD back to three months.
Pasted it? When the reply comes back, push once: ask it to sharpen the weakest part. — Did this prompt help?
Improve — make it easier to accept
+Before I send this graph to the team, make the important branches obvious — highlight active…
Improve — make it easier to accept
+Before I send this graph to the team, make the important branches obvious — highlight active branches and recent merges, show author initials and the date next to each tip, and collapse long linear stretches so reviewers can spot branches that need cleanup.
Pasted it? When the reply comes back, push once: ask it to sharpen the weakest part. — Did this prompt help?
Decide — diagnose the stuck moment
+I just ran the history and the commit graph is a dense tangle; I need to know whether the branch…
Decide — diagnose the stuck moment
+I ran a log and got a tangle of commits I don't trust
I just ran the history and the commit graph is a dense tangle; I need to know whether the branch named feature/login is the current working branch or if HEAD moved to main after a merge. I cannot tell from this output who merged what and when and I'm worried I might base further work on the wrong tip. What is the fastest, safest way to identify the active branch tips and recent merge points so I can proceed without breaking anyone's CI?
Pasted it? When the reply comes back, push once: ask it to sharpen the weakest part. — Did this prompt help?
Become — change the pattern
+Across projects we let old topic branches pile up and the commit graph becomes unreadable; triage…
Become — change the pattern
+Every repo's graph ends up unreadable when we stop pruning
Across projects we let old topic branches pile up and the commit graph becomes unreadable; triage takes twice as long. I want a rule to keep the graph clear and make reviews faster. Which recurring habits should we adopt for branch naming, merge timing, and cleanup so active lines of work stay visible and stale branches get removed without disrupting anyone?
Pasted it? When the reply comes back, push once: ask it to sharpen the weakest part. — Did this prompt help?
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.