Study Guide: Alex for Engineers (Electrical, Mechanical, Civil, Process)
Your personal reference for applying Alex to professional engineering work. Ready-to-run prompts, domain use cases, and a practice progression built for non-software engineering disciplines.
What This Guide Is Not
This is not a habit formation guide (see Self-Study Guide for that). This is a domain use-case library — the specific things Alex can do in your engineering practice, and how to do them well.
Core Principle for Engineers
Engineering work lives or dies on precision, accountability, and traceability. Alex is most valuable when it helps you document, structure, and communicate engineering decisions — not when you ask it to make those decisions.
Critical caveats for engineering use (non-negotiable):
- Alex cannot verify calculations. Do not use Alex-generated numbers in any design without independent verification.
- Alex does not have access to proprietary standards (ASME, IEC, IEEE behind paywalls). It reasons from public training data and will sometimes misquote clause numbers or requirements.
- Alex cannot sign off on safety-critical decisions. The engineer of record is always a human.
- Always verify any standard reference Alex provides before including it in a design document.
What Alex is excellent at: structuring design justification documents, preparing review materials, translating technical content for clients or management, identifying potential failure modes to think through, and scaffolding documentation that would otherwise take hours to organize from a blank page.
The Five Use Cases
1. Design Decision Documentation and Justification
When to use: After making a significant design decision and needing to document it for a project record, internal review, or regulator.
Prompt pattern:
I'm an [electrical/mechanical/civil/process] engineer.
I need to document a design decision for [project or system].
The decision: [describe it plainly].
Standards applicable: [ASME B31.3 / IEC 61511 / IEEE 1584 / AS/NZS XXXX — as relevant].
Structure this as:
1. Design basis and objective
2. Options considered
3. Selected approach and rationale
4. Code compliance notes
5. Limitations and assumptions
Follow-up prompts:
Add a section on what failure modes this design addresses and which ones it does not.
What would a peer reviewer or third-party auditor most likely question in this document?
Rewrite sections 1 and 3 for a client summary — non-technical language, one page.
2. Design Review Preparation
When to use: Preparing a hazard review (HAZOP, SIL, LOPA), internal design review, or client gate review.
Prompt pattern:
I'm preparing for a [HAZOP / SIL assessment / internal design review / client review] on [system or project].
The system is: [brief description].
Help me prepare a checklist of the most likely issues that come up in this type of review,
organized by: process safety concerns, code compliance gaps, design assumptions to challenge,
and documentation completeness.
Follow-up prompts:
Play the role of a skeptical safety engineer reviewing this system. What are the top three things
you'd flag as inadequately justified?
What questions should I ask the client before the review to avoid surprises?
3. Failure Mode and Root Cause Analysis
When to use: After an anomaly, incident, or near-miss; or proactively identifying failure risks before commissioning.
Prompt pattern:
I'm analyzing a failure in [equipment or system type].
What happened: [describe observed failure or symptom].
Operating conditions at time of failure: [describe if known].
Help me structure a root cause analysis covering:
- Possible immediate causes
- Possible contributing factors (design / maintenance / process / human factors)
- What additional information I need to determine root cause
- Interim mitigation while root cause is investigated
Follow-up prompts:
What's the most commonly overlooked contributing factor in [this type of failure]?
Draft a preliminary incident notification for management — factual, no speculation, no admission of fault.
4. Client and Stakeholder Communication
When to use: Writing technical reports, presentations, or explanations for clients, management, or non-technical stakeholders who need to understand engineering decisions without the full technical depth.
Prompt pattern:
I need to explain [technical decision or situation] to [client / management / regulator]
who has [describe their technical background briefly].
The key message I need them to walk away with is: [state it].
Tone: [professional/plain language/formal].
Format: [executive summary / email / presentation talking points].
Follow-up prompts:
What questions will they likely ask that I should prepare for?
Where might they misunderstand this explanation? Add a clarification for each likely confusion point.
5. Engineering Document Scaffolding
When to use: Whenever you need to produce a structured engineering deliverable and want to build the skeleton before writing — specification, method statement, commissioning plan, maintenance procedure.
Prompt pattern:
I need to write a [document type: specification / method statement / commissioning plan / maintenance procedure]
for [equipment or system].
The document is for: [purpose and audience].
Key requirements the document must cover: [list the main topics].
Draft a structured template with section headings and a one-sentence scope statement for each section.
Follow-up prompts:
What sections am I missing that are typically required for this document type?
Write section [X] — here are the key points: [list them].
Flag any sections where I'll need to insert project-specific data placeholders.
Your First Week Back: Practice Plan
| Day | Task | Time |
|---|---|---|
| Day 1 | Use the Design Decision Documentation pattern on a recent or current design choice | 25 min |
| Day 2 | Use the Stakeholder Communication pattern to rewrite a technical explanation you’ve given recently | 20 min |
| Day 3 | Run the Design Review Preparation prompt for an upcoming review | 20 min |
| Day 4 | Try the Document Scaffolding pattern on a document type you find slow to start | 20 min |
| Day 5 | Save your three most useful prompts from the week using /saveinsight | 10 min |
Month 2–3: Advanced Applications
Project Knowledge Base When you’re deep in a project, spend 5 minutes at the end of each significant day briefing Alex on what was decided and why. This creates a searchable project memory.
Project update for [project name]: Today we [what happened].
Key decisions made: [list].
Outstanding questions: [list].
Save this as a project note.
Standards Interpretation Support When working through a new or unfamiliar standard, use Alex to build your initial understanding before diving into the document itself:
I'm working with [standard] for the first time on [application].
Give me a plain-language overview of: what it covers, what it requires at a high level,
and where the most common interpretation issues arise.
Note: I'll verify all specifics against the actual standard.
Cross-Discipline Coordination On multi-discipline projects, use Alex to anticipate interface clashes before they happen in the field:
I'm the [electrical/mechanical/civil] discipline lead on [project type].
The [other discipline] team is responsible for [their scope].
What are the typical interface issues between these disciplines on this type of project,
and what documents or drawings should we align on before [project phase]?
Continue your practice: Self-Study Guide — the 30/60/90-day habit guide.