Create a component

Create a component in JavaScript — 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 a reusable card component that shows a title, an image, and a short description for the…
I need a reusable card component that shows a title, an image, and a short description for the product list. Build it as a function that returns a DOM element, accepts data with keys title, imgSrc, and summary, and applies accessible attributes so screen readers announce the title. Make the component create elements rather than injecting innerHTML so it is safe for untrusted data.

Improve — make it easier to accept

+
Before I share this component with the team, make it easier to drop into existing pages: expose a…
Before I share this component with the team, make it easier to drop into existing pages: expose a simple API that accepts a plain object for title, imgSrc, summary and a mount target element. Add notes about which parts should be styled externally and flag any attributes or classes that will interfere with global CSS resets.

Decide — diagnose the stuck moment

+
I built a card component that returns a DOM tree for product pages, but CI intermittently fails…

The new card renders but images sometimes don't load in CI tests.

I built a card component that returns a DOM tree for product pages, but CI intermittently fails because images 404 or slow-load. The stakeholders are content editors and the QA lead. I can't tell if I should add lazy loading, placeholder SVGs, or change how I surface errors. What is the likely diagnosis and the single best change to make the component resilient in tests and previews?

Become — change the pattern

+
Across projects we keep creating near-duplicate card components with small prop differences. This…

Every page has slightly different micro-components for similar cards.

Across projects we keep creating near-duplicate card components with small prop differences. This costs review time and confuses style updates. Where do we lose time and authority, and what habit should we adopt to stop proliferating one-off components while keeping designers happy?

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.