Copy-ready prompt templates for support, meetings, research, sales, marketing, and project work, with a short review system for keeping a shared library sane.
A corporate prompt should save thought, not hide it. These templates give a team a repeatable starting point, but they don't approve a customer reply, validate a forecast, or make a sensitive data transfer acceptable.
Disclosure: FlitKey makes local text-expansion software, so the storage section mentions a product we build. The prompts themselves work in ChatGPT, Claude, or another approved model.
A usable team prompt names the work, supplies the context that matters, defines the audience, and specifies the shape of the answer. The reference pattern behind this guide uses role, context, task, and format; that structure appears in the TextExpander prompt-template guide alongside its team examples.
Don't write a prompt that only the author can understand. Put changing details in clear brackets, say what the model must not invent, and add a review step for claims, numbers, tone, and confidential material.
| Prompt part | Write this | Leave out |
|---|---|---|
| Task | “Extract owners and due dates from these notes.” | “Make this better.” |
| Context | Audience, source text, product, region, or date | Background the model cannot verify |
| Format | Table, email, numbered steps, short brief, or JSON | A vague request for “a good answer” |
| Boundaries | “Mark missing facts as unknown; don't guess.” | Requests that reward confident invention |
These are templates, not a leaderboard. I selected them for repeated office workflows and wrote them so one person can adapt them without changing the whole structure.
Each prompt card includes a suggested keyword such as :support-reply or :decision-brief. In FlitKey, that keyword becomes the shortcode you type in ChatGPT, Claude, or any other text field where expansion works.
:support-reply. Keep the prefix and naming style consistent across the team.[company] and [tone] with your approved wording, or leave them visible for manual editing.{{clipboard}}. Add {{cursor}} after it when you want the insertion point left at the end.:support-reply, and use this expansion text:You are a support agent for [company].
Draft a reply to the customer message below.
State what you understand, what you need next, and what happens after that.
Use a [tone] tone. Do not claim a fix or deadline unless the notes confirm it.
Customer message:
{{clipboard}}
{{cursor}}On Windows and Linux X11, type the keyword in the AI app or press Alt + Space to search the picker. On native Linux Wayland, FlitKey uses Quick Insert and clipboard paste instead of typed keyword expansion. The placeholder reference lists the supported date, time, clipboard, and cursor tokens.
Support teams need speed, but a polished sentence can still carry the wrong diagnosis. Keep evidence, missing details, customer impact, and the next safe action separate.
:support-replyYou are a support agent for [company]. Draft a reply to the customer below.
State what you understand, what you need next, and what will happen after that.
Use a [tone] tone and keep it under [word count] words.
Do not claim a fix, refund, or deadline unless the source notes confirm it.
Customer message:
[customer message]:support-handoffTurn this support thread into an internal handoff for [team or role].
Use these headings: customer impact, observed facts, steps already tried,
missing information, and recommended next action.
Separate facts from guesses. Quote the exact error only when it appears below.
Thread:
[ticket thread]:kb-gapReview the resolved ticket below and suggest a knowledge-base article.
Return: proposed title, audience, reader question, verified steps,
known limits, and one sentence explaining why the article should exist.
Mark any step that needs confirmation by a subject-matter expert.
Ticket:
[resolved ticket]:support-escalatePrepare an escalation note for [engineering, billing, or security].
Include severity, affected users, first observed time, reproduction steps,
evidence, temporary workaround, and the decision needed from the recipient.
Do not include credentials or private customer data.
Case notes:
[case notes]Meeting notes often mix decisions, guesses, side comments, and tasks. Ask for those categories separately so an owner doesn't disappear inside a tidy paragraph.
:meeting-cleanRewrite these meeting notes for people who were not in the room.
Use four sections: decisions, actions with owners, open questions, and dates.
Keep the original meaning. If an owner or date is missing, write “not assigned”.
Do not turn a suggestion into a decision.
Notes:
[meeting notes]:agenda-buildBuild a [duration]-minute agenda for a [meeting type] with [attendees].
The decision or outcome we need is: [goal].
Give each item a time budget, owner, preparation request, and expected output.
Put the hardest decision early enough to discuss it properly.
Background:
[background]:decision-briefWrite a one-page decision brief for [audience] about [decision].
Use: context, options, recommendation, reasons, risks, cost or effort,
and the next step. Label assumptions and list information that could change
the recommendation. Do not present an unsupported preference as a fact.
Source notes:
[source notes]:weekly-updateTurn these project notes into a weekly update for [audience].
Use: completed work, current work, risks, requests, and next dates.
Keep facts and estimates separate. Name the owner for each request when known.
Keep the update below [word count] words and preserve every date.
Notes:
[project notes]ChatGPT and Claude can organize a research packet quickly; they can't turn an unverified claim into evidence. These prompts ask for source boundaries and uncertainty instead of confident filler.
:research-compareCompare [company or product A] with [company or product B] using only the
source material below. Return a table with claim, source, date, and confidence.
Separate stated facts from your inference. Mark missing or conflicting data.
Do not fill gaps with general knowledge.
Source material:
[sources]:feedback-themesAnalyze the feedback below from [audience or period].
Group repeated themes, quote short evidence, count mentions when possible,
and separate requests from complaints. Note sampling limits and any theme
that appears only once. End with four questions for the next research round.
Feedback:
[feedback]:report-briefSummarize this report for [audience] in [word count] words.
Start with the main finding, then cover method, evidence, limits, and what
the reader should do next. Keep every number tied to its source or label it
as an estimate. Do not copy a conclusion that the report does not support.
Report:
[report text]:data-questionsReview the data summary below for [business question].
Return: what the data supports, what it cannot answer, possible confounders,
data quality checks, and the next analysis worth running.
Do not calculate a result from missing fields. Ask for the exact column or
time period when the question cannot be answered.
Data summary:
[data summary]Sales and marketing drafts move fast, which is why unsupported claims survive review. Put the source text, audience, channel, and forbidden claims in the prompt.
:prospect-emailWrite a short email to [role] at a [industry] company about [topic].
Use a direct, professional tone. Mention only the proof points below.
Make one specific request and keep the body under [word count] words.
Do not invent a result, customer, integration, or deadline.
Proof points:
[approved proof points]:sales-objectionDraft a response to this prospect objection: [objection].
First acknowledge the concern in plain language. Then answer using only the
approved facts below. If the facts do not answer it, say what a salesperson
needs to confirm. Keep the response under [word count] words.
Approved facts:
[approved facts]:channel-copyAdapt the approved copy below for [channel] and [audience].
Keep the factual claims, numbers, product name, and required disclaimer.
Return the draft, then list any line that needs legal or subject-matter review.
Do not add a claim just to make the opening stronger.
Approved copy:
[copy]:interview-guideWrite an interview guide for [audience] about [topic].
Give an opening script, consent reminder, warm-up question, core questions,
follow-ups, and a closing prompt. Avoid leading questions and do not ask for
private information that the study does not need. Target length: [duration].
Research goal:
[goal]Project prompts are most useful when they expose the decision, owner, risk, or missing input. They should make uncertainty easier to see, not polish it away.
:risk-reviewReview the project notes below for [project].
Return a risk register with risk, evidence, likelihood, impact, owner,
mitigation, trigger, and next review date. Separate known risks from guesses.
If a field is missing, write “not provided” instead of filling it in.
Project notes:
[notes]:plan-actionsBreak this plan into work items for [team].
For each item, give outcome, owner, dependency, acceptance check, and target date.
Keep the sequence from the source plan. Flag work that needs a decision before
someone starts it. Do not create dates that the plan does not contain.
Plan:
[plan]:stakeholder-briefWrite a stakeholder brief about [initiative] for [audience].
Cover current state, desired outcome, progress, decisions needed, risks,
and what changes for this audience. Use the source notes only; label open
questions clearly. Keep the tone calm and the brief under [word count] words.
Source notes:
[notes]:project-reviewTurn the project record below into a post-project review.
Use: intended outcome, observed outcome, decisions that helped, decisions that
hurt, process changes to try, and questions for the team. Avoid assigning blame.
Separate evidence from interpretation and end with two owners for follow-up.
Project record:
[record]Templates work when people can find the current version and understand what changed. The reference article makes the same practical distinction: storing a prompt and deploying it are separate jobs.
For a small team, a reviewed JSON file or shared document may be enough. FlitKey can keep a local copy one shortcut away on Windows and Linux; it stores snippets on the device, but it does not provide shared permissions, automatic updates, or a central approval queue. A hosted tool such as TextExpander fits better when those team controls are the requirement.
| Library field | Why it exists | Example |
|---|---|---|
| Prompt name and owner | Someone knows what the template does and who can change it. | Support handoff • Support Operations |
| Approved use | People know which workflow and audience the prompt covers. | Internal ticket triage only |
| Data boundary | People know what may be pasted into the model. | Public and internal, no customer identifiers |
| Version and review date | Old wording does not quietly become the team standard. | v2 • Review September 2026 |
| Known failure | Users see where the prompt needs human checking. | Does not verify product availability or policy |
Run a new prompt with harmless sample material several times before sharing it as a team standard. Record the cases where it guessed, dropped a constraint, or produced a format people couldn't use. Then change the prompt or narrow its approved use.
Saving a prompt locally doesn't make the request to ChatGPT or Claude local. OpenAI documents that model output can change between snapshots and recommends pinned versions and evaluations for consistent API behavior; Anthropic's documentation describes Claude's use for text, code, analysis, and image inputs. For corporate work, the service policy and your organization's approval matter more than the brand name.
Before sending a prompt, remove passwords, private keys, access tokens, regulated records, personal data, confidential customer text, and restricted source code unless the exact workflow has approval. The FlitKey privacy and security guide covers clipboard copies, local files, backups, and the boundary between offline snippet storage and an external AI request.
It names the task, supplies relevant context, defines the audience, sets an output format, and tells the model what not to assume. A strong prompt also makes the human review step obvious.
Yes. They use plain instructions and bracketed placeholders, so you can adapt them for ChatGPT, Claude, or another approved model. Outputs still differ by model, settings, context window, and the material you provide.
A shared library helps when people repeat the same work, but every prompt needs an owner, a review date, an approved data boundary, and a record of changes. A shared folder alone doesn't provide those controls.
Yes. FlitKey can turn a short trigger into a saved local prompt on Windows and Linux. It does not provide shared permissions, cloud sync, or a hosted team prompt console.
Don't paste credentials, private keys, regulated records, personal data, confidential customer material, or restricted source code unless your organization has approved that exact workflow and service.
Reference and product documentation were checked August 14, 2026. The prompt text above is original copy for FlitKey's editorial guide; the sources support the prompt structure, model context, and workflow limits.