AI Prompts for Engineers

Write the technical approach section of an engineering proposal in response to a client brief.

Project: [project name and location]
Client / issuing body: [name]
Discipline: [civil / structural / mechanical / electrical / other]
Scope requested: [what the client is asking for, e.g., condition assessment, detailed design, feasibility study]
Key requirements from the brief: [list the client's stated requirements, deliverables, and constraints]
Our relevant experience: [1-3 comparable projects and what we did]
Proposed deliverables: [list]
Programme / timeline: [key dates or duration, or write "to confirm"]

Requirements for the output:
- Structure it as: Understanding of the Brief, Proposed Approach / Methodology, Deliverables, Programme, Why [our firm].
- Reference applicable codes and standards only if I named them above; otherwise write "[standard TO CONFIRM]". Do not invent standard numbers.
- Do not invent fees, durations, team sizes, or any figures. Use only what I provided and mark anything missing as [TO CONFIRM].
- Professional, not salesy. No hype words like "cutting-edge" or "world-class".
- Spelling convention: [British / American].
- Length: 400-600 words, with clear headings and short paragraphs.

Write an executive summary for an engineering report.

Report title: [title]
Discipline: [civil / structural / mechanical / electrical]
Purpose of the report: [why it was commissioned]
Key findings: [list the main findings as plain bullets; include any figures exactly as I state them]
Conclusions: [list]
Recommendations: [list, with priority if known]
Audience: [client / contractor / building owner / regulator]

Requirements:
- One page maximum, 250-350 words.
- Order: purpose (1-2 sentences), summary of findings, conclusions, recommendations, next steps.
- Lead with what the reader needs to decide or do.
- Use only the findings, figures, and recommendations I provided. Do not add, calculate, round, or extrapolate any numbers. Flag gaps as [TO CONFIRM].
- Plain, professional English a non-engineer can follow, but keep technical terms where precision matters.
- Do not state any conclusion I did not give you.

Rewrite the following technical findings so a non-technical client can understand them, without losing accuracy.

Technical findings (as written by me):
[paste your technical text, results, or observations]

Client / audience: [e.g., building owner, developer, facilities manager]
What they need to decide or do: [the action or decision this affects]
Tone: [reassuring / neutral / urgent, based on the situation]

Requirements:
- Explain what the finding means and why it matters to them, in plain language.
- Keep every figure, unit, and technical qualifier exactly as I wrote it. Do not round, convert, recalculate, or invent any numbers.
- Where I used jargon, add a short plain-English gloss in brackets rather than deleting the term.
- If a finding implies risk, state it honestly, without overstating or understating.
- Do not add reassurance, caveats, or recommendations I did not include.
- End with a short "What this means for you" section (2-4 sentences) and any next step I clearly stated.
- Match the length of the source. Do not pad.

Draft a structured engineering report from my notes.

Report type: [condition/inspection report, feasibility study, design report, forensic/failure investigation, due diligence]
Project / asset: [name, location, type]
Discipline: [civil / structural / mechanical / electrical]
Site visit / inspection date: [date, or "desktop only"]
Background / instruction: [who instructed the work and why]
Observations and data (as I recorded them): [paste bullets, measurements, described photos, test results, exactly as recorded]
Applicable standards / codes: [list the ones I am relying on, or "TO CONFIRM"]
Conclusions I have reached: [list, or leave blank]
Recommendations: [list, or leave blank]

Requirements:
- Use this structure: 1. Introduction & Instruction, 2. Scope & Limitations, 3. Methodology, 4. Observations / Findings, 5. Discussion, 6. Conclusions, 7. Recommendations, 8. Assumptions & Limitations.
- Reproduce my observations, measurements, and results verbatim. Do not perform calculations, estimate values, assess code compliance, or invent standard clauses. Insert [TO CONFIRM] wherever a value or standard is missing.
- In Scope & Limitations, state clearly that conclusions are based only on the information and observations provided.
- Neutral, factual, professional register suitable for a report that may be relied upon by third parties.
- Flag anywhere my notes look inconsistent or incomplete with a bracketed [Author to check: ...] note.
- If I left Conclusions or Recommendations blank, do not write them for me; instead list the questions you need me to answer to complete those sections.

Draft a technical specification section for the following works or equipment.

Element / system being specified: [e.g., structural steelwork, HVAC plant, drainage, LV switchgear]
Project: [name]
Applicable standards / codes: [list; I will provide these, do not invent any]
Performance requirements: [list what it must achieve, with any figures I provide]
Materials / products: [named products or material grades, if specified]
Workmanship / installation requirements: [list]
Testing and acceptance criteria: [list]

Requirements:
- Use a numbered clause structure (1.1, 1.2, ...) grouped under: General, Materials, Design / Performance, Workmanship, Testing & Acceptance, Submittals.
- Write in imperative specification language ("The Contractor shall...").
- Reference only the standards and figures I provided. Never insert a standard number, material grade, tolerance, or acceptance value I did not give; mark those [TO CONFIRM].
- Keep each clause single-subject and unambiguous.
- Do not add design assumptions or calculated values.
- Flag any requirement that appears to conflict with another as [Check: possible conflict].

Write a method statement / scope of work for the following activity.

Activity / works: [describe the task]
Project & location: [name]
Discipline: [civil / structural / mechanical / electrical]
Sequence of operations (as I intend it): [list the steps in order]
Plant, equipment, and materials: [list]
Personnel / responsibilities: [roles involved]
Key hazards I have identified: [list; I will provide these]
Standards / permits required: [list, or "TO CONFIRM"]

Requirements:
- Structure: Purpose & Scope, References, Responsibilities, Sequence of Works (step by step), Plant & Materials, Health & Safety / Key Hazards, Inspection & Hold Points.
- Expand my step sequence into clear, ordered instructions without adding steps I did not describe.
- For Health & Safety, list only the hazards and controls I provided. Do not invent risk ratings, PPE requirements, or regulations; mark gaps as [TO CONFIRM with SHE/EHS].
- Use practical site language a supervisor and crew can follow.
- Do not assume site-specific conditions I have not stated.

Draft a Risks, Assumptions, and Exclusions section from my notes.

Project / deliverable: [name]
Stage: [feasibility / concept / detailed design / construction]
Risks I have identified: [list each risk; include likelihood or impact only if I state them]
Assumptions I am making: [list]
Exclusions (out of scope): [list]
Dependencies (on client or others): [list]

Requirements:
- Present risks as a table with columns: Risk, Potential Consequence, Owner, Mitigation / Action. Use only what I provided; leave a cell as [TO CONFIRM] if I did not give it.
- Do not invent risk scores, probabilities, or cost/schedule impacts.
- Write Assumptions and Exclusions as clear numbered statements a client can review and sign off.
- Phrase each assumption so it is obvious what happens if the assumption proves false.
- Add a one-line note that these are based on information available at [date/stage] and should be revisited as the project develops.
- Neutral, defensible wording suitable for a document that manages professional liability.

Write a project status update email.

Project: [name]
Reporting period: [dates]
To: [client / PM / stakeholder]
From: [your name / role]
Progress this period: [what got done, as bullets]
Upcoming activities: [next steps]
Issues / risks needing attention: [list, or "none this period"]
Decisions or information needed from the client: [list]
Programme status: [on track / delayed, and why, in my words]

Requirements:
- Structure: one-line status headline, Progress, Look-Ahead, Items Needing Your Action, then close.
- Lead with the overall status so a busy reader gets it in five seconds.
- Use only the progress, dates, and issues I provided. Do not invent percentages complete, dates, or milestones.
- Make "Items Needing Your Action" impossible to miss, each with a clear owner and, where I gave one, a date.
- Professional, concise, no filler. Under 250 words.
- If the programme is delayed, state it plainly and factually, without over-apologizing or over-explaining.

Turn my rough meeting notes into formal minutes.

Meeting: [title / type, e.g., design coordination, site progress]
Date & location: [date, venue or call]
Attendees: [names and organizations / roles]
Apologies: [names, if any]
My rough notes: [paste everything discussed, in any order]

Requirements:
- Produce: a header block (meeting, date, attendees, apologies), then numbered minute items grouped by topic, then an Actions table (Action, Owner, Due Date).
- Attribute points and decisions only to the people I named. Do not invent attendees, decisions, dates, or actions.
- Distinguish clearly between decisions made, information shared, and actions agreed.
- Where my notes are ambiguous about who owns an action or the due date, mark it [Owner TO CONFIRM] or [Date TO CONFIRM] rather than guessing.
- Neutral, concise, third-person past tense.
- Carry forward any item I flagged as "open" or "ongoing".

Write the explanatory narrative that accompanies an engineering calculation I have already completed and verified. You are writing the words around the numbers, not doing the maths.

Calculation subject: [e.g., beam design, pump sizing, cable sizing, foundation bearing check]
Discipline: [structural / mechanical / electrical / geotechnical]
Standard / code used: [I will name it; do not substitute another]
Design inputs I used: [list the inputs and their values, exactly]
Method / approach I followed: [describe the steps or the clause I applied]
Result I obtained: [state my result exactly]
Utilisation / pass-fail conclusion I reached: [state it exactly]

Requirements:
- Explain, in prose, the purpose of the calculation, the design basis, the assumptions, the method, and what the result means for the design.
- Do NOT perform, check, reproduce, or "correct" any calculation. Do not compute new values, safety factors, utilisations, or results. Use my stated inputs and result verbatim.
- If a step in my method is unclear or a value is missing, ask me rather than filling it in.
- Reference the code or clause only as I named it. Do not cite clause numbers I did not provide.
- Structure: Purpose, Design Basis & Assumptions, Inputs, Method, Result, Conclusion.
- Include a line noting that the calculation and its inputs remain the responsibility of the verifying engineer.
- Formal, auditable tone suitable for a calculation package.

Draft a response to a technical query / Request for Information (RFI).

RFI / query reference: [number or subject]
From: [contractor / client / architect]
The question asked: [paste it]
Relevant background / documents: [drawings, specs, prior correspondence I am referring to]
My technical answer (in note form): [what I want to say, the substance]
Standards / drawings I am relying on: [list, or "TO CONFIRM"]

Requirements:
- Structure: restate the query in one line, give the answer, then the basis / reasoning, then any action or clarification required from the asker.
- Convey exactly the technical position in my notes. Do not add engineering opinions, values, or approvals I did not state.
- Do not invent drawing numbers, clause references, dimensions, or specifications. Mark anything I did not supply as [TO CONFIRM].
- Precise, professional, and defensible; assume this may be read in a dispute later.
- If my answer depends on an assumption or on outstanding information, state that condition explicitly.
- Keep it concise and unambiguous.

Write a follow-up email that introduces or accompanies a fee proposal.

To: [prospective client name / company]
Context: [how we connected, e.g., enquiry, site visit, referral, tender invitation]
Their need (in my words): [what they asked us to help with]
What we are proposing to do: [scope summary, as bullets]
Deliverables: [list]
Fee basis: [lump sum / hourly / staged, and the figure ONLY if I give it; otherwise "see attached"]
Key assumptions / exclusions: [anything the fee depends on]
Next step I want: [call, sign-off, site access, etc.]

Requirements:
- Warm, professional, and confident without being salesy. No hype.
- Reference the specific context and their stated need so it does not read as a template.
- Do not state or imply a fee, timeline, or scope item I did not provide. Never invent a number.
- Summarize scope and assumptions briefly and point to the attached proposal for detail.
- End with one clear, low-friction next step.
- Under 200 words.
- Keep the English clean and simple; assume the reader may skim on a phone.