The four heights
The same task, four distances: today's deadline, the next reviewer, the stuck moment, the pattern.
Execute — do the immediate task
+The marketing page needs the promo banner text updated and the close button to hide the banner.…
Execute — do the immediate task
+The marketing page needs the promo banner text updated and the close button to hide the banner. Find the banner element by id promo-banner, set its innerText to the new copy, and attach a click handler to the close button with id promo-close that sets display none on the banner. Do this and test in Chrome before pushing.
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 hand the DOM changes to QA, make the banner easier to review: put the updated text near…
Improve — make it easier to accept
+Before I hand the DOM changes to QA, make the banner easier to review: put the updated text near the top of the module, ensure the close handler also removes the aria-hidden attribute for screen readers, and flag any code that directly manipulates innerHTML instead of textContent.
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 changed the close handler to set element.style.display = 'none', but testers report the banner…
Decide — diagnose the stuck moment
+Close button doesn’t hide banner in Safari
I changed the close handler to set element.style.display = 'none', but testers report the banner still occupies space in Safari and VoiceOver still announces it. I can’t tell if the handler isn’t running or if CSS/ARIA is blocking it. What is the most likely cause and the quickest fix to both visually hide the banner and remove it from accessibility trees now?
Pasted it? When the reply comes back, push once: ask it to sharpen the weakest part. — Did this prompt help?
Become — change the pattern
+Over several sprints small DOM tweaks—innerHTML edits, style toggles, appendChild calls—keep…
Become — change the pattern
+Tiny DOM fixes keep regressing accessibility and layout
Over several sprints small DOM tweaks—innerHTML edits, style toggles, appendChild calls—keep causing layout regressions and accessibility failures. I patch one and another breaks elsewhere. Which coding habit and review practice should I adopt to stop these regressions, and what lightweight tests or lint rules would catch the usual culprits before they ship?
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 programming language work people do in JavaScript.
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.