ChatGPT Prompts for Engineers

Write a technical design document for an engineering project.

Project details:
- System/feature name: [name]
- Problem statement: [what problem does this solve?]
- Scope: [what's included and what's explicitly excluded]
- Constraints: [budget, timeline, regulatory, physical, performance]
- Target environment: [where this will operate — production line, data center, field deployment, etc.]

Generate a design document with:
1. **Executive summary**: 3-sentence overview a VP could read and understand the what/why/how
2. **Background and motivation**: Why this design is needed, what's broken or missing today
3. **Proposed solution**: Detailed technical approach with diagrams described in text (block diagrams, data flow, system architecture)
4. **Design alternatives considered**: At least 2 alternatives with pros/cons and why they were rejected
5. **Technical specifications**: Key parameters, tolerances, materials, protocols, or interfaces
6. **Dependencies and interfaces**: What other systems, teams, or components this interacts with
7. **Risk analysis**: Technical risks with severity, likelihood, and mitigation strategies
8. **Testing and validation plan**: How we'll verify this design meets requirements
9. **Timeline and milestones**: Phased delivery with decision gates
10. **Open questions**: Unresolved items that need input from reviewers

Format for Confluence or Google Docs. Use tables for specifications and comparisons.

Perform a structured root cause analysis using the 5 Whys method.

Incident/failure details:
- What happened: [describe the failure, defect, or incident]
- When it happened: [date, time, phase of operation]
- Where it happened: [location, system, component]
- Impact: [downtime, cost, safety implications, customer impact]
- Immediate corrective action taken: [what was done to stop the bleeding]

Conduct the analysis:
1. **Problem statement**: Restate the problem in precise, measurable terms (not "it broke" — specify what failed, how it manifested, and the deviation from expected behavior)
2. **5 Whys chain**: Walk through each level of "why" with evidence or data supporting each answer. Branch the analysis if multiple root causes converge.
3. **Contributing factors**: Identify systemic issues beyond the immediate cause — process gaps, training gaps, design weaknesses, environmental factors
4. **Root cause classification**: Categorize as design, manufacturing, material, human error, process, or maintenance-related
5. **Corrective actions**: For each root cause, propose:
   - Immediate fix (containment)
   - Short-term corrective action (prevent recurrence)
   - Long-term preventive action (systemic improvement)
6. **Verification plan**: How will we confirm the corrective actions actually work?
7. **Lessons learned**: What should be documented and shared across the organization?

Format as a formal RCA report suitable for quality management review.

Create a comprehensive design review checklist for an engineering design.

Design details:
- Type of design: [mechanical / electrical / software / civil / chemical / systems]
- Design phase: [conceptual / preliminary / detailed / final]
- Industry: [aerospace, automotive, medical device, consumer electronics, construction, etc.]
- Applicable standards: [ISO, ASME, IEEE, IEC, etc. — list any known ones]

Generate a review checklist organized by:

1. **Requirements compliance**: Does the design meet every stated requirement? Create a requirements traceability matrix template.
2. **Performance**: Will it meet performance specifications under all operating conditions (normal, edge cases, degraded)?
3. **Reliability and durability**: Fatigue life, wear, corrosion, thermal cycling, MTBF estimates
4. **Manufacturability**: Can this actually be built? Tolerances achievable? Assembly sequence logical?
5. **Maintainability and serviceability**: Can it be inspected, repaired, and replaced in the field?
6. **Safety and regulatory**: FMEA completed? Standards compliance? Hazard analysis?
7. **Interfaces**: Do all interfaces (mechanical, electrical, data, thermal) between subsystems align?
8. **Cost**: Bill of materials realistic? Manufacturing cost estimated? Total cost of ownership considered?
9. **Testing and verification**: Is there a test plan that exercises all requirements?
10. **Documentation completeness**: Drawings, specs, BOMs, test procedures — is everything accounted for?

For each item, include: Check (Y/N/NA) | Finding | Severity (Critical/Major/Minor) | Action Required.

Draft an engineering requirements specification document.

