The four heights
The same task, four distances: today's deadline, the next reviewer, the stuck moment, the pattern.
Execute — do the immediate task
+Update the sprint board for this two-week cycle: move Emma's 'API pagination' card to In Review,…
Execute — do the immediate task
+Update the sprint board for this two-week cycle: move Emma's 'API pagination' card to In Review, mark the task as 90% complete, add a one-line blocker note that QA needs sample data from Mark, and assign the sprint owner, Lucas, to approve before Friday COB.
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 the sprint status to stakeholders, make progress obvious: surface percent complete…
Improve — make it easier to accept
+Before I send the sprint status to stakeholders, make progress obvious: surface percent complete and remaining story points at the top, highlight cards that slipped this week, and flag any tickets missing acceptance criteria or dependent on external input from Mark or Design.
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
+We merged a partial change for API pagination; QA reports they cannot validate without Mark's…
Decide — diagnose the stuck moment
+Dev just pushed a partial commit and QA can't test
We merged a partial change for API pagination; QA reports they cannot validate without Mark's sample data and the ticket lacks acceptance criteria. I am worried the demo on Friday will fail and Lucas will be blamed. I cannot tell stakeholders we delayed because Mark is on leave. What is the most likely diagnosis and the best next move to keep the sprint credible?
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 sprints we keep underestimating backend work and relying on single engineers for test data.…
Become — change the pattern
+Story points and blockers keep drifting late
Across sprints we keep underestimating backend work and relying on single engineers for test data. This burns the release owner and makes sprint reports look optimistic. What habit should we change in how we plan and document dependencies so estimates, QA readiness, and ownership stay reliable?
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 docs and databases work people do in Notion.
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.