Professional Prompting

A prompt is a work brief

Prompt engineering is the design of instructions that help a language model produce useful, reliable, structured results. The phrase has collected folklore: secret phrases, “act as a genius,” ever longer incantations. In professional work the better analogy is a brief to a capable colleague who has not sat in your meetings, has not read your files unless you attach them, and will still try to finish the assignment. A weak brief produces a weak draft. A strong brief does not guarantee a correct draft, but it determines whether the draft is even in the right job.

People who write well for humans already have most of the skill. They specify audience, purpose, sources, limits and the shape of the deliverable. They say what not to do. They name the decision the document is supposed to support. Prompting is that discipline applied to a system that will invent whatever you leave unspecified. The previous chapter showed why invention is dangerous. This chapter is the operational response: make the brief complete enough that invention has less room, and make the remaining uncertainty visible enough that a reviewer can catch it.

You do not need a library of tricks to start. You need a framework you can run on every material task, a small set of techniques for different jobs, an iterative loop that treats the first answer as a draft, and a personal library of prompts that have earned their place on real work. Prompting is not a substitute for verification. It is how you reduce the amount of verification you will otherwise waste on answers that were never on brief.

The RTCCOQ framework

RTCCOQ is a six-part brief: Role, Task, Context, Constraints, Output, Quality. Role says who the model should act as. Task says what exactly it must do. Context is the information it is allowed to use. Constraints are the rules and limits. Output is what the result should look like. Quality is how the result should be checked, including what to do when information is missing. Weak prompts usually specify a vague task and nothing else. Strong prompts cover all six, even if some parts are short.

Use the radar as a diagnostic. After you write a prompt, walk the six axes. If Role is empty, the model picks a generic assistant voice. If Context is empty, it borrows from average professional prose. If Constraints are empty, it invents missing facts to appear complete. If Output is empty, you reshape a wall of text. If Quality is empty, you have not told it how to fail safely. Task is the axis people remember. The other five are where professional prompting actually lives.

Weak and strong, side by side

The weak prompt is familiar because it is how people talk to search boxes. “Write a report about our project.” That sentence names a genre and nothing else. The model must invent the audience, the length, the contents, the facts and the standard of evidence. It will oblige. You will receive a two-page document that could belong to any programme in any company. It will contain milestones that sound right, risks that are generic, and a budget comment that cannot be traced. You will then spend longer editing it than you would have spent writing a real update from your notes.

The strong version is a brief a senior project manager could execute.

Act as a senior project manager. From the attached notes, write a
two-page executive update for senior management. Cover progress,
milestones, delays, budget risks, dependencies and next actions.
Do not invent missing information; label any assumptions. Use a
professional tone and end with the three decisions you need from
management.

Walk RTCCOQ through that paragraph. Role: senior project manager. Task: write an executive update. Context: the attached notes. Constraints: do not invent; label assumptions; professional tone; two pages. Output: coverage of six topics and a closing set of three decisions. Quality: missing information must be labelled rather than filled. The prompt is still short. Completeness does not require length. It requires that each axis has an answer.

Notice what the strong prompt does not do. It does not ask the model to be brilliant. It does not pile on adjectives. It does not request a confidence percentage. It attaches the work and describes the artefact the organisation actually needs. If the notes are thin, the output should be thin in the corresponding places, with assumptions listed. That is a successful use of the model. A thick report from thin notes is a failure, however well written.

Role

Role is not theatre. You are not trying to flatter the model. You are selecting a professional stance: altitude, vocabulary, what counts as a good answer, and what the speaker is responsible for. “Act as a senior project manager” tells the model to write for executives, to care about decisions, dependencies and risk, and not to produce a technical diary. “Act as a staff engineer reviewing a design” tells it to look for failure modes, interfaces and test gaps. “Act as a general counsel’s office commenting on a draft letter” tells it to hunt for commitments, admissions and undefined terms.

Choose roles you could defend to a colleague. Vague prestige roles (“world-class expert,” “top 1 per cent”) add heat and no specification. A role that names a function and a seniority is enough. If the work crosses functions, say so: “Act as a commercial lead, then add a short risk note as if from legal.” Sequential roles are often clearer than a single hybrid persona. Combined with constraints, role keeps the model inside a job description. Combined with nothing else, role is costume.

Task

Task must be a verb with an object: summarise this thread into five decisions; extract every date and owner from these notes; draft a reply that declines the request and offers a call; critique this memo against the attached checklist; propose three options with trade-offs. “Help me with this” is not a task. “Think about our strategy” is not a task. The model will still produce text. You will not be able to say whether it did the job.

If the job has several verbs, say whether they are sequential or alternative. “First list the open questions. Then draft answers only where the notes support them.” If you bury three jobs in one paragraph, the model will blend them. Blend is the enemy of review. One inspectable artefact per prompt is the default. Be precise about the decision the task serves. “Write an update” and “write an update that ends with three decisions we need from management” are different jobs. The second produces a document a meeting can use.

