Prompts that work.

Draft a root cause analysis timeline from my notes below. Put events in time order, mark each as confirmed or assumed, and list the questions I still need to answer. Do not add causes I did not mention.

Notes: [paste notes]

Summarise this inspection finding in five lines: location, what was found, measured values, severity and recommended next step. If a value is missing, write “not provided”.

Finding: [paste finding]

Draft an FMEA table for [equipment] with columns: failure mode, effect, cause, current control, suggested action. Give six rows. Flag every row where you are guessing so I can check it.

Turn my notes into a one-page weekly report with three headings: done, in progress, risks. Keep my numbers exactly as written.

Notes: [paste notes]

Review the answer above as a sceptical senior engineer. List what is likely right, what could be wrong, and the one test I could run to check each claim.

Review my CV for a [role] position. Give me the three strongest points and three gaps, then rewrite my top five bullets with measurable results. Do not invent numbers: ask me when a result is missing.

CV: [paste CV]

Act as a rigorous thinking partner. I’ll share an idea or decision: [paste]. List my hidden assumptions, give the strongest counter-argument, and tell me one thing I haven’t considered. Ask me 3 sharp questions before you answer.

I have this problem: [describe]. Break it into sub-questions, list 3 possible root causes, say what evidence would confirm or rule out each, and tell me what to check first.

Help me decide: [decision]. Use my accessible emails and documents on this topic as evidence. Give max 3 options with benefits, risks, and key assumptions. Recommend one first, then explain why. Keep it to one page.

Imagine my plan [paste] failed badly six months from now. Write the 5 most likely reasons it failed, rank them by likelihood, and give one early warning sign and one prevention step for each.

Read this draft: [paste]. Give me the single most important conclusion in one sentence. Then give 3 supporting points, using the Minto Pyramid structure. Tell me what to cut.

My position is: [paste]. Argue the strongest case against it, then the strongest case for it. Tell me which argument is weaker and what evidence would change my mind.

Review my recent emails, chats, and documents on [project]. List risks that are mentioned only indirectly or that nobody owns. Rank the top 5 by impact and suggest who should be asked about each.

I need to convince [role, e.g. my manager or a client] about [topic]. Describe what they care about, their likely objections, and the 3 questions they will ask. Then suggest how I should open the conversation.

Look at my calendar, tasks, and emails for the coming week. Sort everything into: must do, could delegate, can drop. Give me the top 3 things that would make the week a success.

I’m asking: [question]. Before answering, tell me what I might really be trying to solve, 3 better questions I could ask instead, and which one you would answer first.

Review my week (meetings, emails, tasks). Write a 5-line “weekly sitcom recap” with funny character names for my recurring situations. Keep it kind, no real names, and end with one real insight hiding in the joke.

Based on my meetings this week, create a 5×5 bingo card of things that always happen (e.g. “You’re on mute”, “Let’s take this offline”). Make it funny but kind, and add a prize for a full row.

Take this message: [paste]. Translate it into “what they said” versus “what they might actually mean,” with a light, friendly tone. Then give me a calm, professional reply.

Look at my calendar for tomorrow and write a funny weather forecast for my day (e.g. “scattered meetings with a 70% chance of back-to-back calls”). End with one real tip for staying sane.

Based on my role and recent work, write a short comic-style origin story of my work superhero identity, with a name, a power, and a nemesis (a work annoyance, not a person). Keep it under 150 words.

Take this corporate-speak: [paste]. Rewrite it in plain, funny English, then in plain, serious English. Mark which phrases are pure fluff.

Review my week and give out 5 funny awards (e.g. “Most Valiant Calendar Reschedule”, “Email Thread of the Week”). Keep it kind, no real names, and end with one genuine thank-you to myself.

Look at my inbox themes this week and write 3 original haikus about them, one funny, one dramatic, one peaceful. Then tell me which theme I should deal with first.

Here is my to-do list: [paste]. Roast it lightly and kindly, pointing out tasks I’ve clearly been avoiding. Then pick the one I should finish in 15 minutes.

Write a 4-panel comic script about a typical moment in my workday: [describe]. Include simple scene descriptions, short dialogue, and a punchline in panel 4. Use animal or object characters, not real people.

Pick one concept from my recent work I use but may not fully understand. Explain it with an everyday analogy, then quiz me with 3 questions: one easy, one tricky, one “what if”.

Explain [topic] three ways: to a 10-year-old, to a new colleague, and to an expert. Keep each under 80 words and highlight what changes between levels.

Choose a topic from my recent documents or meetings that I should understand better. Give me a 5-minute lesson: why it matters, 3 key ideas, one real example from my work, and one question to test myself.

