Three Ways to Ask, Three Kinds of Feature

Three more features, and each one is a different kind of problem, so each asks you to talk to Claude a little differently.

The easy kind, one clear ask

There is one obvious way to build a scroll-progress bar, so the prompt can be short and direct.

Add a scroll-progress bar to the page, a thin bar fixed across the top that fills from left to right as the reader scrolls down.

Reach for the single clear request any time there is only one right way to do the thing.

If Claude starts a local server to test its own work and the browser hands it a stale copy of the page, this redirect saves the detour:

Don't use Claude in Chrome for this session. Just give me the full file path URL of the HTML file. I will click open and test it myself.

The messy kind, small verified steps

This is the important one, and the opening prompt is why. It asks Claude what it thinks before telling it what to build.

Turn one, asking instead of ordering:

I want to add filtering to my projects section so visitors can filter the cards by their category, with the buttons above the grid. Before you build it though, take a look at what I actually have in there and tell me what you think. Does a filter even make sense with these projects, or am I missing something?

On the real project, Claude stopped and flagged a problem in the request itself. It laid the project cards out in a small table, pointed at the tags, and showed that every value was unique, so whichever way you sliced them, every filter button would return exactly one card. Its own comparison said it best: the filter would be like a table of contents for a one-page document.

Then it handed the decision back with options, including the honest one, that what was missing was projects rather than a filter.

A command gets you the thing you asked for. A question gets you the thing you actually needed. That small move, asking instead of ordering, is the habit worth carrying into every project.

Turn two, giving the direction:

Yes, filter by the project type, and add 2 more sample projects so a couple of the types have more than one card. Build it.

Turn three, after clicking between the filters yourself:

When I switch filters the cards just pop in and out. Add a smooth fade so they ease out and the rest settle into place.

Claude went past what was asked here, in the right way. The cards that leave fade and shrink where they sit instead of yanking the layout around, the cards that stay glide from their old position to their new one, and it still remembered the people who ask their system to reduce motion.

Moving one verified step at a time means every turn leaves you with something that works before you ask for the next thing. When something needs fixing, you know exactly which step introduced it.

The detailed kind, one loaded prompt

The kind you can get right in a single pass, because the prompt carries enough that there is nothing left to guess.

Yes, stop the server. When someone drops this link into LinkedIn or Slack, I want the preview to actually look right, so let's add proper SEO and social share tags. I need a meta description, Open Graph tags, and Twitter Card tags.

So you're not guessing at the wording, this is Maya Okonkwo's portfolio. She's a product designer who also prototypes in the browser, so lean the keywords toward product design, UX, design systems, and front-end prototyping. Keep the tone warm and human rather than corporate, and use the site's own name and tagline for the titles.

Look at how much that one prompt carries. It names the exact tags wanted. It describes who the site is for, so the descriptions come out relevant. It names the themes, so the keywords hit the target instead of coming out generic.

There is a name for working this way, context engineering, and the more context you hand over, the better the result that comes back.

Notice too that the answer about stopping the server rides along at the front, instead of costing a whole turn of its own. Small confirmations can travel with real work.

The habit worth building from this one

Stop typing short commands at Claude and start talking to it the way you would talk to an employee or a strategic partner. Say what the problem is, what you want to achieve, what the constraints are, and if you already know the shape of the answer, describe the solution you are looking for.

This one was dictated rather than typed, and the transcription came out imperfect, with the acronym mangled and a name misspelled. None of it was fixed. Claude reads through dictation typos the way a person would, and that tolerance is what makes speaking to it practical.

The whole lesson, in three lines

A simple thing needs one clear ask.

A messy thing wants small steps.

A detailed thing takes one loaded prompt.

This resource is part of

Claude Code: From Beginner to Pro Agentic AI Engineer

by Arun Nagarathanam

Take your skills to the next level with

AI GEO 2026: Get Recommended by ChatGPT, Google, Perplexity

by Arun Nagarathanam