Context

Context is the information the model is allowed to use: pasted notes, a policy extract, a table, a prior email, a definition of the metric, the date, the entity, the audience’s known objections. The previous chapter’s rule still holds. If the fact is not in the context, the model should not present it as fact. Paste what you have. Say what you do not have. That pair is more valuable than any role sentence.

Context also includes negative space. “These notes are from the 12 March steering group. They do not include finance’s view. Do not infer a budget position.” Without that sentence, a complete-looking budget paragraph will appear. You then have to remember it was invented. Better that it never appears.

Long context is not free. Models can drop constraints that appeared early, mix two similar names, or attend to the latest message at the expense of the brief. Prefer the relevant extract over the entire data room. If you must supply a long document, restate the constraints at the end of the prompt. Put the question next to the passage that should answer it. Treat context as a designed pack, not as a dump.

Constraints

Constraints are the rules: do not invent; do not give legal advice; UK English; no more than two pages; do not mention the unannounced product; stay inside the attached policy; do not recommend a vendor; assume the reader already knows the programme name. Constraints are where you spend the time you used to spend on cleanup. Every constraint you omit becomes an edit later, or a risk if you fail to edit.

The most important constraint in professional work is the ban on invention. State it every time the output could be mistaken for a sourced document. Pair it with an alternative: “If information is missing, write ‘Unknown — not in the notes’ and continue.” A ban without an alternative often fails, because the model is trained to be helpful and complete. Give it a permitted way to be incomplete.

Constraints can be formal. A word limit, a heading list, a prohibition on bullet-only dumps when you need prose, a requirement to quote rather than paraphrase a clause. They can also name organisational scars: who must not be surprised, which options are already closed, which tone would damage a relationship. The model does not know those. You have to write them down.

Output

Specify the artefact. Two pages, six headings, a table with four columns, an email under 150 words, JSON with named fields, a slide outline with one claim per slide, a numbered list of decisions. If you do not specify shape, you get a shape that is easy for the model to emit and expensive for you to use. Matching the downstream template is not fussy. It is how prompting saves time rather than moving typing from one window to another.

Structured output deserves a special mention. When the task is extraction, comparison or routing, ask for a table or a fixed schema. Free prose hides missing fields. A table with an empty cell makes the gap obvious. If you need both a human-readable memo and a machine-readable list, ask for both, in that order, with a clear separator. Do not hope that you will later parse a narrative.

Output specification is also where you prevent decorative extras. “No cover letter. No apology. Start at the heading.” Those lines keep the artefact insertable.

Quality

Quality instructions tell the model how to inspect its own draft before it shows you, and what good looks like in your setting. “After the draft, list assumptions and residual uncertainties.” “Check that every figure points to a row in the attached table.” “Score the email against: clear ask, tone, length, no new facts.” “If you cannot support a heading from the notes, omit the heading.” These are not substitutes for your verification. They are a way to get a draft that is cheaper to verify.

Asking for uncertainty is part of quality, not a separate personality setting. The model will not spontaneously emphasise what it does not know unless you require a place for that content. Create the place: a heading, a column, a final list. Define the language: “Unknown,” “Not in the supplied material,” “Assumption.” If you ask only for a confident memo, you will receive one.

Quality can include a critique pass in the same prompt or in the next one. “Now attack this draft as a sceptical CFO. What is missing, overstated or unfunded?” Separation of author and critic is a human management practice. It works here for the same reason.

Techniques that earn their place

Frameworks tell you what to include. Techniques tell you how to include it for a given job. Each item below is a method you can explain to a colleague. If you cannot explain why you are using it, you are collecting folklore.

Zero-shot

Zero-shot is a complete RTCCOQ brief with no examples. It is the default and it should remain the default. Most professional tasks are describable in sentences. Start here. Move to few-shot only when the model keeps missing a style or an edge case that you can show faster than you can describe.

Few-shot

Few-shot prompting supplies a handful of input-output pairs. The model matches the pattern. This is the right tool when your organisation has a house way of writing that is tedious to encode as rules: how you decline a meeting, how you label a risk, how you write a finding in an audit memo, how you mark an assumption. Two or three examples outperform a long style guide that the model only half obeys. Poor examples outperform no examples in the wrong direction, so choose them as carefully as you would choose training material for a person.

When few-shot beats role

Role is cheap and often sufficient for tone. Few-shot beats role when the difficulty is format or discrimination, not altitude. If you need the model to classify tickets into a taxonomy with ugly edge cases, showing labelled examples will beat “act as a senior support lead.” If you need a one-page weekly that always puts blockers above narrative, showing last week’s good page will beat “act as a programme director.” Role without examples still leaves the model to invent your house style. Use both when the work is high volume and high visibility. Use examples alone when the role sentence has become empty ritual.