Scan my recent documents and emails. List the 15 most-used technical terms or acronyms, define each in one plain sentence, and mark any that seem to be used inconsistently.

I’ll explain [topic] in my own words: [paste]. Grade my explanation out of 10, tell me what’s correct, what’s missing or wrong, and give me one tip to make it clearer.

I find [topic] hard to grasp. Give me 3 analogies from everyday life (kitchen, travel, family), tell me where each analogy breaks down, and recommend the best one.

Review my work this week and capture 3 lessons: what worked, what didn’t, and what I would do differently. Write each as one reusable sentence I can share with my team.

I want to learn [skill] in 4 weeks with 30 minutes a day. Create a week-by-week plan with a small weekly goal, daily tasks, and a mini project to practise on using my real work.

Turn this document [attach or paste] into 10 flashcards (question on one side, answer on the other). Focus on the ideas I’m most likely to forget. Group them by theme.

Here is a prompt I wrote: [paste]. Tell me what’s unclear, what’s missing (role, context, format, limits), and rewrite it into a better version. Explain the changes in 3 bullets so I learn.

Based on my role, suggest one thing I’ve never tried with AI that feels slightly scary but is doable in 30 minutes. Give the steps, what could go wrong, and how I’ll know it worked. Make it exciting, not overwhelming.

Look at my recurring tasks this month. Pick the one most worth automating with AI, explain why, and give me a simple step-by-step to try it this week. Start with the easiest version.

I want a simple tool for [task, e.g. tracking inspection findings]. Suggest the easiest way to build it with Excel and Copilot, give me the columns or structure, and the first prompt to try.

I’ve been avoiding this task: [describe]. Break it into 5 tiny steps, each under 10 minutes. Tell me the very first one and a simple way to reward myself after.

Analyse only emails and messages I personally wrote. Describe my tone, sentence length, and habits in 5 bullets, then write a paste-ready instruction that makes Copilot sound like me.

I need to present [topic] to [audience] soon. Create a 6-slide outline with a title, one key message, and one visual idea per slide, plus a 30-second opening line. Keep it simple and confident.

My usual way of doing [task] is: [describe]. Suggest 3 completely different ways to do it, one using AI, one with fewer steps, and one bold approach. Tell me the risk of each.

Here is something I tried with AI: [describe]. Write a short, honest post about it covering what I tried, what surprised me, and one tip for others. Keep it under 120 words and friendly.

Based on my role, suggest one thing at work I’d normally say “that’s not for me” to, and show me how AI could help me try it. Include a small, safe first step.

Create a 7-day challenge to build my AI confidence. Each day: one task under 15 minutes, linked to my real work, getting slightly bolder each day. End with a day-7 reflection question.

Review my calendar for the coming week, focusing on recurring meetings. For each, recommend keep, shorten, skip, or delegate, with a one-line reason based on my role and recent emails or chats. Show the top 3 hours I could reclaim. Add a kind one-sentence decline message for each skip. Report only. Do not change my calendar or send anything. If evidence is thin, say so instead of guessing.

Check emails sent directly to me in the past 14 days that I haven’t replied to. Skip newsletters, FYIs, and anything already resolved. Rank them by urgency. For each, give the sender’s ask, a one-line nudge I can copy, and a playful “guilt level” from 1 to 5 (kind, never mean). End with the 3 I should answer first. Report only. Do not send or draft anything.

Review my unread emails from the past 24 hours. Skip newsletters, FYIs, and automated messages. For each email that needs a reply, write a short draft in my writing style (clear, warm, direct) that I can copy and paste. Group them by urgency: reply today, reply this week. List what you skipped and why. Flag any email where you lack information to answer instead of guessing. Report only. Do not send anything or change my mailbox.

Act as an inspection data analyst for oil and gas asset integrity. Clean the inspection history I provide so it is ready for analysis. Produce a DRAFT for engineer review.

Input: [attach Excel or paste rows]. Asset type: [vessel / piping / tank]. Units: [mm / in / mixed].

Do this:
1. Profile the data: columns, blanks, data types, duplicate rows, inconsistent tags.
2. Propose standard column names: asset tag, CML/TML ID, inspection date, method, nominal thickness, measured thickness, units, inspector, remarks.
3. Fix on a COPY only: date formats, text-stored numbers, mixed units, tag spelling, duplicates. Never change the raw data.
4. Flag, do not delete: thickness increasing over time, zero or negative values, impossible dates, missing units.
5. Output: (a) cleaned table, (b) change log with row, field, old value, new value, reason, (c) flagged-items list, (d) up to 3 questions only if you are blocked.

