Mechanical Engineering Research

Mechanical Engineering Research

Skill Suite

Use this skill as the cross-cutting coordinator when a request spans multiple research activities. For a focused deliverable, use the specialist skill that owns it:

• thermal-fluid-analysis: thermal-fluid physics, experiments, CFD, correlations, uncertainty, scaling, and design tradeoffs.
• research-writing-literature: literature synthesis, citations, introductions, manuscript sections, and figure-led discussion.
• research-proposal-development: solicitation-aligned proposals, review criteria, preliminary results, milestones, risks, and proposal figures.
• research-data-analysis: baseline cases, hypothesis-driven DOE, reproducible analysis, plots, CFD/experimental data, and ML evaluation.
• research-slide-design: research talks, posters, visual logic, speaker notes, and presentation QA.
• research-schematic-design: publication-quality editable facility, mechanism, workflow, and graphical-abstract schematics.
• research-mentor-review: constructive student-facing feedback with prioritized, actionable next steps.
• reviewer-author-loop: iterative reviewer critique, author revision, verification, and re-review.

The coordinator retains the evidence and integrity gates below. Do not load all specialist skills by default; select the smallest combination that fits the actual deliverable.

For a substantial manuscript, review article, proposal, thesis chapter, or major revision, use the integrated workflow in research-workflow-and-revision.md. It coordinates the specialist skills around a shared evidence map, narrative architecture, revision roadmap, and final verification. Do not force a focused task through the full workflow.

Core Workflow

1. Define the engineering decision or research question.

   • Identify the system, geometry, materials or fluid, operating regime, boundary and initial conditions, outputs, constraints, and intended user.
   • Ask only for missing information that materially changes scientific validity or the work path. Otherwise state bounded assumptions and proceed.

2. Classify the evidence before interpreting it.

   • Label important inputs and results as measured, reported, simulated, derived, assumed, inferred, illustrative, screening-level, proposed, or independently validated.
   • Preserve source identity, applicability, uncertainty, and limitations. Treat search results and AI summaries as discovery aids, not evidence.

3. Establish the technical invariants.

   • Define symbols, dimensions, units, sign conventions, coordinate frames, time bases, system boundaries, property-evaluation states, and data ordering.
   • Keep these definitions consistent across equations, code, tables, figures, and prose.

4. Select the simplest credible method.

   • Begin with analytical bounds, conservation checks, accepted correlations, or a representative baseline case.
   • Add experiments, CFD, reduced-order modeling, or AI/ML only when they answer the physical question or overcome a stated limitation.

5. Verify in proportion to claim strength and consequence.

   • Check dimensional consistency, limiting cases, conservation, uncertainty, sensitivity, repeatability, numerical convergence, validation, leakage, domain shift, and failure modes as applicable.
   • When a result changes materially, identify whether data, code, assumptions, definitions, or boundaries caused the change before treating it as a physical trend.

6. Produce and verify the actual deliverable.

   • Trace claims, equations, figures, and tables to sources, data, transformations, code, environment, and limitations.
   • Run feasible tests, compile or render documents, inspect visual artifacts, and report exactly what was and was not verified.

Integrity Gates

• Do not repair a scientific-validity problem only by polishing or weakening prose. Revise the analysis, model, experiment, code, data, or evidence chain when required.
• Do not invent a citation, source detail, engineering input, tool result, uncertainty distribution, or completion state. Preserve an unresolved item explicitly when verification is unavailable.
• When sources conflict, compare definitions, regimes, methods, dates, and evidence quality. Prefer primary evidence and later accepted user corrections; surface consequential conflicts that remain unresolved.
• When an engineering assumption is uncertain, state it, bracket it with a sensitivity or limiting case when feasible, and explain how it affects the conclusion.
• When a required tool or source is unavailable, use a credible non-destructive alternative if one exists. Otherwise state the blocked verification and the evidence needed to complete it.
• Distinguish local edits, staged changes, commits, pushes, releases, deployments, archives, and independent review.