Decomposition

Decomposition is how you keep review possible. “Analyse this pack” is one blob. “List facts the pack actually states. List interpretations. List questions the pack does not answer. Then draft a one-page note that keeps those three categories separate.” That sequence is slower in the chat and faster in the real work, because you can challenge a category without throwing away the rest. Whenever a prompt produces a mix of evidence and recommendation, split the job.

Critique and iteration

The working loop is Prompt, Output, Review, Improve, Critique, Final output. The first answer need not be final. In professional settings it should not be. You read the draft against the brief and against the source. You send a short improvement. Then you ask for a critique from a different stance. Then you accept, rewrite by hand, or run one more pass. Stopping at the first fluent page is how invented citations and generic strategy survive. If two improvement passes have not fixed the problem, the brief is wrong, the context is missing, or the task is not a generation task. Repeating “try again” is not a quality system.

How to ask for uncertainty

Professionals need the model to distinguish what is in the file, what is inferred, and what is unknown. The way to get that distinction is to require it in the output contract. Do not ask “are you sure?” Do not ask for a percentage. Ask for labelled buckets and for behaviour when a bucket is empty.

Split your answer into three sections:

SUPPORTED — claims that quote or paraphrase the attached notes.
Give a short pointer (heading or bullet number) for each claim.

INFERRED — conclusions that do not appear in the notes but follow
if the notes are true. State the inference in one sentence.

UNKNOWN — questions a decision-maker would still need answered.
If a section would be empty, write “None” and do not fill it.

Do not move an item from UNKNOWN into SUPPORTED to make the
briefing look complete.

You can require a similar split for numbers: reported figure, calculated figure with the formula shown, unavailable figure. You can require it for legal or policy reading: quoted rule, application to facts, gap in the rule. The pattern is the same. Uncertainty becomes a first-class output, not a mood. That is the quality axis of RTCCOQ made concrete.

Five professional templates

Save these, then adapt the context. They are not magic words. They are RTCCOQ filled in for common jobs. Replace bracketed text. Attach the real material. Run the verification checks from Chapter 3 before anything leaves your desk.

1. Email that needs a decision

Role: You are my chief of staff. You write short emails for a
director who values plain language and a clear ask.

Task: Draft a reply to the message below.

Context:
- Audience: [name, role]
- Relationship: [internal / client / supplier]
- Goal of the email: [the decision or action I need]
- Facts I am willing to state: [paste only cleared facts]
- Facts I am not willing to state: [list]

Constraints:
- Do not invent availability, prices, legal positions or apologies
  I did not authorise.
- British spelling. No exclamation marks. No “I hope this finds you well.”
- 120 words or fewer unless I supplied a reason to go longer.

Output:
- Subject line
- Email body
- A second version that is 80 words

Quality:
- End with one explicit ask and a date if I provided one.
- List any fact you needed and did not have, instead of guessing.

2. Analysis note from a pack

Role: You are a manager in strategy, writing for the executive
committee. You separate evidence from judgement.

Task: Produce a one-page analysis of the attached pack.

Context: [paste notes, table extracts, the question the committee asked]
Time period: [dates]
Entity: [name]
Decision the page must support: [go / no-go / resource / sequencing]

Constraints:
- Answer only from the attached material.
- Do not invent comparators, market sizes or “typical” margins.
- Do not recommend a course of action until the Options heading.

Output headings:
1. What the pack actually shows
2. What it does not show
3. Options (at most three) with the trade-off in one sentence each
4. Recommendation, labelled as judgement
5. Decisions needed from the committee

Quality:
- Every number must point to a row, cell or sentence in the pack.
- If you cannot point, omit the number.
- Close with assumptions and unknowns as a bullet list.

3. Critique of a draft

Role: You are a sceptical reviewer at the same seniority as the
author, not a teacher and not a cheerleader.

Task: Critique the draft below against the brief and the source
material. Do not rewrite it until I ask.

Context:
- Original brief: [paste]
- Source material the draft was allowed to use: [paste or attach]
- Draft: [paste]

Constraints:
- Do not introduce new facts.
- Do not soften a problem to be polite.
- If the draft is fine on a criterion, say so in one line. Do not pad.

Output:
A table with columns: Criterion | Finding | Severity (High/Med/Low) | Fix
Criteria to use:
- Faithfulness to sources
- Missing decisions or asks
- Audience and tone
- Structure
- Unsupported claims
- Confidentiality or over-sharing

Quality:
- Quote the offending sentence when you allege a problem.
- If you cannot quote it, you do not have a finding.

4. Structured extract

Role: You are a research assistant extracting records, not
interpreting them.