Standards to apply: API 510, 570 and 653 inspection record content, and API 574 for CML practice. Name the standard only. Flag any clause or edition for me to verify.

Rules: do not invent readings, dates or units. Write “not provided” for gaps. If the file is too large for chat, give me Power Query or Python steps instead.

Act as an asset integrity data analyst. Merge the sources I provide into ONE inspection register. Produce a DRAFT for engineer review.

Sources: [list files: e.g. contractor reports, old Excel, CMMS export, UT database]. Asset scope: [unit / plant].

Do this:
1. List each source: columns, date range, asset count, quality issues.
2. Build a mapping table from each source’s columns to one common structure.
3. Match assets and CMLs across sources. Show matches as confirmed, probable or unmatched. Never force a match.
4. Resolve conflicts (same asset and date, different value) by listing both values and the source of each. Do not choose silently.
5. Output: merged register, mapping table, conflict list, unmatched list, change log, and a source column on every row.

Standards to apply: API 510, 570 and 653 record requirements. Name the standard only and flag clauses for me to verify.

Rules: keep the original source and row number for every merged row. Do not invent values. Write “not provided” for gaps.

Act as a corrosion and inspection engineer. Calculate corrosion rates and remaining life from the thickness data I provide. Produce a DRAFT for engineer review.

Input: [attach or paste readings: asset, CML, date, thickness]. Provided by me: nominal or initial thickness [..], required (minimum) thickness [..], corrosion allowance [..], units [..].

Calculate per CML:
– Long-term rate = (initial thickness – latest thickness) / years between those dates.
– Short-term rate = (previous thickness – latest thickness) / years between those dates.
– Governing rate = the higher of the two, unless I state otherwise.
– Remaining life = (latest thickness – required thickness) / governing rate.
– Suggested next inspection = not more than half the remaining life, and not more than the maximum interval in the applicable code.

Show formulas with units and one worked example row. Flag anomalies: negative rates (thickness gain), a sudden jump, a single reading far from its neighbours, fewer than 2 data points. Summarise the worst 10 CMLs.

Standards to apply: API 510, 570 or 653 as relevant. Name the standard only. I will verify intervals and clauses.

Rules: use ONLY the required thickness I give you. Do not calculate it. Do not invent readings. Write “not provided” for gaps. Treat the result as a screening calculation, not an approved life.

Act as an inspection records analyst. Extract structured data from the report text or scanned pages I provide. Produce a DRAFT for engineer review.

Input: [attach pages or paste text]. Report type: [UT / visual / MPI / CUI / other].

Extract into a table: asset tag, report number, inspection date, method, location or CML, measured value with unit, finding description, severity if stated, recommendation if stated, source page and line.

Rules:
– Add a confidence column: high, medium or low.
– If text is unclear, write [illegible] and list it for me to check. Never guess a value.
– Keep original wording in a “raw text” column.
– List anything that looks contradictory, such as two different dates or values for the same item.

Standards to apply: API 574, and API 510, 570 or 653 record content. Name the standard only and flag clauses for me to verify.

Output: table, low-confidence list, contradictions list, up to 3 questions only if blocked.

Act as an asset integrity engineer preparing a study. Audit the data I provide and tell me what is missing before the study starts. Produce a DRAFT for engineer review.

Input: [attach asset list and any data]. Study type: [asset life / RBI / corrosion study / FFS screening].

For each asset check: design data (pressure, temperature, material, nominal thickness, corrosion allowance), inspection history (dates, CML count, latest readings), process and damage-mechanism data, repair and modification history, last and next inspection dates, failure or leak history.

Output:
1. Gap matrix: assets as rows, data items as columns, each marked present, partial or missing.
2. Priority list: which gaps block the study and which only reduce confidence.
3. Where each missing item is likely to be found (datasheet, CMMS, P&ID, past report).
4. A request list I can send to each data owner.

Standards to apply: API 580 and 581 data needs for RBI, ISO 14224 for failure data, and API 510, 570 or 653 records. Name the standard only and flag clauses for me to verify.

Rules: do not fill gaps with assumed values. Write “not provided”.

Act as an asset integrity engineer. Draft an asset life study report from the data I provide. This is a DRAFT for engineer review, not an approved life assessment.

Input: [attach inspection history, design data, process data, past reports]. Asset(s): [tag / unit]. Design life and age: [..]. Intended future operation: [..].

