Prompt Coach

Before

Every meeting had someone saying to use AI. Almost nobody knew we already had direct access to Gemini. I ran an AI literacy camp to close that gap, and by the end a different problem had surfaced.

In one session someone told me the training was useful but she still didn't know which tool to pick or how to write a prompt that returned something worth reading. She was not confused about whether to use AI. She was stuck at the moment of typing the first line.

That is a different failure than lack of access, and more training does not fix it. The decision she was stuck on was not covered by any session because it is not a knowledge gap. Gemini's web app is three coupled choices made before you get an answer: a model tier, Flash, Thinking, or Pro, a mode, Deep Research, Search, Canvas, or plain chat, and the shape of the prompt itself. Those interact. A factual lookup sent through Deep Research burns several minutes and returns a report nobody reads. A multi-source synthesis on Flash returns something confident and thin. The prompt that works in Canvas is structured differently from the one that works in Search.

The interface presents tier and mode as a dropdown, which implies they are preferences. They are not preferences. They determine the output.

What I did instead

I stopped adding sessions and built the decision into a Gem.

Prompt Coach takes a plain request and returns three things: three rewritten versions of the prompt, a recommended model tier, and a recommended mode. The user reads them and picks.

The routing logic lives in a skills file attached to the Gem, which spells out the current Gemini model lineup and what each tier and mode is actually good for. I compiled that reference by running Perplexity's Deep Research against Gemini's published capability documentation, then reconciled it against my own usage, because published capability descriptions and observed behavior are not always the same thing.

The key design decision

Three rewrites, not one.

One rewrite makes the Gem an oracle and the user a spectator. The first time an oracle is wrong, the user stops trusting it and goes back to typing whatever came to mind, which is the state I was trying to get them out of. Three options force a comparison. The user reads them, notices why the second is more specific than the first, and chooses. The comparison is the teaching mechanism. The output is a prompt, but the thing being transferred is the judgment about what makes one good.

The routing recommendation works the same way. It is a recommendation, visible and overridable, not a silent redirect. A user who disagrees can ignore it, and disagreeing requires forming an opinion about tier and mode, which is the skill.

The second decision is that the environment knowledge sits in a replaceable file rather than in the Gem's instructions. The model lineup changes every few months. Separating the part that goes stale from the part that does not means updating it is a file swap.

Known limits

The distribution number and the usage number are far apart. It has been shared with 5,000 people and somewhere between 20 and 200 use it on a given day. That range is wide enough that I do not have a real picture of the usage pattern, and the low end suggests most people who have access have not tried it or tried it once. I do not know which, because I shipped without instrumentation.

That is the gap I would close first. I can see active users and nothing else. I cannot tell whether routing recommendations get followed or overridden, and I cannot tell whether the three rewrites spread or converge. The second question is the one that matters, because if users almost always take the first option, the other two are decoration and the design premise is wrong.

The skills file has no staleness check. It encodes a model lineup that changes, and nothing tells me it has drifted except a recommendation that looks off. A version check against the current model list would catch that.

Stack