Product/system: [name]
Purpose: [what it does and why it's needed]
End users: [who will use or interact with this system]
Operating environment: [temperature range, humidity, vibration, EMI, outdoor/indoor, etc.]
Regulatory context: [any industry regulations, certifications needed]

Generate a requirements specification with:
1. **Functional requirements**: What the system must DO — each requirement with a unique ID (REQ-FUNC-001), description, rationale, verification method (test/analysis/inspection/demonstration), and priority (shall/should/may)
2. **Performance requirements**: Quantitative specs — speed, throughput, accuracy, resolution, response time, capacity. Every number needs units and tolerances.
3. **Environmental requirements**: Operating temperature, storage conditions, ingress protection (IP rating), shock and vibration, altitude, humidity
4. **Interface requirements**: Mechanical connections, electrical interfaces (voltage, current, protocols), data formats, communication standards
5. **Reliability requirements**: MTBF, design life, duty cycle, warranty period assumptions
6. **Safety requirements**: Fault tolerance, fail-safe modes, emergency shutdown, protective features
7. **Regulatory and compliance requirements**: Standards, certifications, testing agency requirements
8. **Constraints**: Size, weight, power, cost targets, technology restrictions
9. **Verification matrix**: Requirements vs. verification method crosswalk

Use the SHALL/SHOULD/MAY convention. Every requirement must be testable — if you can't write a test for it, rewrite it until you can.

Conduct a Failure Mode and Effects Analysis (FMEA) for a system or component.

System/component: [name and brief description]
Function: [what it's supposed to do]
Operating conditions: [normal use, extreme use, environmental stressors]
Safety criticality: [how critical is this — life-safety, mission-critical, convenience?]
Existing controls: [current detection or prevention mechanisms, if any]

For each identified failure mode, fill out the FMEA table:
| Item/Function | Potential Failure Mode | Potential Effect(s) | Severity (1-10) | Potential Cause(s) | Occurrence (1-10) | Current Controls | Detection (1-10) | RPN | Recommended Action | Responsible | Target Date |

Analyze at least 10 failure modes across:
- **Structural failures**: Fracture, fatigue, deformation, corrosion, wear
- **Functional failures**: Loss of function, degraded performance, intermittent operation
- **Interface failures**: Misalignment, incompatible signals, loose connections
- **Environmental failures**: Overheating, moisture ingress, contamination, vibration damage
- **Human-induced failures**: Misuse, incorrect assembly, improper maintenance

After the table:
1. **Top 5 failure modes by RPN**: These need immediate attention
2. **Detection gap analysis**: Where are we relying on luck instead of engineered detection?
3. **Recommended design changes**: Specific modifications to reduce top risk items
4. **Testing recommendations**: Tests that should be added to the verification plan

Use standard AIAG/SAE J1739 severity, occurrence, and detection scales.

Create an engineering project risk register.

Project: [name and description]
Phase: [design / prototyping / testing / production ramp / deployment]
Timeline: [start to end, key milestones]
Team: [size, key roles, any gaps]
Budget: [total budget and contingency percentage]
Critical path items: [list the items where delay means project delay]

Identify and assess risks across:
1. **Technical risks**: Unproven technology, integration challenges, performance uncertainty, scaling issues
2. **Schedule risks**: Long-lead items, approval bottlenecks, test facility availability, vendor lead times
3. **Resource risks**: Key person dependencies, skill gaps, equipment availability, competing priorities
4. **Supply chain risks**: Sole-source components, material availability, geopolitical disruptions, cost volatility
5. **Quality risks**: Reliability unknowns, manufacturing yield, first-article inspection failures
6. **Regulatory risks**: Certification timeline, standard changes, testing requirements

For each risk:
| ID | Risk Description | Category | Probability (1-5) | Impact (1-5) | Risk Score | Trigger Event | Mitigation Plan | Contingency Plan | Owner | Status |

Then provide:
- **Risk heat map**: Plot all risks on a probability vs. impact grid (use text table)
- **Top 5 risks requiring management attention**: With recommended actions and deadlines
- **Risk burn-down approach**: How to retire risks as the project progresses through phases
- **Monthly review template**: What to update each review cycle

Help me create a technical presentation for non-technical stakeholders.

Technical topic: [what you need to present — system design, test results, project status, failure analysis, etc.]
Audience: [executives, clients, investors, cross-functional team, regulatory body]
Their technical level: [none / basic / moderate]
What they care about: [cost, timeline, risk, performance, compliance, ROI]
Decision needed: [what you want them to approve, fund, or understand]
Time slot: [X minutes, including Q&A]

Create a presentation outline:
1. **Opening hook** (1 slide): Start with the business problem or outcome, NOT the technical details. One sentence that makes them care.
2. **Context slide** (1 slide): Where we are in the project/timeline. Visual timeline or progress bar.
3. **Key findings or proposal** (2-3 slides): The core message translated into business language. Use analogies for complex concepts. One key metric per slide.
4. **Risk and trade-offs** (1 slide): What could go wrong and what you're doing about it. Frame as business impact, not technical detail.
5. **Recommendation** (1 slide): Clear, specific ask. "We recommend X because Y, and it will cost Z."
6. **Backup slides** (3-5 slides): Technical details for Q&A only. Data tables, test results, calculations — ready but not in the main flow.

For each main slide, provide:
- The key message (one sentence)
- Talking points (what to say, not what to put on the slide)
- Anticipated questions and prepared answers
- What visual to use (chart type, diagram, photo)

Also include: 3 common mistakes engineers make when presenting to executives, and how to avoid them.

Help me set up and verify engineering calculations.

Calculation context:
- What I'm calculating: [describe the problem — stress analysis, heat transfer, fluid flow, electrical load, structural capacity, etc.]
- Known values: [list all inputs with units]
- Required outputs: [what do I need to find, with required units]
- Applicable standards or codes: [if any govern the calculation method]
- Safety factor required: [if applicable]

Perform the following:
1. **State the governing equations**: Write out the formulas being used, with variable definitions and units for each term
2. **Unit consistency check**: Verify all inputs are in compatible units. Flag any conversions needed and show the conversion factors used.
3. **Step-by-step calculation**: Show each step with intermediate results. Keep units attached to every number throughout.
4. **Sanity check**: Does the result make physical sense? Compare against:
   - Order-of-magnitude estimate
   - Known benchmarks or reference values
   - Physical intuition (is the beam deflection bigger than the beam? Red flag.)
5. **Sensitivity analysis**: Which input has the biggest effect on the result? If [X] changes by +/-10%, how much does the output change?
6. **Margin summary**: How much margin exists against the limit/requirement? Express as both absolute and percentage.
7. **Assumptions and limitations**: What simplifications were made and when do they break down?

Present in a format suitable for a calculation package that could be reviewed by another engineer or submitted to a regulatory body.

Create a comprehensive test plan for an engineering product or system.

System under test: [name and description]
Test phase: [development / qualification / acceptance / production / field validation]
Requirements document: [reference the requirements spec this traces to]
Test environment: [lab, prototype, production unit, simulation, field conditions]
Constraints: [budget, timeline, available equipment, sample size limitations]

Generate a test plan with:
1. **Test objectives**: What are we trying to prove? Link each objective to specific requirements.
2. **Test matrix**:
   | Test ID | Requirement Traced | Test Description | Test Type (functional/environmental/stress/life) | Pass Criteria | Sample Size | Duration | Equipment Needed |
3. **Test sequence**: Order matters — which tests should run first (non-destructive before destructive, functional before environmental)
4. **Test procedures**: For the top 5 most critical tests, write step-by-step procedures:
   - Setup and configuration
   - Pre-test measurements and calibration
   - Test execution steps
   - Data collection points and methods
   - Pass/fail criteria (quantitative, not subjective)
   - Post-test inspection requirements
5. **Environmental test conditions**: If applicable — temperature cycling profile, vibration spectrum, humidity levels, with hold times and ramp rates
6. **Data management**: What data to collect, format, storage, analysis methods
7. **Failure handling**: What happens when a test fails? Disposition process, retest criteria, root cause investigation trigger
8. **Schedule and resources**: Test sequence timeline, equipment booking, personnel assignments
9. **Risk register**: What could go wrong with the testing itself (equipment failure, invalid results, insufficient samples)

Append a test readiness review checklist: everything that must be confirmed before testing begins.

Create a quick-reference guide for engineering standards applicable to my work.

Engineering domain: [mechanical / electrical / software / civil / chemical / aerospace / biomedical]
Product type: [describe what you're designing or building]
Markets: [where will it be sold or deployed — US, EU, global]
Safety classification: [is this safety-critical? medical device class? SIL level?]
Current standards I'm already using: [list any you know about]

Generate:
1. **Primary standards**: The core standards that govern this type of product. For each:
   - Standard number and title
   - What it covers (scope summary in plain English)
   - Why it matters (regulatory requirement vs. industry best practice)
   - Current version/year
   - Key clauses that are most frequently referenced
2. **Testing standards**: Standards that define HOW to test (e.g., IEC 60068 for environmental, ASTM for materials)
3. **Quality and process standards**: ISO 9001, AS9100, IATF 16949, etc. — which apply and why
4. **Regional requirements**: CE marking, UL listing, FCC, RoHS, REACH — what's required for each target market
5. **Industry-specific standards**: Standards unique to this domain that a generalist might miss
6. **Standards roadmap**: Known upcoming changes or new editions in development that could affect design decisions made today
7. **Compliance checklist**: A concise checklist of what needs to be done to demonstrate compliance with the top 5 most critical standards

Present as a reference table that an engineer can pin to their desk or bookmark.

Help me research prior art for a potential patent application.

Invention description:
- What it does: [functional description]
- How it works: [technical mechanism or method]
- What's novel: [what specifically is new compared to existing solutions]
- Problem it solves: [the engineering challenge being addressed]
- Field of technology: [domain — e.g., heat exchangers, sensor fusion, battery management]

Help me prepare a prior art research strategy:
1. **Key terms and synonyms**: Generate a comprehensive list of search terms, including:
   - Technical synonyms (what else could this be called?)
   - Functional equivalents (what other approaches solve the same problem?)
   - Component-level terms (subassemblies, materials, methods)
2. **Patent classification codes**: Suggest relevant CPC and IPC classification codes to search
3. **Search queries**: Write 5-7 structured search queries optimized for Google Patents, USPTO, and Espacenet
4. **Non-patent literature sources**: Journals, conference proceedings, technical reports, and standards that might contain relevant prior art
5. **Landscape analysis framework**: How to organize and compare found references against the invention's key claims
6. **Novelty assessment template**: For each reference found, evaluate:
   | Reference | What it discloses | What it doesn't disclose | Relevance to our claims | Gap analysis |
7. **Claim differentiation strategy**: Based on common prior art patterns in this field, suggest how to position claims to maximize allowable scope

Note: This is for research preparation, not legal advice. A patent attorney should review all findings.

Generate technical interview questions for an engineering role.

Role details:
- Position: [job title — e.g., Senior Mechanical Engineer, Embedded Systems Engineer, Civil Structural Engineer]
- Seniority level: [junior / mid / senior / principal / staff]
- Domain: [specific engineering discipline]
- Key skills needed: [list 3-5 must-have technical skills]
- Team context: [what the team works on, what projects they'll join]
- Interview duration: [X minutes]

Generate questions across these categories:

1. **Fundamentals** (3 questions): Core engineering principles the candidate must know. Include expected answer depth for this seniority level.
2. **Design thinking** (2 questions): Open-ended design problems with no single right answer. Describe what good, great, and exceptional answers look like.
3. **Problem-solving** (2 questions): Troubleshooting scenarios based on real-world failure modes. The answer should demonstrate systematic debugging methodology, not just knowledge.
4. **Domain expertise** (2 questions): Deep-dive questions specific to the required skills. Include follow-up questions that probe beyond surface knowledge.
5. **Communication** (1 question): Ask them to explain a complex concept to a non-technical audience. Evaluate clarity and ability to calibrate to the audience.
6. **Judgment calls** (2 questions): Scenarios where engineering trade-offs must be made (performance vs. cost, speed vs. reliability, innovation vs. proven approach). No right answer — evaluate reasoning.

For each question provide:
- The question itself
- What you're evaluating (what does a good answer demonstrate?)
- Red flags (what answers suggest the candidate isn't at this level)
- Follow-up probes (how to dig deeper based on their initial answer)
- Time allocation (how long to spend on this question)

Also include: 3 behavioral questions specific to engineering culture (handling disagreements in design review, dealing with scope changes, communicating bad news about technical feasibility).