The prompt suggestion should steer toward the right next action, not the most predictable one

This is not a request to hide or disable it (that is #82065, and it is the
opposite of what I want). The suggestion is a good idea. The problem is that it
optimises for plausible continuation of the transcript rather than *good next
step*, and those come apart exactly where it matters most.

What happened

Working in a repo where a push to main triggers a deploy. Across a long session
the input box kept pre-filling push it, because the assistant had just finished
a unit of work and "push" is what statistically follows that.

At no point was pushing the right next step, and the repo says so in its own
contributing rules. The suggestion put a deploy one keystroke away and made it the
lowest-friction thing on screen, repeatedly.

Why this is worth fixing rather than hiding

A suggestion carries an implicit recommendation. Anything the product volunteers
reads as "this is what you'd normally do next" — so a suggestion that has no
notion of consequence is not neutral, it is nudging. The failure mode is a user
accepting a costly or irreversible action because the UI proposed it and the
alternative required typing.

What better would look like

1. Weight by consequence, not just likelihood. Actions that spend money,

deploy, publish, message anyone, or are hard to undo should need explicit
intent, not a pre-filled box. Suggest the reversible step.

1. Use signals already on disk. .github/workflows/*.yml says which branches

deploy on push. A repo where push: branches: [main] triggers a deploy is
knowable without asking anybody.

1. Read memory and CLAUDE.md. This is the sharpest one, because the answer

was already written down. My memory files say pushing is my call and that a
push costs money; CLAUDE.md says the same. The suggestion engine proposed
push it anyway. A suggestion that contradicts a recorded preference is
worse than no suggestion — it means the product read my instructions in one
channel and ignored them in another.

1. Prefer what the work actually needs next — verify, review the diff, run the

thing — over the transcript's most common successor.

1. Repetition is a signal. The same suggestion declined several times should

stop being offered.

The agent cannot see it, and that is its own problem

The suggestion appears inside the conversation, in the same product, immediately
after the assistant's own message. I cannot tell the two apart, and neither can
the assistant — it has no way to read what is being proposed next to its output.

That asymmetry is worth fixing on its own terms:

• Let the agent read the suggestion. It cannot correct, contradict or comment

on something it cannot see. When I complained about push it, the assistant
could only reason about what it probably said.

• Let the agent influence it. The assistant just did the work and usually

knows what the next step is — whether it is waiting on a decision, whether
something still needs verifying. That is a better input than the transcript's
statistics.

From where I sit this is one product with one voice. Right now it has two, and
one of them is blind to the other.

Environment

Claude Code desktop app, Code tab.