SideNote ProWrite better prompts for a desktop AI assistant
Most prompting advice is written for long chat sessions. Desktop assistant use is different: short requests, many times a day, usually about something already on your screen. The habits that pay off are different too.
Why desktop prompting is different
In a chat session you build context over many turns. At a desktop assistant you ask one thing, get an answer and go back to work. There is no time to negotiate, and elaborate prompt scaffolding costs more than it returns.
So the goal is not a longer prompt. It is a prompt that specifies the few things a model cannot infer from what you attached.
Three things worth specifying
1. The audience
Explain this error and explain this error to someone who has never seen this codebase produce very different answers, and the second is almost always the one you wanted. Audience is the highest-value word count in any prompt.
2. The format
Three bullets, a table with these columns, under 100 words, a numbered checklist. This shortens the answer, speeds it up, and forces the model to prioritise. Unbounded prompts produce unbounded answers.
3. The lens
What you want the model looking for. Review this specification for ambiguity that would let two developers build different things is a lens. Review this specification is not, and it will produce a summary with some compliments attached.
Audience, format, lens. Most prompts that disappoint are missing at least two of the three, and adding them takes about eight words.
What to leave out
- Roleplay preamble
- You are a world-class expert adds tokens and rarely changes anything. If you want a specific perspective, name the lens instead.
- Politeness padding
- It costs tokens and does nothing for the answer.
- Repeating what is attached
- The model has the document. Describing it again wastes context.
- Multi-part questions
- Two questions in one prompt produce an answer that half-serves both. Ask, then follow up.
- A system prompt doing work the request should do
- The system prompt sets standing behaviour, not the requirements of this specific task.
When the answer misses
The instinct is to reply no, I meant... That works, but it costs a round trip and drags the wrong answer along in the context of everything that follows.
- Ask what your question left outNearly always the answer missed because a constraint was in your head and not in the prompt.
- Edit the original message and resendLater messages in that branch are replaced after confirmation. You get a clean thread and a better answer, for one request instead of three.
- Escalate only if that failsIf a well-specified question still gets a shallow answer, that is when a more capable model or higher reasoning is the right move.
Editing rather than arguing is the highest-leverage habit of these. It is faster, cheaper, and it keeps threads short enough to stay inside the context window.
Turn good prompts into shortcuts
When you notice yourself typing the same instruction for the third time, make it a custom selected-text action. The instruction is stored, {{selection}} marks where the text goes, and it becomes an entry in the Ctrl+Shift+Q menu, and a keystroke too if you give it one.
A prompt you refine once and trigger with one key is worth far more than a clever prompt you retype from memory each time, badly.
Use the system prompt for standing preferences
The system prompt is sent with every normal request of a conversation and is edited in Settings, System prompt. It is the right place for things that are true of every answer you want, and the wrong place for anything task-specific.
Good candidates: a default brevity preference, a note that you prefer being told when something is uncertain rather than given a confident guess, the level of technical detail you want assumed, a preference for step-by-step instructions over prose, or a house style. Bad candidates: instructions about the document you happen to be working on today.
A new installation starts on You are a helpful and friendly assistant on Windows OS. The last three words earn their place. Your provider has no idea which machine it is answering for, so saying it is what keeps file paths, keyboard shortcuts and application names on the Windows side of the fence, instead of arriving as advice for another operating system that you then have to translate.
One profile per kind of work
Standing preferences are only standing within a kind of work: the instructions that make a good code review make a poor marketing draft. So the system prompt is a set of named profiles rather than one box. Create a profile, duplicate it as the starting point for the next, name them for the work rather than for the wording, and mark one Default profile so ordinary conversations pick it up without you choosing anything.
Settings › System prompt
What a profile is worth spending on: how long an answer runs, how formal it reads, how much background it assumes you have, whether it works through steps or states a conclusion, and which field's vocabulary it should be using. Those are the dials that apply to every request, which is exactly why retyping them into each one gets old.
Settings › System prompt
Choose a prompt for each conversation
The prompt picker beside the provider picker in the composer chooses the profile for the open conversation without changing your default. Its menu lists Use default and every profile, with Manage prompts… to open Settings. Choosing one sends nothing and rewrites nothing already in the conversation: it applies from the next request, and new conversations start on the default. The conversation keeps a reference to the profile, not a copy, so editing its instructions in Settings changes that conversation's next request too.
Instructions, not reference material
A system prompt says how to answer. Material to work with, such as project facts, a reply template or a list of terms, belongs in an Active Note you attach when a request needs it, rather than in a prompt sent with every request. Reusing notes as AI context shows the habit.