“Fix the menu” leaves rather a lot to interpretation. The problem might be its width, the pointer moving between panels, keyboard focus or a mobile overlay. An agent can make a plausible change to any of those and still miss what you meant.
My February 2026 theme history contains small submenu spacing changes. That sort of work is a good reminder to describe the visible fault before prescribing a broad CSS rewrite. The brief should give the assistant enough room to investigate while making the finish line clear.
Start with the user's action
On the desktop header, open the product menu and move from the top-level item into its submenu. The panel should stay open and its links should remain reachable. Reproduce the fault, find the responsible styles or event handling, and make the smallest appropriate fix. Check pointer and keyboard use, then check the mobile menu. Preserve unrelated local changes.
This is an example brief, not a claim about the exact cause of that historical menu work. It names the interaction and the expected result without telling the agent to edit a guessed selector.
Separate the outcome from your first theory
I may suspect a padding rule, but I want that treated as a lead. Ask the agent to inspect the computed styles, event handling and relevant markup before choosing a fix. If the evidence points somewhere else, the report should explain why.
For a content problem, supply the intended reading experience. For a performance problem, provide the slow route and measurement conditions. For a shared plugin, identify the sites that need the change. “Make it better” is much harder to verify than “the reader can open this panel without losing their place”.
Give permission at the right level
Say whether the job includes editing, committing, pushing and deploying. Also identify genuine boundaries, such as keeping a public URL intact or leaving an unrelated checkout alone. That avoids repeated questions about routine steps while keeping external changes within the intended scope.
There is no need to dictate every shell command. I want the assistant to choose sensible inspection and testing steps, then explain anything it could not establish. A brief that specifies every keystroke can prevent it from responding to what it finds.
Ask for evidence you can use
A useful completion report says which behaviour changed, how it was checked and which environment was checked. If the agent only ran a build, the report should say that. If it opened the menu in a browser at a narrow viewport, that is a separate piece of evidence.
When the first result is wrong, give the observed difference: “the panel stays open, but the final link is clipped at this width”. That is more actionable than asking the model to try harder. Save a fresh screenshot or a short reproduction sequence and let the next step follow from it.
The same brief works with Claude Code or Codex. The quality comes from the project context and the checkable outcome, not a long ritual of prompt phrases.