Prompt library
Prompts for project delivery work
Each prompt tells the model what it may not do as clearly as what it should. That's what keeps the output tied to your data.
Replace the bracketed parts with your own material. Only paste project data into AI tools your organisation has approved for it, and check the output before you use it.
Project controls
Basis of estimate challenge
Acts as a critical reviewer of an estimate's assumptions so gaps are found before an independent review does.
Act as an experienced independent cost reviewer. Below is a basis of
estimate (BoE) for one work package.
For each assumption, quantity or rate in the BoE:
1. Say whether it is supported by stated evidence (a quote, historical
data, a drawing, a norm). Quote the evidence or write "No evidence
stated".
2. Ask the question a reviewer would ask about it.
3. Rate the exposure if it's wrong: Low / Medium / High, with one
line of reasoning.
Then list:
- Scope that seems to be missing (labelled as questions, not facts).
- Any double counting you suspect.
- The three assumptions that most need firming up before review.
Rules:
- Do not produce a new estimate or new figures.
- Be direct. The aim is to find weaknesses.
[paste basis of estimate here]Reporting
Meeting notes to actions
Pulls actions, owners and dates out of rough meeting notes and flags anything unclear instead of guessing.
Below are notes from a project meeting. Extract the actions.
Return a table with columns:
Action | Owner | Due date | Source line
Rules:
- Only include actions someone agreed to do. Ignore discussion.
- Owner must be a name or role stated in the notes. If none is
stated, write "Owner not stated".
- Due date must be stated in the notes. If it isn't, write
"No date agreed". Do not suggest one.
- "Source line" quotes the few words in the notes the action came from.
After the table, list:
- Decisions made (one line each).
- Anything that sounds like an action but is too vague to assign.
[paste notes here]Reporting
Period report narrative
Drafts variance commentary for a monthly report from your tables and CAM notes, without inventing causes.
You are drafting the narrative section of a monthly project report
for a project board.
Inputs below: variance table by control account, milestone movements,
CAM notes on causes, and risk/change updates.
Write:
1. A 3-sentence summary of overall cost and schedule position.
2. One short paragraph per control account that breaches a threshold:
the variance, the cause, the recovery action, the forecast impact.
3. Milestones that moved more than 2 weeks, with the reason.
Rules:
- Use only figures from the inputs. Do not calculate new ones.
- Only give a cause if a CAM note states it. Otherwise write
"Cause not yet confirmed".
- If inputs conflict, list the conflict at the end instead of
choosing one.
- Plain English. No adjectives like "significant" without a number.
[paste tables and notes here]Project controls
Risk register review
First-pass quality review of a risk register export: vague wording, duplicates, missing owners and stale actions.
You are reviewing a project risk register for quality, not deciding
the risks themselves.
Input below: the register as a table (ID, title, cause, event, effect,
owner, probability, impact, score, response, actions, action dates,
last reviewed).
Report, quoting risk IDs each time:
1. Risks without a clear cause-event-effect structure. Suggest a
rewrite in the form "Because of [cause], [event] may occur,
leading to [effect]." Mark rewrites as suggestions.
2. Likely duplicates or overlaps, with a short reason.
3. Risks with no owner, no response, or actions past their date.
4. Risks not reviewed in the last 90 days (use today's date: [date]).
5. Scores that look inconsistent with the stated probability and
impact under this scale: [describe scale].
Rules:
- Don't change probabilities or impacts. Flag, don't fix.
- Don't add new risks unless asked. You may list "possible gaps"
separately at the end, clearly labelled.
[paste register here]Project controls
Schedule health findings
Turns exact health-check results into patterns, likely causes and a fix list. Give it the results, not the raw schedule.
You are helping a planner act on a schedule health check.
Inputs below:
- A results table: each check, the count, the percentage and the limit.
- A list of failing activities: activity ID, name, WBS, owner,
and which check each one fails.
Do this:
1. For each failed check, say where the failing activities cluster
(by WBS, owner, activity type or naming pattern). Quote activity IDs.
2. Give the most likely causes for each cluster, marked as likely,
not confirmed. Do not invent facts about the project.
3. Explain in two or three plain sentences what the failures mean for
how far the critical path and forecast dates can be trusted.
4. Write a fix list grouped by owner: activity IDs, the problem, the
suggested fix.
Rules:
- Use only the counts given. Do not recount or estimate.
- Every claim must cite at least one activity ID.
- If the data doesn't support a conclusion, say so.
[paste results table and failing activities here]