Do this:
1. Summarise each asset: service, design data, materials, age, inspection history.
2. Assess data quality. List gaps that limit confidence (see my gap audit if I attach it).
3. Show corrosion rates and remaining life per asset, using only the required thickness I supply. Show formulas and units.
4. Identify the likely life-limiting damage mechanisms from the data. Mark each as confirmed, probable or hypothesis.
5. Estimate a remaining-life range (best case, expected, worst case) with the assumptions behind each. No single-point claims.
6. List key uncertainties and what data would narrow the range.
7. Recommend next inspection scope, monitoring, and run, repair or replace options for the engineer to decide.

Report structure: executive summary, scope, data used, method, results table, discussion, uncertainties, recommendations, open items, assumptions register.

Standards to apply: API 510, 570 and 653 for in-service life and intervals, ISO 55000 for asset management context. Name the standards only. Flag every edition and clause for me to verify.

Rules: do not invent readings, rates, dates or design limits. Write “not provided” for gaps. Mark every number with its source. Add a “Reviewer checklist” at the end listing what the engineer must verify before issue.

Act as a corrosion and materials engineer. Draft a damage mechanism review for the equipment I describe. This is a DRAFT for engineer review.

Input: [attach or paste process data, P&ID notes, material, temperature and pressure ranges, fluid composition, contaminants, start-up and shutdown conditions, insulation, coating, past failures]. Equipment: [tag / type].

Do this:
1. Summarise the operating conditions and say which are normal, upset or intermittent.
2. List credible damage mechanisms for each equipment item or circuit. For each give: why it applies (the specific condition), susceptible locations, expected morphology, key influencing factors, and whether it is active, possible or unlikely.
3. Rate confidence for each (high, medium, low) and state what data is missing.
4. Suggest detection and monitoring methods for each mechanism, and the limits of each method.
5. Suggest candidate integrity operating window parameters (variable, why it matters) for the engineer to set. Do not propose numeric limits unless I supply them.
6. Output: summary table (equipment, mechanism, basis, confidence, inspection method), then short notes per mechanism.

Standards to apply: API 571 for damage mechanisms, API 584 for integrity operating windows, and NACE/AMPP or ISO 15156 where sour service applies. Name the standards only. Flag clauses and editions for me to verify.

Rules: do not claim a mechanism is active without evidence in my data. Separate “credible from conditions” from “confirmed by inspection”. Do not invent process values. Write “not provided” for gaps. End with a reviewer checklist.

Act as a corrosion engineer. Draft a corrosion study report from the data I provide. This is a DRAFT for engineer review.

Input: [attach inspection data, process data, corrosion monitoring data (coupons, probes), chemistry or injection records, past corrosion reports]. System: [unit / circuit].

Do this:
1. Define the system, circuits and corrosion loops. Group items with similar service and material.
2. Summarise inspection and monitoring results per circuit: corrosion rates, trends, worst locations.
3. Compare measured rates with the expected rates and mechanisms from the process data. Flag mismatches.
4. Check consistency between monitoring data (coupons, probes) and inspection data. Note where they disagree.
5. Review mitigation: inhibitors, chemistry control, coatings, materials, operating limits. Say what the data shows about effectiveness. Do not assume effectiveness without data.
6. Recommend: monitoring changes, inspection focus, mitigation review, and items for the engineer to decide.

Report structure: executive summary, system description, data used, results by circuit, discussion, recommendations, open items, assumptions register.

Standards to apply: API 970 for corrosion control documents, API 571 for mechanisms, ASTM G16 for corrosion data statistics, and ASTM G1 and G31 for coupons where relevant. Name the standards only. Flag clauses and editions for me to verify.

Rules: do not invent rates, coupon results or chemistry data. Mark each statement as measured, calculated or assumed. Write “not provided” for gaps. End with a reviewer checklist.

Act as an RBI engineer. Check my RBI input pack and draft a narrative for the results. This is a DRAFT for engineer review.

Input: [attach RBI input data, results export, damage mechanism assignments, inspection history, risk matrix definition]. Method used: [API 580/581 based software or company method]. Scope: [unit / plant].

Part A: Input check
1. Check completeness per asset: design data, materials, inventory, fluid, damage mechanisms, inspection history and effectiveness, corrosion rates.
2. Flag inconsistencies: rate vs history, mechanism vs fluid or material, effectiveness claimed vs method actually used, missing last inspection dates.
3. List assumptions and defaults that may be driving the risk result.

Part B: Results narrative
1. Summarise the risk distribution (by category, by unit, by mechanism).
2. Describe the highest-risk items: what drives the risk (probability or consequence), and what data it depends on.
3. Note risk changes versus the last study if I supply them.
4. List planned inspection changes proposed by the results, and which ones depend on weak input data.
5. Draft a short management summary and a technical summary.

