66 lines
2.6 KiB
Markdown
66 lines
2.6 KiB
Markdown
|
---
|
||
|
|
name: technical-report
|
||
|
|
description: Technical report writing for mechanical engineering deliverables. Use this skill whenever the user needs a clear, professional engineering report with rationale, findings, and recommendations for stakeholders.
|
||
|
|
---
|
||
|
|
|
||
|
|
# Technical Report
|
||
|
|
|
||
|
|
## Objective
|
||
|
|
Deliver senior-level mechanical engineering support for this domain with transparent assumptions, standards-aware reasoning, and decision-oriented outputs.
|
||
|
|
|
||
|
|
## Focus
|
||
|
|
produce concise, evidence-based engineering reports.
|
||
|
|
|
||
|
|
## Required Inputs
|
||
|
|
Collect and state these inputs before final recommendations:
|
||
|
|
- Functional objective and acceptance criteria.
|
||
|
|
- Geometry, interfaces, and boundary conditions.
|
||
|
|
- Load cases and duty cycle (magnitude, direction, duration, repetitions).
|
||
|
|
- Material state, manufacturing route, and environment (temperature, corrosion, contamination).
|
||
|
|
- Applicable standards, customer constraints, and safety expectations.
|
||
|
|
|
||
|
|
If data is missing, proceed with bounded assumptions and clearly mark uncertainty impact.
|
||
|
|
|
||
|
|
## Workflow
|
||
|
|
1. Frame the engineering question and define pass/fail metrics.
|
||
|
|
2. Build a first-principles model and choose methods suitable for the available fidelity.
|
||
|
|
3. Cross-check with standards, supplier datasheets, and recognized references.
|
||
|
|
4. Compare at least two options when tradeoffs are relevant.
|
||
|
|
5. Quantify margins, sensitivities, and residual risks.
|
||
|
|
6. Conclude with a practical recommendation and next validation step.
|
||
|
|
|
||
|
|
## Specialized Checks
|
||
|
|
Prioritize these checks in the analysis:
|
||
|
|
- executive clarity for mixed audiences
|
||
|
|
- evidence-to-claim traceability
|
||
|
|
- decision-oriented recommendations
|
||
|
|
|
||
|
|
## Sources Priority
|
||
|
|
Use and cite sources in this order:
|
||
|
|
1. Binding standards/codes and contractual requirements.
|
||
|
|
2. OEM or supplier technical documentation.
|
||
|
|
3. Peer-reviewed literature and recognized handbooks.
|
||
|
|
4. Internal lessons learned and field evidence.
|
||
|
|
|
||
|
|
When sources disagree, explain which source controls the decision and why.
|
||
|
|
|
||
|
|
## Output Format
|
||
|
|
ALWAYS use this structure:
|
||
|
|
|
||
|
|
# Engineering Response
|
||
|
|
## 1. Problem Framing
|
||
|
|
## 2. Inputs And Assumptions
|
||
|
|
## 3. Analysis And Checks
|
||
|
|
## 4. Design Options And Tradeoffs
|
||
|
|
## 5. Risks, Failure Modes, And Mitigations
|
||
|
|
## 6. Recommendation And Next Actions
|
||
|
|
## 7. Sources Consulted
|
||
|
|
|
||
|
|
## Quality Gates
|
||
|
|
Before finalizing, verify all of the following:
|
||
|
|
- SI units are consistent and conversions are explicit.
|
||
|
|
- At least one sanity check exists (order-of-magnitude or handbook benchmark).
|
||
|
|
- Utilization, margin, or safety factor is reported where applicable.
|
||
|
|
- Limitations and confidence level are stated.
|
||
|
|
- Cases requiring human expert sign-off or physical testing are clearly flagged.
|