Give the model a clear job.

Describe the outcome.

State the user’s task and the desired result. “Let people filter the project list by category” is more useful than “make the catalog smarter.”

Include the context.

Point to the current files and data model. Describe the existing design and the interaction that must remain intact. Supply only the material relevant to the task.

Set the boundaries.

Define the scope, important constraints and things the change depends on. If a new package, service or redesign is unnecessary, say so. Keep the request small enough to inspect.

Define acceptance checks.

List observable outcomes: selecting a category filters the cards; “All” restores the list; no results produces a useful message; keyboard users can make the same selection.

Example brief

Add category filtering to the existing project catalog.
Use the current project data and visual components.
Include All, Interfaces and Creative tools.
Show a useful empty state when no items match.
Keep search and category filtering working together.
Do not change project demos or add dependencies.
Inspect the relevant files first. After implementing,
list the changed files and the flows you actually checked.

Improve the next prompt with evidence.

If the output misses the goal, describe the specific mismatch. Keep the working parts, identify the faulty behavior and ask for a focused change. Save both the successful prompt and the checks that made it useful.