Standards to apply: API 580 and API 581 for RBI methodology, and ASME PCC-3 for inspection planning using RBI. Name the standards only. Flag clauses and editions for me to verify.

Rules: do NOT recalculate probability or consequence of failure unless I give the full method and inputs. Do not change any input. Do not invent data. Write “not provided” for gaps. End with a reviewer checklist, including checks against the company RBI procedure.

Act as an integrity engineer preparing an FFS screening note. Summarise what the data shows and route the item to the right assessment. This is a DRAFT for engineer review. It is NOT a fitness-for-service assessment and must not state that equipment is fit for continued service.

Input: [attach inspection findings, design data, operating data, drawings or sketches, previous assessments]. Equipment: [tag / type]. Flaw or damage found: [description].

Do this:
1. Describe the flaw or damage: type, location, size, orientation, how it was measured, and measurement uncertainty.
2. List the data needed for an assessment (design code and edition, material and properties, design and operating conditions, thickness data, loads, future damage rate) and mark each as provided or missing.
3. Say which type of damage this looks like (general or local metal loss, pitting, crack-like flaw, blister, dent or gouge, etc.) and which part of the standard is likely to apply. Name the part only.
4. Suggest what assessment level might be considered and why, for a qualified engineer to confirm.
5. List interim actions the engineer may consider (re-inspection, monitoring, operating limits, temporary repair) without recommending any as approved.
6. Output: one-page screening summary, data gap list, questions for the assessor.

Standards to apply: API 579-1/ASME FFS-1, plus the original construction code and API 510, 570 or 653 for repair and rerating. Name the standards only. Flag parts, clauses and editions for me to verify.

Rules: do not calculate acceptance, remaining strength or allowable flaw size. Do not invent dimensions or properties. Write “not provided” for gaps. Final fitness-for-service decisions belong to a qualified engineer. End with a reviewer checklist.

Act as a reliability engineer. Turn the failure records and notes I provide into an RCA timeline and a clean failure dataset. This is a DRAFT for engineer review. It does not declare a root cause.

Input: [attach work orders, CMMS export, operator logs, inspection reports, incident notes, photos described in text]. Equipment: [tag / type]. Event(s): [description and date].

Do this:
1. Build a timeline in date and time order: what happened, source document, and a status of confirmed (documented) or assumed (inferred).
2. List conflicts between sources (different dates, different descriptions) and show both versions.
3. Build a failure dataset for this equipment with columns: failure date, equipment tag, failure mode, failure mechanism, failure cause (if documented), detection method, consequence, downtime, repair action, source reference. Use “not provided” for anything not in the records.
4. List possible causal factors as hypotheses only. For each, state the evidence for, the evidence against, and the evidence still needed.
5. Suggest an RCA method (for example 5-Whys, fault tree, cause-and-effect diagram) and draft the first level of it from confirmed facts only.
6. Output: timeline table, dataset table, conflict list, hypothesis table, evidence-gap list, up to 3 questions only if blocked.

Standards to apply: IEC 62740 for root cause analysis, and ISO 14224 for failure data taxonomy. Name the standards only. Flag clauses and editions for me to verify.

Rules: do not invent dates, causes or findings. Do not name a root cause unless my data supports it, and even then label it “proposed”. Write “not provided” for gaps. End with a reviewer checklist.

Act as a materials engineer. Draft a material selection comparison for the service I describe. This is a DRAFT for engineer review, not an approved selection.

Input: [service description, fluid composition, contaminants (H2S, CO2, chlorides, O2, etc.), operating and design temperature and pressure ranges, pH, flow velocity, design life, equipment type, candidate materials if any, datasheets or company material specs I attach]. Constraints: [budget, availability, fabrication, existing materials in the system].

Do this:
1. Summarise the service conditions, separating normal, upset and shutdown conditions.
2. List the credible damage mechanisms for those conditions and the material requirements they create.
3. Compare 3 to 5 candidate materials in a table: suitability for the service, main risks, limits stated in the attached datasheets or specs, fabrication and welding considerations, inspection and monitoring needs, relative cost level (low, medium, high), availability.
4. Use only property values and limits that appear in my attached sources or that I state. Where a limit is needed and not supplied, write “to be confirmed from standard or supplier” and do not fill it in.
5. State trade-offs, residual risks, and what testing or data would reduce the uncertainty.
6. Give a ranked shortlist with reasoning, for the engineer to decide.

Standards to apply: ISO 21457 and NORSOK M-001 for materials selection in oil and gas, ISO 15156 (NACE MR0175) for sour service, and API 571 for mechanisms. Name the standards only. Flag clauses and editions for me to verify.

