Home > FAQs > Better cue prompts

How do I write better cue prompts?

Q: How do I write better cue prompts?

The prompt body of a CUE.md is yours to write, and the repo ships its hard-won lessons in docs/prompt-design-learnings.md. They compress to three principles, each the opposite of what most people assume, plus some mechanics of how cue prompts are actually dispatched.

The prompt body of a CUE.md is yours to write, and the repo ships its hard-won lessons in docs/prompt-design-learnings.md. They compress to three principles, each the opposite of what most people assume, plus some mechanics of how cue prompts are actually dispatched.

1. Output tokens dominate latency, not input

The counterintuitive one first: a 320-line prompt runs at similar speed to a 60-line prompt if they produce similar output lengths. Models process input in parallel but generate output sequentially, so a long prompt with short output beats a short prompt with long output. For a cue prompt this means: don't shave instructions to make the prompt look lean; instead constrain the output. Asking for exactly three alternatives per word is a latency optimisation, not just a formatting preference.

2. Test variance, not just averages

A minimal prompt may average well and still be erratic between runs, while a slightly larger prompt with explicit guidance produces consistent results. Consistency is what an inline tool needs: a cue that's brilliant half the time and useless the other half feels broken. So when you tweak a prompt, run it several times against the same text before judging it, and prefer the variant whose worst run is acceptable over the one whose best run is impressive.

3. Explicit guidance improves consistency

Telling the model exactly what to look for constrains it to predictable output. The repo's example is the shape used by the shipped word-cue prompts: "Provide 3 alternatives per word: synonym, opposite, creative." Vague prompts ("suggest better words") produce inconsistent results; enumerated expectations don't. Name the domain, name the output count, name what a good alternative looks like.

Mechanics worth exploiting

Your prompt only sees words it claimed. Every cue must declare a match: regex or keywords: list, and each word is dispatched to exactly one source. So write the prompt for the narrow slice it will receive, not defensively for arbitrary text.
Priority is part of the design. A specific domain cue at high priority with a catch-all below it (the shipped spelling cue is match: .* at priority 10) beats one prompt trying to do both jobs.
Steal the shipped prompts. The legal, medical, and financial cues under defaults/cues/ are working examples of the pattern; copy one and adapt rather than starting blank.
Lint before you test. opencues validate catches a cue with no trigger or an empty body before you spend time wondering why nothing fires; edits hot-reload in about two seconds, so the whole loop is edit, save, type a test word, judge, repeat.

One meta-lesson ties the three principles together: prompt quality here means predictability, not eloquence. A cue fires hundreds of times a day in the background; the prompt that wins is the one whose hundredth run looks like its first.