Prompts for LLMs: Reusable Patterns for Work and Study

Good prompts for large language models share four things: a clear role or task, the context the model needs to do it, the constraints on a useful answer, and the format you expect. These principles hold across ChatGPT, Claude, Gemini, and other LLMs. Tools like fenbs keep your tested prompts and the project context they depend on in one place, so any connected assistant can read both before it starts.

The templates below are model-neutral: they work with any LLM that accepts a text prompt. Each covers a common work or study task, includes the fields to fill in, and notes what a useful response looks like.

The four parts of a prompt that holds up

Most prompts that produce weak results are missing one of four things. Understanding what each part does makes it easier to fix a prompt that is not working rather than discarding it and trying again from scratch.

• Task: what you want the model to do, expressed as an action (summarize, compare, draft, verify, list).
• Context: the background the model needs to do the task well, including relevant decisions or constraints.
• Constraints: the limits on a good answer, such as word count, format, audience, or tone.
• Output format: how you want the answer structured, so you can use it without reformatting.

Prompts for research tasks

Research prompts work best when they ask the model to separate what it found from what it inferred, and to flag any claim that needs verification from a primary source. This reduces the risk of relying on a confident-sounding answer that is actually a guess.

Research [topic] for [purpose, e.g. a report, a decision, a proposal].

Context: [relevant background and any constraints on the answer]
Audience: [who will read or use the output]

Present your findings as:
1. What is well established (with the source or basis for each point)
2. What is disputed or uncertain
3. What you are inferring rather than citing

End with three questions I should verify from a primary source before relying on this.

Prompts for explanation

Explanation prompts are most useful when you specify the audience's starting knowledge. A model that does not know who it is explaining to will pick a level that may be too basic or too technical. Asking it to flag the one concept most likely to confuse a specific audience often produces the clearest result.

Explain [concept or topic] to [audience description, e.g. a new employee, a client with no technical background].

They already know: [what they understand]
They do not yet know: [what you need to cover]
Length: [two paragraphs / a short page / a list of key points]

After the explanation:
- Identify the one concept most likely to confuse this audience
- Give an analogy that avoids [any jargon to avoid]

Do not assume they know any technical terms unless I listed them above.

Prompts for drafting

Drafting prompts produce better first drafts when they include the purpose, the audience, and the decisions already made about tone or structure. Without those, the model will make its own choices, which may be perfectly reasonable but may not match what you had in mind.

Draft [document type: email, proposal, summary, report section] for [purpose].

Audience: [who is reading this and what they need from it]
Key points to include: [list the main things it must cover]
Tone: [formal / conversational / technical / plain language]
Length: [approx. word count or number of paragraphs]
Decisions already made: [any approved direction, agreed conclusions, or fixed wording]

End with a note on anything you assumed that I should confirm before sending.

For patterns specific to a particular model, the principles in prompt engineering explain how to adjust a prompt based on the model's response style. For a broader comparison of what different LLMs are good at, see what is an LLM.

Prompts for verification

Verification prompts ask a model to review a piece of text for accuracy, logic, or consistency. They work best when you give the model the original source or the criteria it should check against. A verification prompt without a reference standard produces opinions, not checks.

Review this text for accuracy and consistency.

[paste the text]

Check it against: [the source document, the agreed criteria, or the original brief]

For each issue found:
- Quote the specific text
- Describe what is wrong or uncertain
- Suggest the correction, or note that a human needs to verify this from a primary source

Do not suggest changes that are style preferences rather than errors.

Saving tested prompts and their context

A prompt that produced a good result is worth saving. The version that worked, together with the context it needed, is more valuable than the template alone. If you reuse a research prompt for a different project, the template transfers but the project context needs to change. Keeping both together means you can reuse the prompt without accidentally bringing in the wrong context.

When a prompt fails, note what was missing and what would make it work next time. That note becomes part of the next version of the prompt, not a separate lesson you have to remember. System prompt examples shows how other prompts handle common situations that come up across different tasks.

Different project contexts call for different versions of the same template. A research prompt for legal work needs different instructions than one for product research: the sources to draw from, the constraints on what counts as a reliable claim, and the output format all differ. Rather than keeping those differences in your head and adjusting each time, write the project-specific version as a separate saved prompt with a clear name. When a session starts, the assistant reads the right version for the project at hand. Over time, a small library of well-named, context-specific prompts covers most of the work without requiring you to rebuild context from memory at the start of each session.

How to do this with fenbs

1. Create a free account and set up a project for the work these prompts support.
2. Write the context each prompt needs into the project: goals, constraints, decisions, and any standing rules.
3. Save each tested prompt in Skills and prompts with a note on when it is useful and what it needs to work.
4. Connect your LLM over MCP from Integrations so it can read the project context and the prompt library at the start of each session.
5. When a prompt stops working as the project evolves, update the saved version rather than starting over.

fenbs does not run prompts for you, compare model outputs, or host a model. It keeps the prompts and the context they depend on in one place so they remain useful as the project grows and as you switch between models.