Rules: do not invent compositions, limits, hardness values or temperature ranges. Do not claim a material is acceptable for sour service without the check against the standard. Write “not provided” for gaps. End with a reviewer checklist.

Act as a cathodic protection engineer. Review the CP survey data I provide and draft a summary. This is a DRAFT for engineer review, not a CP assessment sign-off.

Input: [attach survey data: structure-to-electrolyte potentials (on and instant-off), test point IDs, dates, rectifier or anode readings, current output, coating survey results, interference notes]. Structure: [pipeline / tank bottom / jetty / vessel]. Protection criteria to use: [state the criteria from the company procedure or attach it].

Do this:
1. Clean and tabulate the data: test point, location or chainage, date, measurement type (on or instant-off), value, units, reference electrode type.
2. Compare each reading with the criteria I supplied. Mark pass, fail or cannot assess (for example only on-potentials given where instant-off is needed).
3. Flag: readings that fail, readings with missing reference electrode or method, big changes from the previous survey, suspect values, and gaps in coverage.
4. Show trends against previous surveys if I attach them.
5. Review rectifier and anode data for output changes or signs of depletion, using only the numbers provided.
6. Suggest follow-up for the engineer to decide: re-measurement, closer interval survey, coating survey, interference check, rectifier adjustment, anode inspection.
7. Output: results table, exceptions list, trend summary, follow-up list, draft survey summary paragraph.

Standards to apply: AMPP SP0169 for control of external corrosion on buried or submerged metallic piping, ISO 15589-1 for onshore pipelines (ISO 15589-2 for offshore), and the relevant AMPP or ISO test and survey practice for the structure. Name the standards only. Flag clauses and editions for me to verify.

Rules: use only the protection criteria I supplied. Do not state numeric criteria from memory. Do not invent readings or correct them. Write “not provided” for gaps. End with a reviewer checklist, including whether IR-drop and instant-off methods were valid.

Act as an inspection engineer. Turn the inspection findings I provide into clear recommendations and a work scope draft. This is a DRAFT for engineer review. The engineer decides priority and approves the scope.

Input: [attach findings, photos described in text, readings, drawings or sketches, previous recommendations, the company priority or risk matrix]. Equipment: [tag / type]. Report date: [..].

Do this:
1. List each finding in a table: location, description, measured value and unit, method, comparison with the previous inspection, and whether it is new or repeated.
2. For each finding, write a recommendation in plain, specific language: what to do, where, and by when as a proposed timeframe. If the company matrix is attached, use it to propose a priority. Mark the priority as “proposed”.
3. Link each recommendation to the finding it addresses. Note any that depend on an assessment first (for example FFS screening, engineering review).
4. Draft a work scope: tasks, access needs (scaffold, insulation removal, isolation), inspection or repair methods, hold points, and information to be recorded on completion.
5. List what is unclear or missing in the findings before work can be planned.
6. Output: finding and recommendation table, draft work scope, open-questions list, and a short summary paragraph for the inspection report.

Standards to apply: API 510, 570 or 653 as relevant for inspection, repair, alteration and rerating, and API 574 for inspection practice. Name the standards only. Flag clauses and editions for me to verify.

Rules: do not invent findings, dimensions or deadlines. Do not state that equipment is safe to operate. Do not set a final priority without my matrix. Write “not provided” for gaps. End with a reviewer checklist.

Act as an asset integrity engineer writing for management. Turn my raw notes into a clear summary. This is a DRAFT for engineer review before it is sent.

Input: [paste notes, inspection updates, overdue items list, incidents, RBI or study status, KPIs if any]. Period: [week / month]. Audience: [VP, asset manager, plant manager]. Length: [one page / half page].

Do this:
1. Write a 3-line headline: overall status, the biggest concern, the decision or support needed (if any).
2. Group content under: key findings, overdue or at-risk inspections, actions closed, actions opened, risks and concerns, decisions needed, next period plan.
3. Keep every number and date exactly as in my notes. Show the count and the source for each statistic.
4. Use plain language, short sentences, no jargon. Explain any technical term once.
5. Separate facts from judgement. Mark any statement that is my opinion or an assumption.
6. Provide a second, shorter version (5 bullet points) for a message or meeting slide.
7. List anything in my notes that is unclear, missing or contradictory before I send it.

Standards to apply: ISO 55000 asset management context, and the inspection codes (API 510, 570, 653) only when naming overdue inspection categories. Name the standards only. I will verify terms against company procedures.

Rules: do not invent numbers, dates, causes or status. Do not soften or hide a risk to make the message sound better. Write “not provided” for gaps. End with a reviewer checklist.