Task: Extract every commitment, date, owner and condition from
the text I paste.

Context: [paste meeting notes, contract extract or email thread]
Today’s date: [ISO date]
Our entity name: [name]

Constraints:
- Use only wording supported by the text.
- If owner, date or condition is missing, write “Not stated”.
- Do not merge two commitments into one.
- Do not add “implied” items.

Output: A markdown table with columns:
ID | Commitment | Owner | Date | Condition | Verbatim pointer

Then a second table of Unresolved questions.

Quality:
- The verbatim pointer must be a short quote from the source.
- Count the rows. If the source contains a numbered list, your
  extract should not silently drop an item.
- After the tables, write “Items I was unsure about:” and list them.
  If none, write “None.”

5. Meeting-to-actions, with a quality gate

Role: You are the programme manager responsible for the action log.

Task: Turn these notes into an action log and a three-line summary
for people who missed the meeting.

Context: [paste notes]
Attendees: [list]
In-scope decisions: [what this forum is allowed to decide]

Constraints:
- Do not assign an owner who is not in the attendee list unless
  the notes explicitly name them.
- Do not invent deadlines.
- Do not record a decision that is only a discussion.

Output:
1. Summary (three sentences: purpose, decision, open issue)
2. Decisions table: Decision | Evidence in notes
3. Actions table: Action | Owner | Deadline | Dependency
4. Parking lot: items raised but not decided

Quality:
- If a field is missing, “Not stated”.
- Flag any action that is actually a wish with no owner.
- End with questions I should confirm with the chair before
  circulating.

Each template can be stored as a snippet with the RTCCOQ headings already typed. Filling the context is the work. Resist the urge to strip the quality block. That block is what keeps the extract from becoming a story.

Common prompt failures

Most failed prompts fail in the same few ways. Recognising the pattern is faster than collecting new techniques. The table is a field guide. Use it when a draft feels wrong and you are tempted to blame the model in general.

A personal prompt library

Capability in this domain is cumulative only if you keep the briefs that worked. A prompt library is not a folder of viral templates. It is a short, dated set of prompts you have used on real work, with a note on what they produced and where they failed. Five excellent prompts you trust will outperform fifty you collected and never ran.

The habit is simple. After a prompt earns its place — an email that needed only light edits, an extract that survived a source check, a critique that found a real hole — copy it into a note with a title, the date, the job it is for, and one line on the failure mode it still has. When a prompt fails, do not delete it in annoyance until you have written why. “Failed because budget numbers were not in context” is a lesson. “AI is useless at finance” is not.

Organise by job, not by model. Models change. Jobs do not: decline an invitation, extract actions, brief a senior, critique a draft, turn a table into a narrative that does not invent. Keep RTCCOQ headings in the stored text so you can see which axis you usually skip when you are in a hurry. Most people skip quality and constraints. Seeing the empty headings is the reminder. Strip client facts before you share a prompt on a wiki. What you share is the brief structure. What you do not share is last Tuesday’s paste.

Putting the loop to work

A professional prompting session on a real artefact looks ordinary from the outside. You classify the data. You paste the notes you are allowed to paste. You fill RTCCOQ, often from a template. You take the first output as a draft. You check it against the notes, not against how finished it sounds. You send a short improvement. You ask for a critique from a different role. You verify names, numbers, dates and quotations. You rewrite the two sentences that still carry risk. You put your name on the issued version.

That loop is slower than “one prompt, one paste into the pack.” It is faster than the correction cycle that follows a fluent error. It is also how you stay in the job. The model can produce structure, options, extracts and a first letter. It cannot accept accountability. The quality axis exists to make your accountability cheaper to exercise, not to transfer it. The next chapters apply this brief to everyday work, then to data, then to thinking partners and systems. Keep RTCCOQ and the same six questions will carry you from an email to a RAG evaluation without a new personality for each tool.

Key takeaways

• Prompt engineering is designing a work brief so the model can produce useful, reliable, structured results.
• RTCCOQ is Role, Task, Context, Constraints, Output, Quality. Weak prompts specify a vague task and skip the rest.
• A strong prompt names the professional stance, the artefact, the sources, the bans, the shape and the failure path.
• Zero-shot is the default. Few-shot beats role when house format or edge cases are hard to describe as rules.
• Decompose mixed jobs. Keep evidence, inference and recommendation in separate artefacts or headings.
• Ask for uncertainty as labelled output. Do not ask the model whether it is sure.
• The loop is Prompt, Output, Review, Improve, Critique, Final output. The first answer need not be final.
• Keep templates for email, analysis, critique, structured extract and action logs. Adapt context; keep the quality block.
• A personal library of dated, job-based prompts, with known failures recorded, is how the skill compounds.
• Prompting reduces the room for invention. It does not replace the verification duty in Chapter 3.