Act as an asset integrity engineer preparing a management presentation. Turn the report, data or notes I provide into a PowerPoint pack. This is a DRAFT for engineer review before it is presented.

Input: [attach report, Excel results, or paste notes]. Audience: [VP / asset manager / technical committee / audit]. Time slot: [minutes]. Decision needed from the audience: [..]. Company template: [attached or none].

Do this:
1. Propose a storyline: one headline message, then slides in order. Use the structure: situation, finding, risk, options, recommendation, decision needed, next steps. Keep to [number] slides plus an appendix.
2. For each slide give: a title that states the message (not a topic label), 3 bullets maximum, the chart or table to show (type, X and Y, units, source), speaker notes of 3 to 5 sentences, and the source for every number.
3. Make a one-slide executive summary with the decision needed at the top.
4. Put detail (data tables, method, assumptions, full results) in the appendix, not in the main slides.
5. Add a “Questions you may be asked” slide with short, evidence-based answers.
6. If I ask for a file, write python-pptx code that builds the deck from your outline (title and content layouts, native charts, speaker notes, slide numbers). Say which fonts and colours you used so I can match the company template.

Standards to apply: name the standards behind the source analysis only (for example API 510, 570, 653, 580, 581, ISO 55000). Do not add new technical claims to the slides. Flag clauses and editions for me to verify.

Rules: keep every number, date and conclusion exactly as in my source. Do not invent data, trends or risk statements. Do not soften or hide a risk. Mark any judgement as “engineer view”. Write “not provided” for gaps. End with a reviewer checklist, including checking every number against the source.

Act as an asset integrity engineer writing to senior management. Draft the email(s) I need from the notes I provide. This is a DRAFT for engineer review. I will edit and send it myself.

Input: [paste notes, findings, study results, or attach report]. Email type: [status update / escalation of a risk / request for budget or shutdown window / request for decision / study results / overdue inspection notice]. Recipient: [role]. Tone: [neutral / urgent / formal]. My name and role: [..].

Do this:
1. Write the email with: a subject line that states the action or topic, a first sentence that gives the bottom line, 3 to 5 short supporting points, the specific decision or action requested with a proposed date, and a closing line.
2. Keep it under [150] words. Use plain language and explain any technical term once.
3. Give three versions: (a) concise, (b) detailed with a short evidence list, (c) a 3-line message for chat or phone.
4. Separate facts from judgement. Mark any assumption or opinion.
5. State the consequence of no action only if my notes support it. Do not exaggerate.
6. List what is unclear, missing or contradictory in my notes before I send.
7. Optionally list attachments I should add (chart, table, report extract).

Standards to apply: mention a standard or code only if it directly supports the request (for example the inspection interval in API 510, 570 or 653). Name it only. I will verify the clause and the company procedure.

Rules: do not invent numbers, dates, findings or deadlines. Do not name a person at fault. Do not soften a risk to make the message easier. Write “not provided” for gaps. End with a reviewer checklist.

Act as an engineering data analyst. Produce clear charts and graphs from the data I provide, with code I can rerun. This is a DRAFT for engineer review.

Input: [attach Excel/CSV or paste data]. Charts needed: [for example thickness trend per CML, corrosion rate by circuit, remaining life ranking, inspection status, overdue by month, risk matrix counts, Pareto of failures]. Audience: [engineers / management]. Output: [PNG / embedded in Excel / slides].

Do this:
1. Profile the data first: columns, units, date range, missing values. Tell me what you cannot chart and why.
2. Pick the right chart for each question and say why (line for trend, bar for ranking, scatter for correlation, histogram for distribution, box plot for spread, heat map for matrix counts). Avoid 3D, pie charts with many slices, and dual axes unless I ask.
3. Make each chart readable: title that states the message, axis labels with units, legend only if needed, readable fonts, colour-blind safe palette, data source and date in a footnote, minimum thickness or limit line only if I supply the value.
4. Write complete, commented Python code (pandas, matplotlib) that loads my file, cleans dates and units on a copy, builds each chart, and saves it. Use clear variable names and put file paths at the top.
5. Also give the Excel route for each chart: the formulas or pivot steps, and the chart type to insert.
6. Run the code if you can and show the charts. If you cannot run it, say “not executed” and list what to check on first run.
7. For each chart give a one-line takeaway and one caution about what it does not show.

Standards to apply: ASTM G16 for corrosion data presentation and statistics, ISO 16269 for statistical presentation of data, and API 510, 570 or 653 only to label inspection categories. Name the standards only. Flag clauses and editions for me to verify.

Rules: do not smooth, drop or “fix” outliers silently. Show them and flag them. Do not extrapolate beyond the data unless I ask, and then label it as an extrapolation. Do not invent values or limits. Write “not provided” for gaps. End with a reviewer checklist.

Act as a corrosion and inspection data analyst. Run statistics on the thickness and corrosion data I provide. This is a DRAFT for engineer review. Screening statistics only, not an approved remaining-life assessment.

Input: [attach Excel/CSV: asset, CML, date, thickness, units]. Grouping: [by circuit / by material / by damage mechanism / by asset]. Required thickness and limits: [I supply them, or none].

Do this:
1. Check the data first: units, duplicates, dates, missing values, thickness gains. List what you excluded or flagged and why. Never delete raw data.
2. Calculate per CML: short-term and long-term corrosion rates, and the governing rate. Show the formulas and one worked example.
3. Summarise per group: count, mean, median, standard deviation, minimum, maximum, percentiles (50th, 90th, 95th), and a histogram.
4. Fit a linear regression of thickness against time for CMLs with enough points. Report slope, intercept, R squared, the number of points, and the confidence interval of the slope. Do not fit when fewer than 3 points. Say so.
5. Flag outliers using a stated method (for example the interquartile range rule or a formal test from ASTM E178). Show them. Do not remove them without my approval.
6. For localised corrosion or pitting, show how an extreme value method (such as the Gumbel distribution described in ASTM G16) could be applied, only if I supply enough maximum-depth data. State the assumptions.
7. Give a remaining-life range per CML using only the required thickness I supplied, with the rate range (low, expected, high). Show the units.
8. Write complete, commented Python code (pandas, numpy, scipy, statsmodels) that reproduces every number. Run it if you can. If not, say “not executed”, and mark all results as pending.
9. Output: cleaned-data log, results tables, charts, a short written summary, and a list of limits of the analysis (sample size, measurement error, spacing of dates, UT tool uncertainty).

Standards to apply: ASTM G16 for corrosion data statistics, ASTM E178 for outliers, ASTM E2586 for basic statistics, and API 510, 570 or 653 for rates and remaining life. Name the standards only. Flag clauses and editions for me to verify.

Rules: use only values I supply for required thickness and measurement uncertainty. Do not invent data. Do not report a statistic if the sample is too small. Say “insufficient data”. Do not calculate by hand when code can do it. Write “not provided” for gaps. End with a reviewer checklist.

Act as a reliability engineer. Analyse the failure and maintenance data I provide with standard reliability statistics. This is a DRAFT for engineer review.

Input: [attach failure dates, run times or hours between failures, equipment tags, failure modes, censored data (units still running, removed or not failed), CMMS export]. Equipment group: [pumps / valves / exchangers / other]. Question to answer: [MTBF / is it wearing out / which failures matter most / maintenance interval].

Do this:
1. Prepare the data: define time to failure (hours, days or cycles), identify censored (suspended) units, separate failure modes, and flag units with too little history. List all exclusions and reasons.
2. Pareto analysis: rank failure modes, equipment or causes by count, downtime or cost, with a cumulative percentage chart. Say which measure was used.
3. MTBF and failure rate: calculate with the formulas shown. State the assumption of a constant failure rate and warn if the data does not support it. Include repairable versus non-repairable treatment and say which one applies.
4. Weibull analysis: fit shape (beta) and scale (eta), by maximum likelihood or median-rank regression (state which), include censored data, give confidence bounds, goodness-of-fit and a Weibull probability plot. Interpret beta: below 1 early life, about 1 random, above 1 wear-out. State the limits when there are fewer than about 10 failures.
5. For repairable systems, show a cumulative failure plot or a trend test to check whether failures are getting more frequent.
6. Suggest what the results might mean for maintenance strategy for the engineer to decide. Do not set intervals or a replacement policy unless I supply the cost and consequence data.
7. Write complete, commented Python code (pandas, numpy, scipy, matplotlib, and lifelines or reliability if available) that reproduces every number and chart. Run it if you can. If not, say “not executed”, and mark all results as pending.
8. Output: data-preparation log, Pareto chart and table, MTBF table, Weibull results and plot, trend result, limits of the analysis, short summary for management.

Standards to apply: IEC 61649 for Weibull analysis, ISO 14224 for failure data taxonomy and collection, and IEC 60300-3-1 for dependability analysis methods where relevant. Name the standards only. Flag clauses and editions for me to verify.

Rules: do not invent failure data or fill missing run times. Do not ignore censored data. Do not claim a distribution fits without a goodness-of-fit result. Do not give a precise life from a tiny sample. Write “not provided” for gaps. End with a reviewer checklist.