From 632f7a4c767fbcee1a6aeea84809e9359a3c9b5e Mon Sep 17 00:00:00 2001 From: Han Hu <72934230+hanhuark@users.noreply.github.com> Date: Thu, 28 May 2026 11:11:35 -0500 Subject: [PATCH 1/3] Add Thermal-Fluid Research Workflow plugin --- .agents/plugins/marketplace.json | 15 + README.md | 1 + plugins.json | 14 +- .../.codex-plugin/plugin.json | 42 +++ .../.codexignore | 9 + .../LICENSE | 21 ++ .../README.md | 314 ++++++++++++++++++ .../assets/icon.svg | 23 ++ .../mechanical-engineering-research/SKILL.md | 129 +++++++ .../agents/openai.yaml | 4 + .../references/ai-tools-thermal-fluids.md | 121 +++++++ .../references/brief-template.md | 63 ++++ .../innovation-commercialization.md | 114 +++++++ .../references/literature-review.md | 211 ++++++++++++ .../references/paper-writing-style.md | 214 ++++++++++++ .../references/presentation-slides.md | 204 ++++++++++++ .../references/proposal-development.md | 231 +++++++++++++ .../references/research-coding.md | 212 ++++++++++++ .../references/research-toolchain.md | 103 ++++++ .../references/technical-writing-analysis.md | 142 ++++++++ 20 files changed, 2185 insertions(+), 2 deletions(-) create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/.codex-plugin/plugin.json create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/.codexignore create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/LICENSE create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/README.md create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/assets/icon.svg create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/SKILL.md create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/agents/openai.yaml create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/ai-tools-thermal-fluids.md create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/brief-template.md create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/innovation-commercialization.md create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/literature-review.md create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/paper-writing-style.md create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/presentation-slides.md create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/proposal-development.md create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/research-coding.md create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/research-toolchain.md create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/technical-writing-analysis.md diff --git a/.agents/plugins/marketplace.json b/.agents/plugins/marketplace.json index e37b498f..8e127d92 100644 --- a/.agents/plugins/marketplace.json +++ b/.agents/plugins/marketplace.json @@ -1277,6 +1277,21 @@ "description": "OpenAI Codex plugin and local MCP server for turning task lists into realistic schedules with blocked dates, capacity overrides, overflow tracking, and markdown planning output.", "icon": "./plugins/6Delta9/task-scheduler-codex-plugin/assets/icon.png" }, + { + "name": "thermal-fluid-research-workflow", + "displayName": "Thermal-Fluid Research Workflow", + "source": { + "source": "local", + "path": "./plugins/hanhuark/mechanical-engineering-research-skill" + }, + "policy": { + "installation": "AVAILABLE", + "authentication": "ON_INSTALL" + }, + "category": "Tools & Integrations", + "description": "Thermal-fluid mechanical engineering research workflow for literature review, technical writing, data analysis, presentations, proposals, coding, and AI/ML tools.", + "icon": "./plugins/hanhuark/mechanical-engineering-research-skill/assets/icon.svg" + }, { "name": "tokrepo-search", "displayName": "TokRepo Search", diff --git a/README.md b/README.md index 10b242df..7055136b 100644 --- a/README.md +++ b/README.md @@ -224,6 +224,7 @@ Third-party plugins built by the community. [PRs welcome](#contributing)! - [sitemd](https://github.com/sitemd-cc/sitemd) - Build websites from Markdown via MCP — 22 tools for creating pages, generating content, validating, running SEO audits, configuring settings, and deploying static sites to Cloudflare Pages. - [Synta MCP](https://github.com/Synta-ai/n8n-mcp-codex-plugin-synta) - Build, edit, validate, and self-heal n8n workflows with Synta MCP tools and Codex-ready workflow guidance. - [Task Scheduler](https://github.com/6Delta9/task-scheduler-codex-plugin) - OpenAI Codex plugin and local MCP server for turning task lists into realistic schedules with blocked dates, capacity overrides, overflow tracking, and markdown planning output. +- [Thermal-Fluid Research Workflow](https://github.com/hanhuark/mechanical-engineering-research-skill) - Thermal-fluid mechanical engineering research workflow for literature review, technical writing, data analysis, presentations, proposals, coding, and AI/ML tools. - [TokRepo Search](https://github.com/henu-wang/tokrepo-codex-plugin) - Search and install AI assets from TokRepo with a bundled skill and MCP server for Codex. - [unslop](https://github.com/MohamedAbdallah-14/unslop) - Strip AI writing patterns from text output — removes filler phrases, hedging language, and generic constructs to produce cleaner written content. Install: `npm install -g unslop`. - [Upwork Autopilot](https://github.com/klajdikkolaj/upwork-autopilot) - Controlled Upwork job search, qualification, and proposal submission sessions through a dedicated Chrome profile. diff --git a/plugins.json b/plugins.json index 4697d7b5..d67c9407 100644 --- a/plugins.json +++ b/plugins.json @@ -2,8 +2,8 @@ "$schema": "https://json-schema.org/draft/2020-12/schema", "name": "awesome-codex-plugins", "version": "1.0.0", - "last_updated": "2026-05-27", - "total": 92, + "last_updated": "2026-05-28", + "total": 93, "categories": [ "Development & Workflow", "Tools & Integrations" @@ -879,6 +879,16 @@ "source": "awesome-codex-plugins", "install_url": "https://raw.githubusercontent.com/6Delta9/task-scheduler-codex-plugin/HEAD/.codex-plugin/plugin.json" }, + { + "name": "Thermal-Fluid Research Workflow", + "url": "https://github.com/hanhuark/mechanical-engineering-research-skill", + "owner": "hanhuark", + "repo": "mechanical-engineering-research-skill", + "description": "Thermal-fluid mechanical engineering research workflow for literature review, technical writing, data analysis, presentations, proposals, coding, and AI/ML tools.", + "category": "Tools & Integrations", + "source": "awesome-codex-plugins", + "install_url": "https://raw.githubusercontent.com/hanhuark/mechanical-engineering-research-skill/HEAD/.codex-plugin/plugin.json" + }, { "name": "TokRepo Search", "url": "https://github.com/henu-wang/tokrepo-codex-plugin", diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/.codex-plugin/plugin.json b/plugins/hanhuark/mechanical-engineering-research-skill/.codex-plugin/plugin.json new file mode 100644 index 00000000..6cb30463 --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/.codex-plugin/plugin.json @@ -0,0 +1,42 @@ +{ + "name": "thermal-fluid-research-workflow", + "version": "0.1.0", + "description": "Thermal-fluid mechanical engineering research workflow plugin for Codex.", + "author": { + "name": "Han Hu", + "email": "72934230+hanhuark@users.noreply.github.com", + "url": "https://github.com/hanhuark" + }, + "homepage": "https://github.com/hanhuark/mechanical-engineering-research-skill", + "repository": "https://github.com/hanhuark/mechanical-engineering-research-skill", + "license": "MIT", + "keywords": [ + "thermal-fluids", + "mechanical-engineering", + "research", + "technical-writing", + "data-analysis", + "codex-skill" + ], + "skills": "./skills/", + "interface": { + "displayName": "Thermal-Fluid Research Workflow", + "shortDescription": "Research, write, code, analyze, and present thermal-fluid work.", + "longDescription": "A workflow plugin for thermal-fluid mechanical engineering research. It combines domain-specific judgment for literature review, technical writing, data analysis, research coding, presentations, AI/ML tools, proposals, patents, and commercialization with reusable workflow prompts.", + "developerName": "Han Hu", + "category": "Productivity", + "capabilities": [ + "Research", + "Write", + "Code" + ], + "websiteURL": "https://github.com/hanhuark/mechanical-engineering-research-skill", + "defaultPrompt": [ + "Plan a thermal-fluid research workflow.", + "Write a technical section with domain rigor.", + "Review this figure and explain the physics." + ], + "brandColor": "#0F766E", + "composerIcon": "./assets/icon.svg" + } +} diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/.codexignore b/plugins/hanhuark/mechanical-engineering-research-skill/.codexignore new file mode 100644 index 00000000..72958886 --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/.codexignore @@ -0,0 +1,9 @@ +.git/ +.github/ +.tmp-paper-text/ +*.pdf +*.pptx +*.docx +*.zip +__pycache__/ +.pytest_cache/ diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/LICENSE b/plugins/hanhuark/mechanical-engineering-research-skill/LICENSE new file mode 100644 index 00000000..95f93f9a --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/LICENSE @@ -0,0 +1,21 @@ +MIT License + +Copyright (c) 2026 Han Hu + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/README.md b/plugins/hanhuark/mechanical-engineering-research-skill/README.md new file mode 100644 index 00000000..f51f99d2 --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/README.md @@ -0,0 +1,314 @@ +# Thermal-Fluid Research Workflow Plugin + +**A Codex plugin for thermal-fluid mechanical engineering research, proposal development, technical writing, data analysis, research coding, presentations, and AI-assisted workflows.** + +This repository packages the `mechanical-engineering-research` skill as a lightweight workflow plugin. The skill remains the domain judgment layer; the plugin adds a cleaner install target and reusable workflow prompts for common research tasks. + +**Works with:** OpenAI Codex plugins and skills + +[![Plugin](https://img.shields.io/badge/Codex-Plugin-blue?style=for-the-badge)](.codex-plugin/plugin.json) +[![Skill](https://img.shields.io/badge/Codex-Skill-teal?style=for-the-badge)](skills/mechanical-engineering-research/SKILL.md) +[![Domain](https://img.shields.io/badge/Domain-Thermal--Fluids-orange?style=for-the-badge)](#capabilities) +[![Validation](https://img.shields.io/badge/Plugin-Validated-brightgreen?style=for-the-badge)](#validation) +[![License: MIT](https://img.shields.io/badge/License-MIT-yellow?style=for-the-badge)](LICENSE) +[![GitHub stars](https://img.shields.io/github/stars/hanhuark/mechanical-engineering-research-skill?style=for-the-badge)](https://github.com/hanhuark/mechanical-engineering-research-skill/stargazers) + +--- + +## What Is This? + +This repository is now a plugin-style distribution for a single canonical skill: + +```text +skills/mechanical-engineering-research/ +``` + +The plugin is designed around a simple principle: + +```text +academic research workflow = process scaffold +mechanical-engineering-research = thermal-fluid domain judgment layer +``` + +Use it to help Codex reason more carefully about thermal-fluid research: source quality, physical assumptions, literature synthesis, methodology detail, data-analysis logic, figure discussion, proposal significance, reproducible code, and AI/ML tools connected back to physics. + +--- + +## Quick Install + +### From Codex Chat + +Ask Codex to install the plugin from GitHub: + +```text +Install the Codex plugin from https://github.com/hanhuark/mechanical-engineering-research-skill +``` + +If your Codex environment does not yet support community plugin installation from a GitHub repo, install the skill folder directly: + +```text +Install the Codex skill from GitHub repo hanhuark/mechanical-engineering-research-skill, path skills/mechanical-engineering-research. +``` + +or: + +```text +Install the Codex skill from https://github.com/hanhuark/mechanical-engineering-research-skill/tree/main/skills/mechanical-engineering-research +``` + +Do not ask Codex to install only `mechanical-engineering-research-skill` as a curated skill name. That is the repository name, not a curated Codex skill name. + +### Manual Skill Installation + +Clone the repository: + +```powershell +git clone https://github.com/hanhuark/mechanical-engineering-research-skill.git +cd mechanical-engineering-research-skill +``` + +Copy the skill into your Codex skills directory: + +```powershell +Copy-Item -Recurse .\skills\mechanical-engineering-research "$env:USERPROFILE\.codex\skills\mechanical-engineering-research" -Force +``` + +Restart Codex if the skill is not discovered immediately. + +--- + +## Capabilities + +| Area | What The Plugin Helps With | Reference | +|---|---|---| +| Research workflow | Source-aware thermal-fluid research, assumptions, correlations, trade studies, validation | [`SKILL.md`](skills/mechanical-engineering-research/SKILL.md) | +| Literature review | Critical review, seminal-work tracing, citation past/future, review figures, benchmark tables | [`literature-review.md`](skills/mechanical-engineering-research/references/literature-review.md) | +| Paper writing style | Preferred journal-paper structure, abstract pattern, figure-led results, conclusions, AI/ML paper style | [`paper-writing-style.md`](skills/mechanical-engineering-research/references/paper-writing-style.md) | +| Technical writing | Introduction logic, methodology detail, modeling assumptions, results discussion | [`technical-writing-analysis.md`](skills/mechanical-engineering-research/references/technical-writing-analysis.md) | +| Proposal development | DOE/NSF/NASA-style proposal narratives, solicitation alignment, review criteria, preliminary results, milestones | [`proposal-development.md`](skills/mechanical-engineering-research/references/proposal-development.md) | +| Data analysis | Baseline case analysis, hypothesis-driven DOE, plotting, figure interpretation | [`technical-writing-analysis.md`](skills/mechanical-engineering-research/references/technical-writing-analysis.md) | +| Research coding | Reproducible scripts, notebooks, data pipelines, plotting code, simulation automation, code review | [`research-coding.md`](skills/mechanical-engineering-research/references/research-coding.md) | +| Presentations | Slide logic, graphics-first storytelling, speaker notes, videos/animations, backup slides | [`presentation-slides.md`](skills/mechanical-engineering-research/references/presentation-slides.md) | +| AI/ML tools | BubbleID, SeqReg, CFDTwin, DataDroid-LAM, sensor fusion, surrogate modeling | [`ai-tools-thermal-fluids.md`](skills/mechanical-engineering-research/references/ai-tools-thermal-fluids.md) | +| Toolchain | Overleaf, VS Code, GitHub, git, releases, archival workflow, reproducibility hygiene | [`research-toolchain.md`](skills/mechanical-engineering-research/references/research-toolchain.md) | +| Innovation | Invention disclosure, patent-support packets, commercialization briefs, non-confidential summaries | [`innovation-commercialization.md`](skills/mechanical-engineering-research/references/innovation-commercialization.md) | +| Briefs | Concise research brief structure for decision-ready engineering summaries | [`brief-template.md`](skills/mechanical-engineering-research/references/brief-template.md) | + +--- + +## Plugin Structure + +```text +mechanical-engineering-research-skill/ + .codex-plugin/ + plugin.json + commands/ + me-build-slides.md + me-code-review.md + me-data-analysis.md + me-lit-review.md + me-write-section.md + skills/ + mechanical-engineering-research/ + SKILL.md + agents/ + openai.yaml + references/ + ai-tools-thermal-fluids.md + brief-template.md + innovation-commercialization.md + literature-review.md + paper-writing-style.md + presentation-slides.md + proposal-development.md + research-coding.md + research-toolchain.md + technical-writing-analysis.md +``` + +--- + +## Workflow Prompts + +The `commands/` folder contains reusable workflow prompts that can be copied into Codex or adapted into future slash commands: + +| Prompt | Use | +|---|---| +| [`me-lit-review.md`](commands/me-lit-review.md) | Critical literature review and gap synthesis | +| [`me-write-section.md`](commands/me-write-section.md) | Manuscript, proposal, report, or thesis-section drafting | +| [`me-data-analysis.md`](commands/me-data-analysis.md) | Baseline-first analysis and hypothesis-driven DOE | +| [`me-build-slides.md`](commands/me-build-slides.md) | Graphics-first research presentations | +| [`me-code-review.md`](commands/me-code-review.md) | Reproducible research code review and refactoring | + +--- + +## Usage Examples + +### Literature Review + +```text +Use the mechanical-engineering-research skill to develop a critical literature review on this thermal-fluid research topic. Synthesize the main theories, methods, limitations, unresolved challenges, and future directions instead of writing a paper-by-paper summary. +``` + +### Federal Proposal Development + +```text +Use the mechanical-engineering-research skill to expand this DOE EPSCoR pre-application into a full proposal narrative. Follow the solicitation structure, map the narrative to review criteria, integrate preliminary results under each thrust, add quantifiable milestones, and cite seminal, recent, and team-relevant papers. +``` + +### Data Analysis Plan + +```text +Use the mechanical-engineering-research skill to design a hypothesis-driven DOE for these experiments or simulations. Start from a baseline case, identify the mechanism being tested, and choose cases that can support or refute the hypothesis. +``` + +### Figure Discussion + +```text +Use the mechanical-engineering-research skill to write the results discussion for this figure. Follow description, observation, physical explanation, and comparison with existing work. +``` + +### Research Coding + +```text +Use the mechanical-engineering-research skill to write a reproducible Python analysis pipeline for this experiment. Start with one baseline case, preserve raw data, make units explicit, and generate publication-quality plots. +``` + +### Research Presentation + +```text +Use the mechanical-engineering-research skill to create a 12-slide conference talk outline from this paper, with graphics-first slides and complementary speaker notes. +``` + +### AI For Thermal Fluids + +```text +Use the mechanical-engineering-research skill to plan a BubbleID/SeqReg workflow for extracting boiling interface dynamics and predicting heat flux from videos and acoustic signals. +``` + +--- + +## Update Workflow + +Use this repository as the canonical source for future improvements. + +```powershell +cd mechanical-engineering-research-skill +git pull +``` + +Edit files under: + +```text +skills/mechanical-engineering-research/ +``` + +Validate the skill: + +```powershell +python "$env:USERPROFILE\.codex\skills\.system\skill-creator\scripts\quick_validate.py" ".\skills\mechanical-engineering-research" +``` + +Validate the plugin: + +```powershell +python "$env:USERPROFILE\.codex\skills\.system\plugin-creator\scripts\validate_plugin.py" "." +``` + +Commit and push: + +```powershell +git add .codex-plugin commands skills README.md CONTRIBUTING.md +git commit -m "Improve thermal-fluid research workflow plugin" +git push +``` + +Copy the updated skill into your local Codex skills directory when you want to use the latest skill version directly: + +```powershell +Copy-Item -Recurse .\skills\mechanical-engineering-research "$env:USERPROFILE\.codex\skills\mechanical-engineering-research" -Force +``` + +--- + +## Validation + +Validate the skill: + +```powershell +python "$env:USERPROFILE\.codex\skills\.system\skill-creator\scripts\quick_validate.py" ".\skills\mechanical-engineering-research" +``` + +Validate the plugin: + +```powershell +python "$env:USERPROFILE\.codex\skills\.system\plugin-creator\scripts\validate_plugin.py" "." +``` + +Expected result: + +```text +Skill is valid! +Plugin is valid! +``` + +--- + +## Related Tools And References + +The AI/ML guidance references several thermal-fluid and mechanical-engineering tools: + +| Tool | Use | +|---|---| +| [BubbleID](https://github.com/cldunlap73/BubbleID) | Computer vision for bubble and interface dynamics | +| [SeqReg](https://github.com/cldunlap73/SeqReg) | Sequence regression for boiling and sensor data | +| [CFDTwin](https://github.com/UARK-NED3/CFDTwin) | CFD surrogate modeling and digital-twin workflows | +| [DataDroid-LAM](https://github.com/spier16/DataDroid-LAM) | Lab analysis and automation tooling | +| [MEEG-54403](https://github.com/hanhuark/MEEG-54403) | Machine Learning for Mechanical Engineers course material | + +--- + +## FAQ + +**Is this still a Codex skill?** + +Yes. The canonical skill now lives at [`skills/mechanical-engineering-research`](skills/mechanical-engineering-research/). The plugin wraps it with metadata and workflow prompts. + +**Why convert it to a plugin?** + +The plugin form gives the project a clearer install target, room for workflow prompts, and a path toward future commands, scripts, assets, or additional skills. + +**Does the plugin replace academic-research workflow tools?** + +No. For full papers and proposals, use academic-research workflow tools as the process scaffold when available. Use this plugin as the thermal-fluid/mechanical-engineering judgment layer. + +**Can I use this with Claude Code, Cursor, or other agents?** + +The core skill is markdown-based and can be adapted manually. The plugin metadata here is Codex-oriented. + +**How should I contribute improvements?** + +Add reusable guidance, not one-off facts. Keep `SKILL.md` concise and put detailed workflows in `references/`. See [`CONTRIBUTING.md`](CONTRIBUTING.md). + +--- + +## Contributing + +Contributions are welcome. Good contributions improve reusable research practice: + +- clearer thermal-fluid research workflows +- stronger literature-review synthesis methods +- proposal development and review-criteria guidance +- technical writing and results-discussion guidance +- data-analysis, plotting, and DOE practices +- reproducible research coding practices +- presentation design patterns +- AI/ML workflows for mechanical engineering + +See [`CONTRIBUTING.md`](CONTRIBUTING.md) for details. + +--- + +## License + +MIT License. See [`LICENSE`](LICENSE) for details. diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/assets/icon.svg b/plugins/hanhuark/mechanical-engineering-research-skill/assets/icon.svg new file mode 100644 index 00000000..b42f777b --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/assets/icon.svg @@ -0,0 +1,23 @@ + + Thermal-Fluid Research Workflow + Stylized heat plume, fluid streamline, and research node network. + + + + + + + + + + + + + + + + + + + + diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/SKILL.md b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/SKILL.md new file mode 100644 index 00000000..33364c13 --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/SKILL.md @@ -0,0 +1,129 @@ +--- +name: mechanical-engineering-research +description: Research, write, code, analyze, present, and develop proposals for thermal-fluid mechanical engineering work with source-aware rigor. Use for heat transfer, fluid mechanics, thermodynamics, HVAC, energy systems, turbomachinery, pumps, piping, CFD, experiments, correlations, standards, datasheets, papers, patents, AI/ML tools, computer vision, sequence regression, surrogate modeling, research coding, Overleaf, VS Code, GitHub, git, federal grant proposals, DOE/NSF/NASA-style narratives, invention disclosure, provisional patent support, commercialization, and trade studies. Produces technical briefs, critical literature reviews, proposal narratives, review-criteria responses, manuscript sections, methods, results discussions, data-analysis plans, plots, presentations, design comparisons, calculation plans, reproducible code, repository workflows, disclosure drafts, patent-support packets, and research roadmaps. +--- + +# Mechanical Engineering Research + +## Overview + +Use this skill to research thermal-fluid systems with engineering rigor: define the question, collect reliable sources, preserve assumptions and validity ranges, and separate verified evidence from inference. + +## Workflow Coordination + +For full paper, proposal, review-article, thesis chapter, or major manuscript workflows, use an academic-research workflow as the scaffold when one is available, and use this skill as the thermal-fluid/mechanical-engineering judgment layer. + +Treat the roles as: + +- **Academic research workflow**: organize the process, checkpoints, outline, drafting sequence, review/revision loop, citation/claim checks, and finalization. +- **Mechanical engineering research skill**: enforce domain logic, physical reasoning, literature synthesis standards, methodology detail, assumptions, data-analysis rigor, figure discussion, plotting, presentation quality, AI/ML interpretation, reproducible coding, and proposal-specific technical judgment. + +When both are available, do not let a generic academic workflow overwrite domain judgment. Apply this skill whenever deciding whether the research question, gap, method, DOE, model assumptions, interpretation, figure narrative, or proposal significance is mechanically and thermally sound. + +## Research Workflow + +1. Clarify the engineering objective. + - Identify the system, working fluid, operating regime, geometry, boundary conditions, performance metric, and constraints. + - Ask for missing high-impact values only when they determine the research path; otherwise state assumptions and proceed. + +2. Build a source hierarchy. + - Prefer standards, textbooks/handbooks, peer-reviewed papers, manufacturer datasheets, government or lab reports, and primary patents. + - Use web search for current papers, standards status, products, prices, regulations, or citations. Cite sources with links whenever browsing is used. + - Treat blogs, marketing pages, forum posts, and uncited summaries as orientation only unless the user explicitly asks for informal context. + +3. Extract engineering substance. + - Capture equations, correlations, dimensionless groups, material limits, empirical constants, and uncertainty. + - Record applicability limits: Reynolds/Rayleigh/Nusselt ranges, Prandtl range, Mach/compressibility assumptions, phase-change regime, geometry, roughness, orientation, temperature/pressure range, and fluid property source. + - Note what was measured, simulated, or assumed. + +4. Compare alternatives by mechanism. + - Explain why each design or model performs differently, not only which is "best." + - Consider pressure drop, heat-transfer coefficient, pumping power, fouling, manufacturability, instrumentation, maintenance, safety, cost, and scaling behavior. + +5. Produce a decision-ready output. + - Lead with the answer or recommendation. + - Include assumptions, key evidence, equations/correlations, source quality, uncertainty, and next verification steps. + - Mark engineering inference explicitly when sources do not directly prove a claim. + - Use a clear paragraph logic flow: each paragraph starts with a central topic sentence, and each following sentence develops, supports, qualifies, or transitions from that topic. + +## Output Patterns + +For a research brief, use: + +- **Question**: One sentence defining the engineering problem. +- **Bottom Line**: Concise answer, recommendation, or state of evidence. +- **Assumptions**: Operating conditions, geometry, fluid, and scope. +- **Evidence**: Source-backed findings with citations. +- **Models/Correlations**: Equations, variables, units, and validity limits. +- **Tradeoffs**: Performance, cost, safety, reliability, manufacturability, and uncertainty. +- **Gaps**: What remains unverified or standards-dependent. +- **Next Steps**: Calculations, experiments, simulations, or standards lookups. + +For a literature review, read `references/literature-review.md`. Group sources by mechanism, method, design family, or unresolved question rather than listing papers chronologically. + +For federal research proposals, DOE EPSCoR/National Laboratory partnership proposals, full narrative expansions, review-criteria responses, or ready-to-submit proposal polishing, read `references/proposal-development.md`. + +For a design comparison, include a compact decision matrix and explain the dominant physics behind each score. + +For manuscript-style technical writing, read `references/technical-writing-analysis.md` before drafting or revising introductions, methods, modeling sections, results/discussion, data analysis, or plot narratives. + +For full technical papers, journal manuscripts, or paper-style section drafting, also read `references/paper-writing-style.md` to match the preferred section logic, abstract style, figure-led results, and conclusion patterns. + +For experiments, simulations, or parameter studies, use `references/technical-writing-analysis.md` to plan a detailed baseline case and hypothesis-driven DOE before proposing broad sweeps or large case matrices. + +For research presentations or slide decks, read `references/presentation-slides.md` before creating slide outlines, slide content, speaker notes, or visual-story plans. + +For AI/ML-assisted thermal-fluid research, read `references/ai-tools-thermal-fluids.md` before recommending computer vision, sequence regression, surrogate modeling, sensor fusion, dimensionality reduction, or data-driven control workflows. + +For research code, scripts, notebooks, data pipelines, plotting code, CFD automation, or ML implementation, read `references/research-coding.md` before writing or reviewing code. + +For research tool workflows involving Overleaf, VS Code, GitHub, or git, read `references/research-toolchain.md` before advising on manuscript collaboration, code/debugging workflow, repository updates, archival releases, branches, commits, tags, or reproducibility hygiene. + +For innovation, invention disclosure, provisional patent support, utility patent technical content, or technology commercialization, read `references/innovation-commercialization.md` before drafting disclosure answers, non-confidential summaries, technical descriptions, figure lists, prior-art comparisons, market/use-case notes, inventor response emails, or commercialization briefs. Support the technical and strategic content, but do not provide legal advice; defer claim scope, filing strategy, assignments, declarations, and prosecution decisions to Technology Ventures and patent counsel. + +## Thermal-Fluid Checks + +Before finalizing, check whether the answer should account for: + +- Laminar, transitional, turbulent, natural, forced, or mixed convection. +- Internal, external, developing, fully developed, compressible, multiphase, or non-Newtonian flow. +- Radiation, conduction contact resistance, fins, heat pipes, boiling, condensation, or evaporative cooling. +- Pump/fan curves, NPSH, cavitation, choking, surge, fouling, erosion, corrosion, thermal stress, or fatigue. +- Property variation with temperature and pressure. +- Similarity/scaling limits between benchtop tests, CFD, and full-scale systems. +- Applicable ASME, ASTM, ISO, API, ASHRAE, NFPA, or local code requirements. + +## CFD And Experiments + +When discussing CFD: + +- Identify turbulence model, wall treatment, mesh independence, boundary conditions, property models, convergence criteria, and validation data. +- Do not present CFD as evidence unless the setup and validation are known. +- Suggest simpler analytical or empirical checks as sanity bounds when available. + +When discussing experiments: + +- Identify sensors, calibration, uncertainty, repeatability, heat loss correction, flow development, and property measurement. +- Prefer outputs that can be independently reproduced from stated dimensions and conditions. + +## Reference Files + +Read `references/brief-template.md` when the user asks for a reusable research brief format, report outline, or deliverable template. + +Read `references/technical-writing-analysis.md` when the user asks for technical writing, manuscript sections, data analysis, figures, plots, or results discussion. + +Read `references/paper-writing-style.md` when the user asks to write, revise, outline, or polish a journal paper, conference paper, manuscript, abstract, introduction, methods, results/discussion, conclusion, or paper-style technical narrative. + +Read `references/literature-review.md` when the user asks for a literature review, related-work section, research background, citation map, state-of-the-art comparison, review figure/table, future-work analysis, or paper discovery strategy. + +Read `references/proposal-development.md` when the user asks for grant/proposal development, solicitation alignment, pre-application expansion, DOE EPSCoR or National Lab partnership narratives, collaborator document planning, review-criteria mapping, milestones, preliminary-results integration, proposal figures, references, or ready-to-submit polish. + +Read `references/presentation-slides.md` when the user asks for presentation slides, a research talk, conference talk, group-meeting slides, slide-by-slide narrative, speaker notes, animation/video suggestions, or figure-focused storytelling. + +Read `references/ai-tools-thermal-fluids.md` when the user asks about AI tools, machine learning, computer vision, BubbleID, SeqReg, CFDTwin, DataDroid-LAM, MEEG-54403, sensor fusion, surrogate modeling, dimensionality reduction, thermal-fluid datasets, or ML-enhanced data analysis. + +Read `references/research-coding.md` when the user asks for coding help, research scripts, notebooks, data processing, plotting, reproducibility, simulation automation, CFD post-processing, ML implementation, repository organization, or code review. + +Read `references/research-toolchain.md` when the user asks about Overleaf writing/editing, VS Code coding/debugging, GitHub repo updating or archiving, git branches/commits/tags/releases, repository hygiene, manuscript-code-data synchronization, or reproducible project handoff. + +Read `references/innovation-commercialization.md` when the user asks for invention disclosure, Technology Ventures, Sophia disclosure, provisional patent, utility patent application support, patent counsel feedback, USPTO filing support, notice of allowance/grant tracking, licensing, startup/commercialization strategy, non-confidential summaries, or translating research results into protectable/commercializable technology. diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/agents/openai.yaml b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/agents/openai.yaml new file mode 100644 index 00000000..0adff888 --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/agents/openai.yaml @@ -0,0 +1,4 @@ +interface: + display_name: "Mechanical Engineering Research" + short_description: "Research, write proposals, code, present, analyze, use AI, manage repos, and support IP." + default_prompt: "Research, critically review, analyze, code, write, develop proposals, present, manage Overleaf/VS Code/GitHub/git workflows, support invention disclosure or commercialization, or apply AI tools to this thermal-fluid systems question with clear logic flow, source-aware reasoning, and reproducible workflows." diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/ai-tools-thermal-fluids.md b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/ai-tools-thermal-fluids.md new file mode 100644 index 00000000..3e97fc7c --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/ai-tools-thermal-fluids.md @@ -0,0 +1,121 @@ +# AI Tools For Thermal-Fluid Research + +Use this reference when a task involves AI, machine learning, computer vision, sequence regression, surrogate modeling, sensor fusion, dimensionality reduction, data-driven control, or ML-assisted analysis for thermal-fluid systems. + +## Core Principle + +Use AI tools to extract physics, accelerate analysis, or enable measurements that are difficult with manual methods. Do not use machine learning as a substitute for defining the physical question, baseline case, uncertainty, and validation plan. + +Always connect the ML task to a thermal-fluid objective: + +- Detect or classify regimes, events, structures, or failure transitions. +- Quantify physical quantities from images, acoustic signals, simulations, or sensor streams. +- Extract interpretable features, modes, mechanisms, or low-dimensional coordinates. +- Build fast surrogate models for expensive experiments or simulations. +- Fuse multiple sensing modalities to improve robustness. +- Support design, control, monitoring, or decision-making. + +## Tool Selection + +Use these tools and repositories as examples and starting points: + +- `BubbleID` (https://github.com/cldunlap73/BubbleID): computer-vision framework for pool-boiling images. Use for bubble tracking, segmentation, classification, interface-velocity analysis, bubble statistics, vapor fraction, bubble count, and related image-derived metrics. +- `SeqReg` (https://github.com/cldunlap73/SeqReg): sequence-regression framework for boiling heat-flux prediction and general sequence regression from time series, acoustic emission, hydrophone data, and optical/image-derived inputs. +- `CFDTwin` (https://github.com/UARK-NED3/CFDTwin): surrogate modeling and digital-twin workflows for CFD simulations, especially when expensive CFD cases need accelerated prediction, interpolation, or design exploration. +- `DataDroid-LAM` (https://github.com/spier16/DataDroid-LAM): lab analysis tooling example for automated or AI-assisted processing workflows. +- `MEEG-54403` (https://github.com/hanhuark/MEEG-54403): Machine Learning for Mechanical Engineers course reference for supervised learning, unsupervised learning, image classification, clustering, dimensionality reduction, time-series classification/regression, surrogate modeling, GPU/CPU scalability, and mechanical-engineering datasets. + +Before using any repository, inspect the current README, examples, dependencies, model weights, licenses, and required data format. Tool capabilities and installation details may change. + +## Workflow + +1. Define the engineering question. + - Example: predict heat flux, identify CHF, measure bubble departure, quantify interface velocity, classify boiling regime, build a CFD surrogate, or extract dominant thermal-fluid modes. + +2. Choose the data modality. + - Images or videos: use computer vision, segmentation, tracking, optical-flow-like analysis, image regression, or classification. + - Acoustic or hydrophone signals: use time-series features, frequency-domain features, event/hit features, or sequence regression. + - CFD or simulation data: use surrogate modeling, reduced-order modeling, dimensionality reduction, active learning, or digital twins. + - Multimodal data: use sensor fusion, aligned time histories, or multi-branch models. + +3. Establish a baseline case. + - Run the full pipeline on one representative case. + - Show raw data, preprocessing, labels or annotations, model output, error cases, and final physical metrics. + - Verify whether the model output agrees with human inspection, known physics, conservation laws, or independent measurements. + +4. Design hypothesis-driven ML experiments. + - State the hypothesis, such as "acoustic spectra encode heat flux," "bubble-interface dynamics predict CHF," or "low-dimensional CFD modes capture design trends." + - Choose cases, labels, features, and model comparisons that can support or reject the hypothesis. + - Avoid training a large model before confirming that the data contain the needed physics. + +5. Validate and interpret. + - Use train/validation/test separation that prevents leakage across videos, experiments, surfaces, pressures, geometries, or simulation families. + - Report error metrics that match the engineering objective. + - Test generalization across conditions, not only random splits from the same experiment. + - Inspect failure cases and relate them to physics, sensor noise, domain shift, or labeling uncertainty. + +## Data Preparation + +For image/video workflows: + +- Record frame rate, resolution, field of view, lighting, magnification, exposure time, and synchronization. +- State whether frames, videos, masks, labels, or annotations are used. +- Define event labels such as departure, coalescence, CHF, film boiling, or regime transition. +- Check whether the frame rate is sufficient for tracking; lower frame rates may support per-frame quantities but not reliable dynamics. + +For acoustic or sequence workflows: + +- Record sampling rate, sensor type, sensor location, thresholding, hit definition, filtering, and frequency-domain processing. +- Define sequence length, overlap, FFT/windowing choices, and label timing. +- Check synchronization between thermal measurements and signal data. + +For CFD/surrogate workflows: + +- Define geometry parameters, mesh, solver settings, boundary conditions, outputs, and convergence criteria. +- Include design-space bounds and explain why training cases cover the intended interpolation region. +- Treat extrapolation outside the training design space as high risk unless separately validated. + +## Model Evaluation + +Choose evaluation metrics based on the engineering use: + +- Regression: MAE, RMSE, relative error, R2, calibration, error versus regime, and physically important threshold error. +- Classification: confusion matrix, precision, recall, F1 score, ROC/PR curves, and class-imbalance handling. +- Segmentation/tracking: IoU, mask quality, tracking continuity, ID switches, event-timing error, and manually inspected failure modes. +- Surrogate modeling: error over the design space, extrapolation behavior, uncertainty, active-learning gain, and comparison with CFD or experiment. + +Always include representative visual diagnostics: + +- Raw input and model output side by side. +- Error maps or residual plots. +- Predicted versus measured values. +- Time histories with events marked. +- Failure cases and likely causes. + +## Physics-Aware Interpretation + +After model evaluation, translate ML results back into thermal-fluid understanding. + +Ask: + +- What physical mechanism is the model likely using? +- Are the learned features consistent with known scaling, regimes, or conservation laws? +- Does performance degrade at transitions, extremes, unseen surfaces, different fluids, or new geometries? +- Can simpler physics-based features achieve similar performance? +- What new measurement, trend, or research hypothesis did the ML tool enable? + +Avoid presenting model accuracy as the final scientific contribution. The contribution should be the measurement capability, physical insight, design acceleration, monitoring reliability, or new hypothesis enabled by the model. + +## Reporting AI/ML Work + +When writing or presenting AI-assisted thermal-fluid work, include: + +- Engineering objective and why ML is needed. +- Dataset description, baseline case, labels, preprocessing, and train/test split. +- Model architecture or tool used, with repository link if relevant. +- Training procedure, hyperparameters, and hardware only to the level needed for reproducibility. +- Evaluation metrics, visual diagnostics, uncertainty, and failure cases. +- Generalization tests across meaningful thermal-fluid conditions. +- Physics interpretation and limits of applicability. + +For presentations, show the pipeline visually: raw data -> preprocessing -> model -> output metric -> physical interpretation. diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/brief-template.md b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/brief-template.md new file mode 100644 index 00000000..78bf9fa1 --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/brief-template.md @@ -0,0 +1,63 @@ +# Thermal-Fluid Research Brief Template + +Use this template when the user wants a structured deliverable. + +## Title + +Short engineering title naming the system and research question. + +## Question + +Define the system, operating conditions, design objective, and decision to support. + +## Bottom Line + +State the recommendation or strongest evidence in 3-6 sentences. + +## Assumptions And Scope + +List fluid, geometry, pressure, temperature, flow regime, heat load, target metric, and exclusions. + +## Evidence Summary + +Use a table with columns: + +- Source +- Source type +- What it supports +- Key data/correlation +- Applicability limits +- Confidence + +## Engineering Model + +Define variables, units, equations, correlations, and property sources. + +Include dimensionless groups where relevant: + +- Reynolds number +- Prandtl number +- Nusselt number +- Rayleigh number +- Grashof number +- Biot number +- Fourier number +- Mach number +- Friction factor + +## Trade Study + +Use a decision matrix when comparing designs. Include performance, pressure drop, power, safety, manufacturability, maintenance, cost, and uncertainty. + +## Risks And Unknowns + +Separate: + +- Source-backed limitations +- Engineering inference +- Unverified assumptions +- Standards or code dependencies + +## Recommended Next Steps + +List calculations, tests, CFD validation, datasheet requests, standards checks, or prototype measurements. diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/innovation-commercialization.md b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/innovation-commercialization.md new file mode 100644 index 00000000..c3b0dc9a --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/innovation-commercialization.md @@ -0,0 +1,114 @@ +# Innovation, Invention Disclosure, Patent Support, And Commercialization + +Use this reference when helping convert research into inventor-facing IP and commercialization materials. This is technical and strategic support, not legal advice. Defer legal decisions, claim scope, filing strategy, assignments, declarations, prosecution, and USPTO correspondence to University of Arkansas Technology Ventures and patent counsel. + +## UA Technology Ventures Workflow + +At the University of Arkansas, route invention and commercialization work through Technology Ventures: https://research.uark.edu/techventures/. Their public page says Technology Ventures helps faculty and research scientists identify, protect, and commercialize intellectual property from university-supported activities, and that new invention disclosures and patent-filing status are handled in the Sophia database. + +Typical workflow: + +1. File an invention disclosure with Technology Ventures. + - Treat this as a structured questionnaire for the invention. + - Prepare concise but substantive answers, figures, evidence, inventor/funding information, prior-art notes, and non-confidential summary language. + - Keep confidentiality in mind before public presentations, papers, theses, posters, websites, code releases, or sponsor reports. + +2. Support Technology Ventures and patent counsel in preparing a provisional patent application. + - Inventors provide the technical content, examples, figures, data, and implementation variants. + - Technology Ventures and counsel prepare the legal document. + - Inventors should review drafts for technical accuracy, missing embodiments, correct units/labels, figure consistency, inventor list, funding, and public-disclosure dates. + +3. Around the one-year conversion window, support review for utility patent filing. + - Patent counsel may review the provisional and recommend whether to file a utility application. + - Inventors provide updates, new data, improved figures, revised embodiments, use cases, and responses to counsel questions. + - Technology Ventures handles writing/submission mechanics; inventors review technical content and execute requested declaration/assignment paperwork. + +4. Track application, allowance, and grant. + - Technology Ventures may notify inventors of filing, application number, publication, Notice of Allowance, and grant/active status. + - When asked for current status, verify with official or public patent databases. + +Example case: US12591230B2, "Detecting or predicting system faults in cooling systems in a non-intrusive manner using deep learning," lists Han Hu, Hari Pandey, and Christy Dunlap as inventors. Google Patents shows filing on December 9, 2022, publication of US20230195094A1 on June 22, 2023, grant/publication of US12591230B2 on March 31, 2026, and active status. The local project history indicates invention disclosure materials in 2021, provisional filing support in 2022, and utility application filing in 2022/2023-era communications; when exact dates matter, verify against source documents and patent databases. + +## Inventor Packet Checklist + +For invention disclosure: + +- Working title and short non-confidential title. +- Background/problem: what existing systems cannot do and why the problem matters. +- Brief invention summary: the core technical idea in plain language. +- Detailed technical description: system architecture, sensors, algorithms, control logic, hardware/software components, workflows, and variants. +- Novelty and advantages: what is faster, safer, more accurate, less intrusive, more scalable, cheaper, easier to retrofit, or otherwise different from existing approaches. +- Proof of concept: experiments, simulations, raw signals, figures, videos, datasets, model results, validation metrics, and dates. +- Prior art and competing approaches: papers, patents, products, and limitations. +- Products/services: likely embodiments, retrofit packages, software, hardware, SaaS, consulting/evaluation services, or licensing targets. +- Market/use cases: industries, users, pain points, regulatory/safety relevance, and deployment environments. +- Inventors and contributions: who contributed to conception and what each person contributed. +- Funding and obligations: grants, sponsors, contracts, federal funding, ERISF/seed grants, or other reporting obligations. +- Public disclosures: submitted manuscripts, talks, posters, abstracts, theses, websites, demos, GitHub releases, sponsor reports, or planned disclosures. +- Attachments: sketches, data plots, photos, architecture diagrams, draft papers, prior-art PDFs, and signatures if requested. + +For provisional/utility patent technical support: + +- Clean figure set with captions and consistent labels. +- Technical field, background, summary, brief description of drawings, and detailed description inputs. +- Multiple embodiments and alternatives, not just the current lab prototype. +- Data examples that show mechanism and utility. +- Units and labels checked across text, figures, and claims-facing descriptions. +- Distinction between measured facts, engineering inference, and desired future embodiments. +- Draft-review response listing technical corrections and missing content. +- Signed paperwork only as requested by Technology Ventures or counsel. + +## Drafting Guidance + +Write inventor-facing drafts in a dual register: + +- Use plain technical language for Technology Ventures intake. +- Include enough implementation detail that patent counsel can generalize the invention beyond one experiment. + +For a disclosure answer, prefer this structure: + +1. Problem and technical gap. +2. Core inventive concept. +3. System components and data flow. +4. What is non-intrusive, real-time, multimodal, predictive, or otherwise advantageous. +5. Proof-of-concept evidence. +6. Variants, extensions, and commercial embodiments. +7. Prior art and why this is different. +8. Commercial value and target users. + +For patent-support figure review: + +- Check whether each figure supports a specific technical point. +- Use consistent numbering, labels, units, time stamps, colorbars, and terminology. +- Ensure panels compared side-by-side are from compatible experiments or clearly explain differences. +- Flag any figure where the result could be misread by counsel or reviewers. + +For emails to Technology Ventures: + +- Be concise and factual. +- Confirm receipt/review of drafts, packets, drawings, declaration/assignment forms, or filing notices. +- Group requested corrections by figure, paragraph, claim concept, or attachment. +- State when the inventors have no further technical questions. +- Avoid making legal assertions; ask Technology Ventures or counsel for legal/process questions. + +## Commercialization Outputs + +When asked for commercialization support, produce one or more of: + +- Non-confidential summary: problem, solution, benefits, applications, development status, and licensing/startup fit without enabling confidential details. +- Technology one-pager: title, unmet need, innovation, advantages, proof-of-concept, IP status, target markets, and next development milestones. +- Value proposition: user, pain point, measurable benefit, deployment path, and buying/licensing rationale. +- Prior-art/product comparison: current method, limitation, proposed technology advantage, evidence, and residual risk. +- Partner/customer discovery questions: technical buyer, economic buyer, workflow integration, safety/regulatory needs, validation threshold, and retrofit constraints. +- Development roadmap: prototype, validation, field pilot, manufacturability, software/data pipeline, IP milestones, and commercialization decision gates. + +## Example Technical Content Pattern + +For thermal-fluid AI inventions, capture: + +- Sensors: acoustic emission sensors, hydrophones, microphones, optical/high-speed cameras, thermocouples, pressure/flow sensors. +- Signals: temporal waveforms, frequency-domain spectrograms, images/video, heat flux, temperature, vapor fraction, flow state. +- Models: CNNs, recurrent networks, ConvLSTM, multimodal fusion, anomaly detection, prediction/classification, control or mitigation logic. +- Faults: boiling crisis, critical heat flux, flow maldistribution, flow reversal, dryout, cavitation, fouling, pump/fan faults, overheating. +- Benefits: non-intrusive measurement, faster-than-thermal-diffusion detection, early warning, real-time monitoring, retrofit compatibility, safer operation, higher heat-flux utilization. +- Evidence: experiment dates, sampling rates, heat flux range, image frame rate, validation metrics, representative plots, and videos. diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/literature-review.md b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/literature-review.md new file mode 100644 index 00000000..1277cb61 --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/literature-review.md @@ -0,0 +1,211 @@ +# Critical Literature Review + +Use this reference when producing literature reviews, related-work sections, citation maps, research-background sections, review figures/tables, or paper discovery strategies. + +## Core Principle + +Treat literature review as research analysis, not paper collection. + +Reading papers and writing one or two sentences about each paper is only preliminary data collection. A good review adds the author's own analysis: patterns, limitations, challenges, mechanisms, disagreements, opportunities, and synthesis across papers. + +Effective review work should integrate: + +- Reading and writing: find, understand, summarize, compare, and synthesize sources. +- Doing: build CAD models, write analysis code, digitize plots, run calculations, simulate cases, or perform preliminary tests when needed to understand a paper. +- Communicating: talk to experts, manufacturers, collaborators, or authors when papers do not contain enough practical detail. + +Assume that some papers cannot be fully understood from reading alone. When needed, reproduce a calculation, implement a model, inspect geometry, digitize a figure, or run a small baseline case to understand the method and limitations. + +## Review As A Story + +Write the review as the user's own story, not as a concatenated list of paper summaries. + +The review should answer: + +- Why does this field or problem matter? +- What are the main approaches, theories, methods, materials, designs, diagnostics, or manufacturing routes? +- What has each approach clarified or enabled? +- What limitations, contradictions, or unresolved challenges remain? +- Why do these challenges persist? +- What opportunities, future work, or research directions follow from the synthesis? +- How does the user's current or proposed work fit into this landscape? + +If a review only teaches the writer what others have done, it is preliminary. A mature review contributes something new through critical analysis, outlook, synthesized trends, mechanism maps, taxonomies, benchmark plots, summary tables, or a clarified research framework. + +## Literature Review Workflow + +1. Start from the research question and target decision. + - Define what the review must enable: choosing a manufacturing method, selecting a model, designing a diagnostic, interpreting data, or framing a manuscript. + +2. Identify seminal work. + - Start with papers that introduced major theories, methods, benchmark datasets, structures, models, or experimental approaches. + - Do not start only from the newest papers; understand the origin of the ideas. + +3. Trace the past and future of key references. + - For each key reference, read its introduction and bibliography carefully. This is the past of the work. + - Search for papers that cited the key reference. This is the future of the work. + - Use citation tracing to identify main players, competing schools of thought, and how the field evolved. + +4. Search selectively and balance coverage. + - Avoid overciting one research group, one theory, or one method when multiple major approaches exist. + - For mature fields, cite representative and high-impact papers rather than every available paper. + - Ensure coverage includes major theories, major experimental methods, key materials/geometries, and important contradictory results. + +5. Extract comparable information. + - Capture geometry, material, working fluid, operating conditions, manufacturing method, diagnostics, performance metrics, correlations, assumptions, and uncertainty. + - Convert symbols and definitions into a unified notation when comparing equations. + - Digitize figures when needed and allowed by the task; clearly mark digitized values and likely uncertainty. + +6. Synthesize rather than list. + - Group papers by mechanism, theory, design family, method, metric, material, operating regime, or unresolved challenge. + - Identify trends, scaling behavior, agreement, disagreement, limitations, and missing diagnostics. + +7. Connect review to doing and communicating. + - Use the review to decide what calculation, CAD model, code, experiment, manufacturer question, or expert conversation should happen next. + - Use results from doing and communicating to refine the literature search. + +## Critical Review Expectations + +A critical review should include more than summary. + +It should identify: + +- Limitations of existing studies. +- Challenges that explain why issues remain unsolved. +- Conflicting conclusions and possible causes of disagreement. +- Missing diagnostics, missing operating regimes, or missing practical constraints. +- Trends and patterns visible only after comparing multiple papers. +- Main directions and future work. +- Opportunities created by new measurement methods, models, fabrication methods, or datasets. + +Avoid writing "to the best of our knowledge, no literature has been published on this topic" as the main novelty claim. Instead, ask: + +- Is the topic important? If not, why study it? +- If it is important, why has it not been solved? +- Is the barrier measurement difficulty, fabrication difficulty, coupled physics, lack of theory, cost, throughput, scale-up, or missing diagnostics? +- How does the proposed work overcome that barrier? + +## Citation And Synthesis Style + +Use professional manuscript citation style. + +- Refer to papers by the first author's last name followed by "et al." when the sentence names the authors, such as "Rahman et al. demonstrated..." Do not write long author lists such as "Author 1, Author 2, Author 3, and Author 4..." in the prose. +- Avoid vague phrasing such as "Author and collaborators" unless the exact paper or group relationship matters. +- Use citation placeholders or the user's citation format consistently, such as `Rahman et al. [12]` or `Rahman et al. (2014)`, depending on the manuscript style. +- Check that the named first author matches the actual first author of the cited paper. + +Write compact synthesis instead of redundant two-sentence summaries. + +- Avoid this pattern: "Rahman et al. studied X. Their results show Y." +- Prefer a single purposeful sentence when possible: "Rahman et al. used X to demonstrate Y." +- Use two sentences only when the method and conclusion each need emphasis, or when a limitation, contrast, or mechanism must be developed. + +For each cited paper or group of papers, decide whether it is: + +- A key reference that deserves discussion of method, result, mechanism, and limitation. +- A background reference that only needs acknowledgment within a category. +- A comparison reference used to position the user's data, model, or method. + +Do not give every background reference a full sentence. Doing so makes the review read like an annotated bibliography instead of a synthesis. + +## Background Reference Grouping + +Background references should be acknowledged efficiently and accurately. + +When many studies belong to different categories, group citations by category rather than bundling all references at the end of one broad sentence. + +Good pattern: + +```text +Textured boiling surfaces have been developed in many forms, including micropillar arrays [15-21], re-entrant cavities [1,22,23], ordered porous structures [24-27], disordered microporous coatings [28-31], nanowires [32-36], and hierarchical multiscale structures [20,37-56]. +``` + +This structure is better than either: + +- writing one sentence for every background paper, which is too slow and redundant; or +- placing one large citation range at the end of the sentence, which hides the fact that the papers belong to different technical categories. + +Use category-level background citations when: + +- the purpose is to acknowledge the breadth of prior work; +- the individual papers are not central to the current argument; or +- the review is setting up a transition to the few papers that matter most. + +After category-level citations, select only the most relevant papers for deeper discussion. + +## Group Review To Gap Transition + +After reviewing a group of references, explicitly state the limitation, unresolved issue, or knowledge gap that motivates the present work. + +Use this logic: + +1. Summarize the research category or theory. +2. Cite representative references in the right categories. +3. State what the group of studies has established. +4. State what remains unclear, limited, contradictory, difficult to measure, or insufficiently modeled. +5. Explain how that limitation motivates the present study. + +Example pattern: + +```text +Prior studies have shown that structured surfaces can enhance boiling performance through increased nucleation density, capillary liquid supply, and modified liquid-vapor interfacial dynamics [category-specific citations]. However, the relative contribution of these mechanisms remains difficult to isolate because most measurements observe the apparent interface rather than liquid replenishment within the structures. This limitation motivates the present use of multimodal diagnostics to connect surface wickability with boiling behavior. +``` + +Do not end a paragraph after only summarizing prior work. The paragraph should usually end by pointing to a limitation, gap, challenge, implication, or transition. + +## Review Figures, Tables, And Charts + +Use figures, charts, and tables as analysis tools. + +Valuable review artifacts include: + +- Taxonomy figures that classify technologies, mechanisms, theories, structures, diagnostics, or manufacturing approaches. +- Benchmark plots that compare performance metrics across literature and the user's work. +- Summary tables of geometry, material, dimensions, method, operating conditions, and performance. +- Mechanism maps that connect structures or process parameters to physical effects and outcomes. +- Equation comparison tables with a unified symbol system and stated assumptions. +- Timeline or citation-map figures showing how ideas developed from seminal work to current directions. +- Cost, throughput, scalability, and limitation tables for manufacturing or experimental methods. + +When making a comparison plot: + +- Use color to distinguish source or study group when useful. +- Use marker shape to distinguish material, structure type, fluid, or method. +- Include the user's result only when directly comparable; otherwise explain why the comparison is imperfect. +- Use the plot to draw a conclusion about generalizability, gaps, or positioning, not only to decorate the review. + +Even if a review figure contains no new experimental data, it can contribute new knowledge by organizing scattered literature into a clear framework. + +## Literature-Grounded Positioning + +Compare the user's work against literature honestly. + +- If the user's performance is not better than prior work, state that plainly. +- Then identify other contributions: transient versus steady-state behavior, multimodal diagnostics, new measurement access, model validation, manufacturability, cost, throughput, scalability, or mechanism clarification. +- Use literature comparison to decide whether the work should emphasize performance improvement, fundamental understanding, method development, or practical feasibility. + +## Manufacturing And Technology Reviews + +When reviewing manufacturing options, include more than technical feasibility. + +Compare: + +- Achievable geometry and material compatibility. +- Process constraints, tolerances, defects, and post-processing. +- Throughput, cost, vendor availability, maturity, and scalability. +- Risks, failure modes, inspection methods, and quality control. +- What must be tested or asked of manufacturers before down-selection. + +Use communication with manufacturers or experts as review evidence, but label it clearly as expert/vendor input rather than peer-reviewed literature. + +## Quality Check + +Before finalizing a literature review, ask: + +- What new knowledge does this review contribute? +- Are the contributions critical analysis, outlook, synthesized trends, benchmark comparisons, taxonomy, or unified theory/model comparison? +- Does the review identify main players and seminal work? +- Does it avoid overrepresenting one group, one theory, or one convenient cluster of papers? +- Are the figures, tables, or charts doing analytical work? +- Does the review explain why unresolved problems remain difficult? +- Does the review lead naturally to a research question, DOE, model, experiment, or design decision? diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/paper-writing-style.md b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/paper-writing-style.md new file mode 100644 index 00000000..68704220 --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/paper-writing-style.md @@ -0,0 +1,214 @@ +# Paper Writing Style + +Use this reference when drafting or revising full technical papers, journal manuscripts, conference papers, abstracts, introductions, methods, results/discussion sections, and conclusions in the preferred thermal-fluid mechanical engineering style. + +## Core Style + +Write as a technical paper that teaches the physics, not as a collection of facts. + +The preferred style is: + +- Problem-driven: start from an important engineering or scientific need. +- Mechanism-focused: explain what physical process, measurement, model, or data relationship is being clarified. +- Evidence-forward: use figures, equations, experiments, simulations, and comparisons to support claims. +- Compact: avoid redundant sentence pairs when one sentence can state the method and conclusion. +- Specific: include conditions, geometry, materials, metrics, regimes, uncertainty, and validation where relevant. +- Careful: separate measured results, model predictions, interpretation, and speculation. + +## Abstract Pattern + +Use a dense but logical abstract structure: + +1. Motivation or need: one sentence on the application, scientific problem, or limitation. +2. Gap or challenge: one sentence on what is difficult, unresolved, expensive, unmeasurable, or poorly understood. +3. Approach: one or two sentences naming the experimental, numerical, modeling, AI/ML, or diagnostic method. +4. Validation or analysis scope: one sentence on datasets, surfaces, regimes, operating conditions, benchmark comparisons, or validation approach. +5. Key findings: two to four concrete findings with metrics, trends, regimes, or mechanisms. +6. Significance: one final sentence on what the method or result enables. + +Avoid starting the abstract with broad generic statements if a specific research need is available. Avoid ending with only "results are discussed"; end with what is learned or enabled. + +## Introduction Pattern + +Build the introduction as a narrowing funnel: + +1. Establish the application importance and technical need. +2. Define the key thermal-fluid phenomenon or performance metric. +3. Summarize state of the art by category, not paper by paper. +4. Identify what existing approaches have established. +5. State what remains difficult to measure, predict, isolate, generalize, or design. +6. Explain why the gap persists, such as coupled physics, limited diagnostics, expensive CFD, uncertain boundary conditions, scale mismatch, or insufficient data. +7. Introduce the present work as a targeted response to that gap. +8. Preview the main methods and contributions in a compact final paragraph. + +Use "However" and "Nevertheless" to pivot from importance or prior work to limitations, but make the limitation specific. Do not use novelty as "no prior work exists"; explain why the missing work is important and challenging. + +## Contribution Paragraph + +At the end of the introduction, include a contribution paragraph that answers: + +- What is developed, measured, modeled, or demonstrated? +- What data, regimes, surfaces, geometries, or systems are studied? +- What comparisons or validation are performed? +- What physical insight or practical capability is obtained? + +Prefer concrete contribution verbs: + +- develops +- validates +- quantifies +- compares +- demonstrates +- reveals +- identifies +- establishes +- enables + +Avoid vague verbs such as "explores" unless the work is explicitly exploratory. + +## Methods Pattern + +Write methods so the reader can reproduce or audit the work. + +For experiments, include: + +- facility overview and figure reference; +- sample/material preparation; +- operating conditions and procedure; +- sensors, locations, sampling rates, calibration, synchronization, and uncertainty; +- data-reduction equations and property sources; +- repeatability, number of tests, and steady-state or transient criteria. + +For modeling or simulation, include: + +- governing equations or objective function; +- assumptions and justification; +- boundary and initial conditions; +- geometry and parameter definitions; +- numerical method, mesh, convergence, and validation; +- outputs and post-processing metrics. + +For AI/ML papers, include: + +- dataset source and split strategy; +- raw input representation; +- preprocessing and feature extraction; +- model architecture and baseline models; +- training details only to the extent needed for reproducibility; +- metrics tied to the engineering task; +- generalization and failure-case analysis. + +## Results And Discussion Pattern + +Write results as a sequence of figure-led arguments. + +For each major figure or table: + +1. Orient: "Fig. X shows..." with variables, conditions, cases, and uncertainty representation. +2. Observe: state the main trend, regime, threshold, error pattern, or comparison. +3. Quantify: provide key values, relative changes, slopes, errors, or performance metrics when useful. +4. Explain: connect the observation to physical mechanisms, model structure, measurement effects, or data features. +5. Compare: relate to literature, baseline cases, simulations, correlations, or other surfaces/regimes. +6. Imply: state what this means for the research question, design guidance, measurement capability, or next analysis. + +Use transition sentences to make the analysis cumulative: + +- "To understand the role of..." +- "To isolate the effect of..." +- "To validate the model..." +- "To examine whether this trend generalizes..." +- "This observation indicates..." +- "These results suggest..." + +Do not present plots as isolated results. Each figure should either answer a question, motivate the next analysis, or close a gap from the introduction. + +## Baseline To Generalization + +Start results with a representative baseline case when the work includes experiments, simulations, image analysis, acoustic signals, or ML workflows. + +Use the baseline to demonstrate: + +- raw data and processed metrics; +- event definitions, regimes, or labels; +- calculation or model pipeline; +- uncertainty and sanity checks; +- how to read later figures. + +Then generalize through parametric studies, repeated tests, design comparisons, or literature benchmarks. + +## Model And AI/ML Result Style + +When writing about models or AI/ML tools, avoid treating accuracy as the final contribution. + +Use this sequence: + +1. State the prediction, reconstruction, classification, segmentation, or surrogate task. +2. Explain why the task matters physically or practically. +3. Compare model types, data representations, sequence lengths, feature extraction methods, or training regimes. +4. Report metrics with engineering interpretation. +5. Analyze error distribution, regime dependence, failure cases, or latent variables. +6. Connect the model output to physical features, thermal resistance, heat flux, bubble dynamics, interface motion, or design parameters. +7. State what the model enables: faster design, nonintrusive measurement, real-time monitoring, mechanism identification, or reduced experimental/CFD burden. + +When discussing latent spaces, modes, or features, explicitly connect them to recognizable physical behavior. + +## Literature Comparison Inside Results + +Use literature comparison to establish generality or positioning, not as decoration. + +- Compare against correlations, prior datasets, benchmark surfaces, standard methods, or reported ranges. +- Explain differences through geometry, regime, fluid, material, diagnostic method, or data reduction. +- State whether the present result confirms, extends, or challenges prior understanding. +- If performance is not better than literature, identify the actual contribution, such as measurement access, transient behavior, multimodal data, model interpretability, uncertainty quantification, or practical implementation. + +## Sentence-Level Preferences + +Prefer compact method-result sentences: + +```text +The model is validated against X and then used to investigate Y. +``` + +```text +Rahman et al. used X to demonstrate Y. +``` + +Avoid redundant pairs: + +```text +Rahman et al. studied X. Their results showed Y. +``` + +Use "indicates" for evidence-supported interpretation, "suggests" for weaker inference, and "demonstrates" only when the evidence directly supports the claim. + +Use "due to" or "because" only when the mechanism is supported. Otherwise use "may be attributed to" or "is likely associated with." + +## Conclusion Pattern + +Conclusions should be compact, specific, and cumulative. + +Use this structure: + +1. Re-state what was developed, measured, modeled, or demonstrated. +2. Summarize the main quantitative or qualitative findings. +3. State the mechanism or interpretation. +4. State the practical or scientific implication. +5. Optional: note limitations and future work if important. + +For multi-result papers, numbered conclusions are effective. Each numbered item should contain a complete takeaway, not just a topic label. + +Avoid broad restatement of the introduction. The conclusion should tell the reader what is now known because of this work. + +## Manuscript Self-Check + +Before finalizing a paper draft, check: + +- Does the abstract move from need to gap to method to findings to significance? +- Does the introduction narrow from application to gap to present contribution? +- Are background references grouped by category and key papers discussed selectively? +- Does each methods subsection include enough detail for audit or reproduction? +- Are assumptions stated before model use? +- Does the results section start from a baseline or representative case when appropriate? +- Does each figure discussion include observation, mechanism, and implication? +- Are model or AI results interpreted physically rather than only statistically? +- Does the conclusion state concrete findings rather than rephrasing the abstract? diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/presentation-slides.md b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/presentation-slides.md new file mode 100644 index 00000000..35065b02 --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/presentation-slides.md @@ -0,0 +1,204 @@ +# Research Presentation Slides + +Use this reference when creating or revising research presentations, slide outlines, slide content, speaker notes, animation plans, or visual-story plans. + +## Core Principle + +Design slides and spoken narration as complementary parts of one argument. + +Slides should show the evidence, structure, and take-home message. The presenter should explain the logic, transitions, mechanisms, and implications. Do not make the presenter read slide text aloud. + +## Logic Flow + +Build the presentation so the audience can anticipate the next slide. + +- Each slide should answer a question raised by the previous slide or prepare the audience for the next question. +- When saying "Slide N," the audience should have a reasonable expectation of what belongs on "Slide N+1." +- Use a clear chain: motivation, gap, approach, method, baseline case, key result, mechanism, comparison, implication, conclusion, next step. +- Avoid abrupt topic jumps. If a jump is necessary, add a transition slide or visual bridge. + +For each slide, define: + +- The question this slide answers. +- The single take-home message. +- The figure, animation, video, schematic, or data view that carries the message. +- The one sentence the presenter should say to transition to the next slide. + +## Slide Cleanliness + +Make slides feel clean and relaxed. + +- Ensure each content block can be visually wrapped in a rectangle. +- Keep rectangles separated; do not let text, plots, arrows, captions, and images collide. +- Align edges and use consistent margins. +- Use whitespace as structure, not as leftover space. +- Avoid placing small text in corners or squeezing labels into crowded figures. +- Remove decorative elements that do not support the message. + +A quick layout test: if the slide content cannot be divided into a few non-contacting rectangles, simplify the slide or split it into multiple slides. + +## Graphics-Focused Communication + +Prefer graphics over text. + +Use: + +- Schematics to explain systems, mechanisms, geometry, test facilities, and models. +- Figures and plots to show evidence and trends. +- Photos or microscopy images to show samples, hardware, or fabrication. +- Videos or animations to show time-dependent behavior, bubble dynamics, flow, deformation, moving interfaces, or experimental procedures. +- Sequential builds to reveal complex ideas step by step. + +Use text only for information that the visual cannot convey clearly: + +- Key labels. +- Essential assumptions. +- A concise take-home message. +- Critical numbers or comparisons. +- A short note that prevents misinterpretation. + +## Text Discipline + +Keep slides light on text. + +- Use short phrases rather than full paragraphs. +- Prefer one main message per slide. +- Put detailed explanation in speaker notes, not on the slide. +- Avoid copying manuscript text onto slides. +- Do not include text that the presenter will simply read aloud. + +If a slide needs many words, the idea is probably not yet visualized well enough. + +## Speaker Notes + +Write speaker notes to complement the slide. + +Speaker notes should: + +- Explain the transition from the previous slide. +- Describe what the audience should notice in the figure. +- Add physical explanation, context, and implications. +- Mention caveats or details that would clutter the slide. +- End with a bridge to the next slide. + +Speaker notes should not duplicate the exact slide text. + +## Technical Research Talk Structure + +Use this structure as a default for thermal-fluid research talks: + +1. Motivation: Why the application or scientific question matters. +2. State of the art: What is known and what remains unresolved. +3. Gap or challenge: Why the issue remains difficult. +4. Proposed approach: What method, diagnostic, model, or experiment addresses the gap. +5. Facility or model overview: Show the system visually. +6. Baseline case: Demonstrate the analysis workflow on one representative case. +7. Key results: Show the most important trends through figures. +8. Mechanism: Explain the physics behind the trends. +9. Literature comparison: Position the result against existing work. +10. Impact: State what is now understood, enabled, or improved. +11. Conclusions and next steps: Give a compact set of takeaways and future work. + +Adjust the structure for the audience. For expert audiences, shorten broad motivation and add more mechanism, uncertainty, and comparison. For general audiences, add more schematics and reduce equations. + +## Group Presentation Style Patterns + +When preparing talks in the style of the provided thermal-fluid conference examples, prefer this rhythm: + +1. Title slide with speaker, collaborators, institution, conference/session identifier, and a precise technical title. +2. Motivation slide that ties the topic to applications using recognizable systems, photos, or schematics. +3. Background physics slide that introduces the key phenomenon, regime transition, metric, or bottleneck visually. +4. Research-question slide that states a small number of concrete questions the talk will answer. +5. Experimental setup, model system, or data-source slide that makes the workflow visually inspectable. +6. Representative raw-data or baseline-case slide that shows what was measured before showing processed trends. +7. Regime, mechanism, or analysis-pipeline slide that explains how raw data becomes interpretable events or metrics. +8. Parametric result slides that vary one meaningful factor at a time and preserve visual comparability. +9. Mechanism or synthesis slide that turns observations into physical understanding. +10. Literature or benchmark comparison slide when positioning, generalizability, or contribution needs support. +11. Conclusions slide with concise takeaways, sponsors, team, and acknowledgments as appropriate. +12. Backup slides for detailed equations, material-property tables, additional curves, sensitivity checks, or derivations. + +Use slide numbers unobtrusively when helpful for conference navigation and discussion. + +## Baseline And Raw-Data Slides + +Include at least one slide that shows representative raw data, raw images/video, or the baseline case before polished aggregate plots. + +Use this slide to: + +- Build trust in the measurements or simulations. +- Demonstrate synchronization, event labels, regimes, or extracted metrics. +- Show how the audience should read later processed results. +- Introduce the visual language used later, such as colors, symbols, regimes, or annotations. + +For boiling, two-phase, IR, acoustic, or image-sequence work, use videos, time traces, thermographs, spectrograms, event labels, or side-by-side raw/processed views when available. + +## Visual Comparability Across Result Slides + +For parameter studies, preserve visual comparability. + +- Keep axis limits, color meanings, marker meanings, and panel layout consistent across related slides. +- Use repeated slide structure when comparing pressure, surface structure, flow rate, inlet temperature, material, or model dimension. +- Reveal differences by changing the data, not by changing the visual grammar. +- Use compact annotations such as arrows, regime labels, or highlighted regions to direct attention to the comparison. + +If a slide series compares multiple cases, make each slide answer one comparison question and use the transition sentence to explain why the next case follows. + +## Media-Rich Mechanism Slides + +Use embedded videos, GIFs, or sequential frames for transient and spatial phenomena. + +Good candidates include: + +- Boiling regime transitions. +- Bubble departure, interface motion, vapor-film growth, or return to nucleate boiling. +- IR temperature fields and time histories. +- Acoustic or hydrophone signals synchronized with physical events. +- ML tracking outputs, segmentation masks, IDs, or model predictions over time. + +Pair videos with a minimal schematic, trace, or label that tells the audience what to watch. Avoid asking the audience to infer the point from motion alone. + +## Backup Slides + +Use backup slides deliberately. + +Put detailed material-property tables, derivations, additional validation plots, alternate cases, and extra comparison figures in backup rather than crowding the main talk. Main slides should carry the story; backup slides should support Q&A. + +## Figure Slides + +For each figure slide, use the same four-level thinking as results writing: + +1. Description: What is shown? +2. Observation: What should the audience notice? +3. Physical explanation: Why does it happen? +4. Significance: Why does it matter for the research question? + +The slide should usually show description and take-home message. The presenter should provide observation, physical explanation, and significance verbally unless short annotations are needed. + +## Animation And Video + +Use animations and videos to reveal logic, not to decorate. + +Good uses include: + +- Building a schematic from components to full system. +- Revealing one mechanism at a time. +- Showing experimental procedure or flow path. +- Comparing before/after states. +- Synchronizing data traces with physical events. +- Highlighting how a metric is extracted from raw data. + +Avoid animations that slow the talk without improving understanding. + +## Review And Revision Checklist + +Before finalizing a presentation, check: + +- Can the audience predict why the next slide follows from the current slide? +- Does each slide have one main message? +- Is the slide mostly carried by graphics, figures, videos, or animations? +- Can each content block be wrapped in a clean rectangle without touching another block? +- Is all text necessary, short, and complementary to the presenter? +- Are speaker notes explaining rather than repeating the slide? +- Are complex methods or results introduced first through a baseline case or visual demo? +- Does the talk end with clear takeaways rather than a dense summary slide? diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/proposal-development.md b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/proposal-development.md new file mode 100644 index 00000000..62da00e6 --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/proposal-development.md @@ -0,0 +1,231 @@ +# Federal Research Proposal Development + +Use this reference for DOE EPSCoR, NSF, NASA, National Laboratory partnership proposals, pre-application expansion, review-criteria response, and ready-to-submit technical narratives in mechanical engineering, thermal-fluid systems, power electronics, reliability, diagnostics, and AI/ML-enabled research. + +## Core Principle + +Build the proposal around the solicitation, the review criteria, and the investigators' own intellectual work. A strong proposal is not a long technical essay. It is a controlled argument that establishes importance, synthesizes the state of the art, identifies gaps, states objectives and hypotheses, explains methods, substantiates feasibility with preliminary results, defines measurable success, and proves that the team and collaboration can execute the work. + +Use AI only as proposal-development support. Preserve the investigators' scientific direction, original technical content, preliminary results, and final responsibility. If the solicitation requires AI disclosure, flag the requirement and suggest wording for institutional review. + +## Solicitation-First Workflow + +1. Read the solicitation before drafting. + - Extract deadline, page limits, font/margin rules, required sections, required attachments, eligibility rules, budget restrictions, National Lab rules, data-management requirements, AI-disclosure language, and review criteria. + - If a specific PDF or NOFO is provided, use it as the controlling source rather than generic grant-writing advice. + - Track whether references, appendices, biosketches, current and pending support, budget justification, data management plans, letters, and optional attachments have separate page limits. + +2. Build a compliance checklist. + - Include narrative page limit and formatting. + - Include all collaborator documents, letters, institutional commitments, and data-management attachments. + - Note budget restrictions such as whether National Laboratory partners may receive funds. + - Identify who must provide biosketches, current and pending support, collaborator/affiliation information, senior/key-personnel documents, facilities/equipment descriptions, and letters of commitment. + +3. Map the proposal to review criteria. + - Treat review criteria as questions that the proposal must answer explicitly. + - For DOE-style criteria, cover scientific/technical merit, method/approach, personnel/resources, budget reasonableness, data management, and likelihood of collaboration success. + - Add subsection-level sentences that make the answers visible without turning the narrative into a checklist. + +4. Use pre-application feedback as design input. + - Preserve encouraged directions from the pre-application. + - Expand the scientific foundation, methods, preliminary results, milestones, and collaboration plan. + - Do not simply inflate the pre-application; convert it into a full argument with literature, figures, methods, risks, and metrics. + +## Narrative Architecture + +When the solicitation suggests Background/Introduction, Project Objectives, and Proposed Research and Methods, follow that structure unless the user explicitly chooses another one. + +### 1. Background/Introduction + +This section should explain importance, relevance, and literature context. It should not become a preliminary-results dump. + +Use this flow: + +1. Establish why the problem matters for DOE, NSF, NASA, industry, safety, resilience, energy efficiency, reliability, or fundamental science. +2. Review the state of the art by mechanism, method, or system class. +3. Cite seminal work, recent state-of-the-art papers, high-impact reviews, standards, and team-relevant papers. +4. Identify gaps that remain after the literature is fairly represented. +5. Explain why the gaps persist: coupled physics, missing diagnostics, scale mismatch, difficult measurements, limited models, lack of benchmark data, weak transferability, or insufficient collaboration access. +6. End with the opportunity that the proposed project will address. + +For mature fields, target a selective and balanced reference set rather than every paper found. For a full DOE-style narrative, a working development draft may use 50-60 references, then compress the in-text review for page limits and move references to the required appendix if allowed. + +### 2. Project Objectives + +Use one overall goal when multiple objectives are interdependent. + +Pattern: + +- **Overall goal:** Establish what the project will create, validate, or discover. +- **Objective 1:** Experimental or observational characterization. +- **Objective 2:** Theory, modeling, mechanism interpretation, or computational framework. +- **Objective 3:** Predictive tool, design rule, diagnostic method, validation, or translational outcome. + +Keep objectives concise. Avoid burying task descriptions, milestones, and preliminary results in this section. Objectives should map clearly to thrusts or aims in the research plan. + +### 3. Proposed Research and Methods + +This section should identify hypotheses, methods to test them, and integration of experiments with theory, modeling, computation, or data science. + +Start with: + +- Central hypothesis or scientific premise. +- Thrust-level hypotheses when useful. +- Explanation of how experiments, theory/modeling, computation, and data analytics interact. + +For each thrust or aim, include: + +- Objective. +- Hypothesis tested. +- Tasks. +- Methods for each task. +- Preliminary data that demonstrates feasibility and expertise. +- Expected outcomes. +- Quantifiable completion and success metrics. +- Risks and alternatives, especially for weak signals, noisy data, uncertain labels, failed hardware, or modeling mismatch. + +Do not isolate preliminary results in a long standalone section unless the solicitation asks for it. In most research narratives, preliminary results are strongest when embedded under the task they justify. For each preliminary result, state what capability it proves and what remaining question motivates the proposed work. + +## Literature Review Strategy For Proposals + +Use the literature review to make a case, not to show that many papers were found. + +Cover four categories: + +1. **Seminal sources:** papers, standards, textbooks, or reports that established the mechanism, diagnostic method, model, or governing concept. +2. **High-impact reviews or most-cited papers:** sources that define the current state of the field and accepted challenges. +3. **Most-recent work:** papers from the last 1-3 years, especially where the field is moving quickly. +4. **Team publications:** PI, Co-PI, collaborator, and National Lab papers that demonstrate expertise directly related to the work plan. + +When the user provides Google Scholar profiles or publication lists: + +- Use them to identify team publications, but verify final citation details through publisher pages, university pages, lab repositories, DOI records, OSTI, NSF public access, or other stable sources. +- Cite team papers strategically where they substantiate capability: prior hardware, modeling, sensing, datasets, algorithms, facilities, standards experience, or National Lab relevance. +- Avoid overciting the team at the expense of field-leading external experts. + +For a proposal on physics-informed acoustic diagnostics for power electronics reliability, organize literature around mechanisms: + +- Wide-bandgap/SiC power electronics, packaging, and reliability. +- Partial discharge physics, standards, and nonconventional detection. +- Acoustic emission sensing for PD, source localization, propagation, and limitations. +- Thermal management, direct cooling, dielectric fluids, two-phase cooling, and electrical reliability. +- Acoustic sensing and AI/ML for boiling, condensation, bubble dynamics, and phase-change diagnostics. +- Physics-informed machine learning, transferability, uncertainty, and health-state estimation. + +The gap should follow naturally: existing work does not yet connect mechanism-labeled acoustic signatures to coupled electrical, thermal, mechanical, and cooling degradation in compact grid-relevant power electronics with synchronized reference data and transfer-tested diagnostics. + +## Preliminary Results Integration + +For each thrust, use preliminary results to answer three reviewer questions: + +1. Why is the proposed work plausible? +2. What expertise, hardware, data, or analysis capability does the team already have? +3. What remains unknown enough to justify the new research? + +Good preliminary-result placement: + +- A PD/acoustic-camera result belongs in a discharge-characterization task. +- A PDIV spectral-analysis result belongs in a task about distinguishing PD from artifacts. +- A SiC junction-temperature ML result belongs in thermal/package health monitoring or multimodal diagnostics. +- A boiling, hydrophone, bubble, or dielectric-fluid result belongs in cooling-instability acoustics. +- A flow-boiling/condensation acoustic ML result belongs in physics-informed acoustic feature extraction and diagnostic transferability. + +Write preliminary-results paragraphs in this pattern: + +1. State the result and conditions. +2. State the measured outcome or performance. +3. Explain what capability it demonstrates. +4. Identify the limitation or unanswered question. +5. Connect directly to the proposed task. + +## Figures In Proposal Narratives + +Use figures as evidence, not decoration. + +Figures should: + +- Show preliminary data, testbeds, mechanism maps, workflow diagrams, or milestones. +- Be embedded near the text that uses them. +- Have captions that state the result, relevance, and proposed-work connection. +- Be legible at final page size. +- Avoid vague stock imagery or purely atmospheric visuals. + +For a 15-page narrative, use a small number of high-value figures. Candidate figure types include: + +- Preliminary PD/acoustic localization and hydrophone/bubble results. +- SiC module thermal-state estimation result. +- Immersion-cooling boiling and dielectric-strength result. +- AE phase-change or condensation diagnostic result. +- Spectral AE PDIV processing result. +- Integrated experiment-model-ML workflow diagram. +- Four-year timeline and milestone table. + +## Quantifiable Milestones + +Milestones should allow reviewers and program managers to evaluate completion and success. Avoid vague milestones such as "develop model" or "analyze data" without metrics. + +Examples of measurable metrics: + +- Number of source-class datasets. +- Number of geometries, operating conditions, repeats, or coupled-stressor cases. +- Synchronization accuracy, sampling rate, signal-to-noise threshold, calibration completion, or metadata completeness. +- Agreement between predicted and observed trend direction. +- Error metrics such as MAE, MAPE, RMSE, R2, classification accuracy, macro-F1, precision/recall, or uncertainty calibration. +- Improvement relative to a baseline, such as amplitude-threshold AE detection. +- Transfer performance across geometry, sensor placement, coolant condition, or operating regime. +- Number of student trainees, technical meetings, manuscripts, datasets, code packages, or National Lab reviews. + +For each year, define major activities and quantifiable milestones. Include a final end-to-end demonstration with clear success criteria. + +## National Lab And Collaboration Planning + +For National Lab partnership proposals: + +- Clarify whether National Lab collaborators are senior/key personnel or unfunded collaborators based on solicitation definitions and their substantive intellectual role. +- If they design experiments, interpret data, mentor students, or shape the research plan, assume they may need senior/key-personnel-style documents unless the solicitation or program officer says otherwise. +- Identify required documents: letters of commitment, biosketches, current and pending support, collaborator/affiliation information, facilities descriptions, and institutional approvals. +- Check whether funds can flow to the National Lab. Some EPSCoR lab-partnership programs do not fund labs directly. +- Describe collaboration mechanics: meeting cadence, student mentoring, milestone reviews, facility or expertise access, data-sharing boundaries, and how lab feedback changes the work plan. + +Letters should be specific. A strong National Lab letter confirms the collaborator's role, expertise, commitment of time or engagement, student mentoring, technical review plan, and alignment with DOE mission needs. A strong institutional or jurisdiction commitment letter confirms institutional support, cost share or resources if applicable, facilities, administrative support, and commitment to building EPSCoR capacity. + +If a jurisdiction letter is unclear, distinguish among: + +- University institutional commitment. +- State EPSCoR jurisdiction or committee commitment. +- Department/college commitment. +- National Lab letter of commitment. + +Ask the research office or program officer when the solicitation language is ambiguous. + +## Ready-To-Submit Polish + +Before calling a proposal ready: + +- Confirm the narrative follows the solicitation's required or suggested structure. +- Replace bullet-heavy draft text with complete sentences and continuous paragraphs, except where tables or milestone lists are more effective. +- Ensure every objective has tasks, methods, preliminary basis, expected outcomes, risks, and measurable metrics. +- Cite references in the text and include a complete reference list in the correct appendix or section. +- Embed figures and verify captions, numbering, and cross-references. +- Check that the literature review is comprehensive enough to identify gaps, but compressed enough for page limits. +- Make review-criteria answers visible throughout the proposal. +- Verify senior/key-personnel documents, letters, DMSP, budget justification, facilities, and institutional commitment. +- Check page length with final formatting, not markdown word count. +- Flag AI-disclosure requirements for institutional review. + +## Common Iteration Pattern + +A practical proposal-development sequence is: + +1. Answer compliance and collaborator-document questions. +2. Expand the pre-application into a full narrative. +3. Integrate preliminary results from prior proposals, manuscripts, reports, and figures. +4. Align the draft to review criteria. +5. Convert the outline into the solicitation's required section architecture. +6. Add hypotheses, task-level methods, and experiment-model-computation integration. +7. Replace vague milestones with quantitative success metrics. +8. Add references and figure placeholders. +9. Expand the literature review with seminal, most-cited, recent, and team-specific papers. +10. Compress and polish for final page limits and submission formatting. + +At each iteration, preserve prior drafts with versioned filenames when feasible so the user can compare structure and content choices. diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/research-coding.md b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/research-coding.md new file mode 100644 index 00000000..2cbb5f2c --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/research-coding.md @@ -0,0 +1,212 @@ +# Research Coding Guidelines + +Use this reference when writing, reviewing, or refactoring code for thermal-fluid research, data analysis, plotting, simulation automation, CFD post-processing, machine learning, or reproducible research workflows. + +## Core Principle + +Write research code so that another researcher can understand what physical question is being answered, reproduce the result, and safely modify the analysis later. + +Research code should be: + +- Traceable from raw data to final figure or metric. +- Explicit about units, assumptions, constants, and data sources. +- Modular enough to reuse on multiple cases without copy-paste editing. +- Simple enough that the analysis logic remains inspectable. +- Reproducible through documented inputs, parameters, environment, and outputs. + +## Start From The Research Question + +Before writing code, define: + +- What physical quantity, trend, metric, or figure the code must produce. +- What raw inputs are required. +- What assumptions and constants are used. +- What units are expected at each stage. +- What validation or sanity check should pass. + +Avoid writing a large generic pipeline before validating the analysis on a baseline case. + +## Baseline-First Implementation + +Implement the full workflow on one representative baseline case before scaling to many cases. + +For the baseline case, show: + +- Raw input inspection. +- Preprocessing steps. +- Intermediate quantities. +- Final figure or metric. +- Sanity checks and likely failure modes. + +After the baseline case works, generalize the code to batches, parameter studies, or automated reports. + +## Repository And File Organization + +Prefer a clear project structure: + +```text +project/ + README.md + data/ + raw/ + processed/ + scripts/ + src/ + notebooks/ + figures/ + results/ + config/ + tests/ +``` + +Use `data/raw/` as read-only input when possible. Write generated files to `data/processed/`, `figures/`, or `results/`. + +Keep paths configurable. Avoid hard-coded absolute paths unless the script is explicitly personal or one-off. + +## Data Processing + +Make each processing step explicit. + +- Load raw data without silently changing it. +- Validate column names, units, shapes, time bases, and missing values. +- Convert units near the data-loading boundary and document the conversion. +- Keep filtering, smoothing, thresholding, interpolation, and fitting choices visible. +- Save processed data with metadata describing the processing settings. +- Do not overwrite raw data. + +For time-series data, record sampling rate, synchronization, trigger times, time windows, filters, and event definitions. + +For image/video data, record frame rate, resolution, calibration, field of view, preprocessing, segmentation thresholds, labels, and tracking rules. + +## Plotting Code + +Plots should communicate the mechanism or comparison. + +- Put plotting settings in reusable functions when many figures share style. +- Label axes with variable names and units. +- Use legends, colors, markers, and line styles consistently across related figures. +- Include uncertainty where available. +- Export publication-quality figures with deterministic filenames. +- Save both editable and presentation-ready formats when useful. + +Separate the calculation of plotted data from the formatting of the figure. This makes the analysis easier to verify. + +## Functions And Scripts + +Use functions for repeated research logic: + +- property calculations +- dimensionless numbers +- heat-transfer correlations +- uncertainty propagation +- data loading and cleaning +- feature extraction +- plotting common figure types + +A script should have a clear entry point, explicit inputs, and predictable outputs. + +For Python scripts, prefer: + +```python +def main(): + ... + +if __name__ == "__main__": + main() +``` + +## Notebooks + +Use notebooks for exploration, explanation, and interactive analysis. + +For final or repeatable workflows: + +- Move reusable functions into scripts or `src/`. +- Restart and run the notebook from top to bottom before sharing. +- Keep cells in logical order. +- Avoid hidden state that only works after manual cell execution. +- Include enough markdown to explain the analysis choices. + +## Physical Sanity Checks + +Every analysis should include physics checks when possible: + +- Units and dimensional consistency. +- Order-of-magnitude estimates. +- Energy, mass, or momentum balance. +- Monotonicity or limiting behavior expected from theory. +- Comparison to known correlations, baseline data, or literature. +- Bounds on efficiencies, heat fluxes, velocities, pressures, and temperatures. + +If a result violates expected physics, investigate before polishing the figure. + +## Simulation And CFD Automation + +When automating simulations, record: + +- Geometry parameters. +- Mesh settings and mesh version. +- Boundary conditions. +- Solver settings. +- Convergence criteria. +- Material properties. +- Output quantities. +- Case naming convention. + +Do not mix setup generation, solver execution, post-processing, and plotting into one opaque script unless the workflow is very small. Prefer clear stages with saved intermediate outputs. + +For surrogate modeling or design exploration, store the design matrix, parameter bounds, and train/test split. + +## Machine Learning Code + +Make ML code reproducible and physically interpretable. + +- Fix random seeds when appropriate. +- Prevent leakage across experiments, videos, geometries, surfaces, pressures, or simulation families. +- Save preprocessing settings, model configuration, weights, and metrics. +- Include baseline models before complex models. +- Inspect failure cases visually or physically. +- Report metrics by regime or condition when aggregate metrics hide important behavior. + +Connect model performance back to the thermal-fluid question. Accuracy alone is not the scientific contribution. + +## Configuration And Metadata + +Use configuration files or clearly named parameters for: + +- input paths +- case IDs +- fluid and material properties +- calibration constants +- thresholds and fitting windows +- plot style +- model hyperparameters + +Save metadata with outputs so figures and tables can be traced back to the code and data that produced them. + +## Testing And Validation + +Use lightweight tests for critical functions: + +- unit conversions +- dimensionless numbers +- correlations +- uncertainty propagation +- data parsers +- event detection logic + +For research code, a small set of sanity tests is often more valuable than no tests. Include regression checks for baseline outputs when the analysis will be reused. + +## Code Review Checklist + +Before considering research code ready, check: + +- Can a new user identify the raw inputs, outputs, and main entry point? +- Are units and assumptions explicit? +- Is raw data preserved? +- Can the baseline case be reproduced? +- Are figures traceable to scripts and processed data? +- Are hard-coded paths, magic numbers, and hidden notebook state avoided or documented? +- Are physical sanity checks included? +- Are failure modes or limitations stated? +- Is the code simple enough to audit? diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/research-toolchain.md b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/research-toolchain.md new file mode 100644 index 00000000..f17129eb --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/research-toolchain.md @@ -0,0 +1,103 @@ +# Research Toolchain: Overleaf, VS Code, GitHub, And Git + +Use this reference when a research task involves the recurring tools around manuscripts, code, collaboration, version control, and archival release. Keep tool advice practical and tied to the research deliverable. + +## Tool Roles + +- Overleaf: collaborative LaTeX writing, editing, comments, tracked changes, bibliography management, journal/conference templates, and final manuscript packaging. +- VS Code: coding, debugging, notebook/script development, environment management, linting/formatting, testing, plotting, and local data-processing workflows. +- GitHub: remote repository hosting, issue/PR collaboration, README documentation, release pages, DOI/archive integrations, reproducibility packages, and public/private sharing. +- git: local version control, branches, commits, diffs, tags, release snapshots, rollback points, and provenance for research changes. + +## Default Research Workflow + +1. Define the deliverable. + - Manuscript, response letter, code repo, dataset package, release archive, presentation, report, or patent/commercialization support. + - Identify what must be versioned: text, code, figures, raw data pointers, processed data, environment files, and outputs. + +2. Keep source-of-truth boundaries clear. + - Use Overleaf as the source of truth for LaTeX manuscript text when writing collaboratively. + - Use GitHub/git as the source of truth for code, scripts, documentation, computational figures, and release snapshots. + - Do not duplicate manuscript sections across Overleaf and repo files unless there is an explicit export/sync convention. + +3. Connect manuscript and code artifacts. + - Put reproducible figure-generation scripts in the repo. + - Use stable figure filenames that match manuscript references. + - Record commit hashes, release tags, dataset versions, and environment files for results used in the manuscript. + - Keep large raw data outside git unless the repository intentionally uses a data-management system. + +4. Version before major changes. + - Commit before risky refactors, major manuscript restructuring, new analysis pipelines, or camera-ready submission changes. + - Use branches for exploratory work and PRs for reviewable changes. + - Use tags/releases for submitted, revised, accepted, archived, or published states. + +## Overleaf Guidance + +When helping with Overleaf manuscripts: + +- Preserve journal/conference template structure unless there is a clear reason to change it. +- Keep edits compatible with LaTeX: avoid smart quotes, hidden Unicode, fragile manual spacing, and unnecessary package churn. +- Suggest section-level edits that maintain a clear logic flow: motivation, gap, method, evidence, implication. +- Use comments or change summaries for scientific rationale, missing citations, unclear assumptions, or figure/text mismatch. +- Coordinate citations through `.bib` entries and consistent citation keys. +- For revisions, maintain a response-letter mapping between reviewer comment, manuscript change, and location. +- For final packaging, check figures, captions, references, supplementary files, and source files expected by the venue. + +## VS Code Guidance + +When helping with VS Code coding/debugging: + +- First identify the language, environment, run command, tests, and expected output. +- Prefer repo-local environment files such as `requirements.txt`, `environment.yml`, `pyproject.toml`, `package.json`, or launch configs. +- Use debugging to isolate the smallest failing case: reproduce, inspect inputs, check dimensions/units, then patch. +- Keep scripts reproducible from the command line before relying on interactive notebooks. +- For research plots, verify data provenance, units, labels, legends, uncertainty, and export resolution. +- For notebooks, separate exploration from final pipeline code when results need to be reproduced later. + +## GitHub Guidance + +When helping update a research repository: + +- Keep README content accurate for setup, usage, examples, data availability, citation, license, and contact. +- Add a clear repository structure section when onboarding matters. +- Use issues for tasks/questions and PRs for reviewable changes when collaborating. +- Prefer small commits with descriptive messages tied to research intent. +- For archival releases, prepare a clean state with: + - working installation or environment instructions + - tested run commands + - representative input/output examples + - license and citation metadata + - tagged release and changelog/release notes + - DOI/archive link when available +- Avoid committing secrets, private data, unpublished confidential IP details, or large binary outputs unless explicitly intended. + +## Git Guidance + +When advising on git: + +- Check status before editing, staging, committing, pulling, rebasing, or pushing. +- Inspect diffs before staging. +- Stage explicit files when the worktree is mixed. +- Use branches for independent changes: `feature/...`, `fix/...`, `paper/...`, or the local convention. +- Use merge for preserving shared branch history; use rebase only when appropriate and safe for the current collaboration model. +- Tag durable research states, for example `submission-2026-05-13`, `revision-r1`, `accepted`, or `v1.0.0`. +- Write commit messages that explain what changed in research terms, not only tool actions. + +## Recommended Outputs + +For toolchain requests, provide one of: + +- Step-by-step workflow for manuscript/code/repo synchronization. +- Repository cleanup checklist. +- Release/archive checklist. +- Git branch/commit/tag plan. +- VS Code debugging plan. +- Overleaf manuscript revision plan. +- Research reproducibility handoff plan. + +## Guardrails + +- Do not invent access to Overleaf, VS Code, or GitHub if no connector/tool is available. Provide file-level instructions or use available local/GitHub tools. +- Do not expose confidential invention details, unpublished sponsor data, or private datasets in public repositories. +- Do not overwrite user edits or force-push shared branches unless explicitly requested and clearly safe. +- Always distinguish local edits from pushed GitHub changes when reporting status. diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/technical-writing-analysis.md b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/technical-writing-analysis.md new file mode 100644 index 00000000..9910644f --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/skills/mechanical-engineering-research/references/technical-writing-analysis.md @@ -0,0 +1,142 @@ +# Technical Writing, Data Analysis, And Plotting + +Use this reference for manuscript-style thermal-fluid writing, experimental methods, modeling sections, data analysis, figures, and results discussion. + +## Paragraph Logic + +Write each paragraph around one central topic. + +- Put the central topic in the first sentence unless a short transition sentence is needed. +- Make each sentence build on the previous sentence: define the context, add evidence, explain the mechanism, then state the implication. +- Avoid isolated facts that do not advance the paragraph's claim. +- End paragraphs with the consequence, remaining gap, or transition to the next paragraph. + +## Introduction And Background Logic + +Use this order unless the target venue or user request calls for a different structure: + +1. Establish why the research area matters for applications, performance, safety, efficiency, or fundamental understanding, and cite sources. +2. Summarize the state of the art: what has been studied, which approaches dominate, and what is already known. +3. Identify remaining issues, limitations, unresolved mechanisms, measurement gaps, or design barriers. +4. Explain why the issues remain unsolved, such as difficult measurements, limited diagnostics, coupled physics, lack of models, scale mismatch, or limited operating conditions. +5. State the proposed innovation, method, model, measurement, or design that addresses the gap. +6. State the significance and impact: what the innovation enables, clarifies, predicts, improves, or makes measurable. + +Do not write "no prior work has been done on X" as the novelty claim. Lack of prior work does not prove importance. Instead, explain the challenge that limited prior work and how the proposed work overcomes that challenge. + +For background references in introductions, cite by category. Acknowledge broad bodies of work compactly, using category-specific citation groups rather than one sentence per paper or one undifferentiated citation range. For key papers that need prose discussion, use first-author-last-name plus "et al." and avoid long author lists. + +## Experimental Methodology + +Provide enough detail that a technically competent reader can reproduce or audit the work. + +Include: + +- Test facility layout, major components, flow path, heating/cooling path, pressure control, visualization path, and data-acquisition architecture. +- Materials, samples, surface preparation, fabrication recipes, dimensions, suppliers or grades when relevant, cleaning steps, and storage/handling. +- Instrumentation model or class, sensor locations, calibration, sampling rate, resolution, synchronization, and uncertainty. +- Operating procedure, including startup, degassing or conditioning, steady-state criteria, step size, dwell time, shutdown, and repeat tests. +- Data reduction equations, property sources, filtering, segmentation, fitting, uncertainty propagation, and outlier handling. +- Replication details such as number of samples, number of trials per sample, and how mean and standard deviation are reported. + +## Modeling Sections + +List assumptions upfront before deriving or using the model. + +For each assumption, provide: + +- The assumption. +- The physical or empirical justification. +- The expected validity range. +- The consequence if the assumption fails. + +Then present governing equations, boundary conditions, closure relations, material properties, dimensionless groups, numerical method if any, and validation or sanity checks. + +## Data Analysis + +State exactly how raw signals become plotted quantities. + +- Start with a good baseline case. Use it as the detailed proof of concept and the demo case that shows the full analysis pipeline before scaling to parameter studies. +- Define every metric before interpreting it. +- Include equations, units, time windows, thresholds, filters, fitting windows, and normalization. +- Report sample size and uncertainty representation. +- Check whether the trend is robust to reasonable analysis choices. +- Distinguish direct measurement, derived quantity, fitted parameter, and interpretation. + +For thermal-fluid experiments, explicitly check regime, property variation, heat loss, background noise, synchronization, steady-state criteria, and sensor bandwidth. + +## Baseline Case Analysis + +Choose one baseline case that is representative, physically interpretable, and data-rich enough for detailed examination. + +Use the baseline case to: + +- Demonstrate the full data-processing pipeline from raw data to final metrics. +- Show representative signals, images, fields, contours, spectra, or time histories. +- Explain how thresholds, filters, segmentation, fitting windows, and uncertainty estimates are selected. +- Verify conservation laws, scaling expectations, boundary conditions, sensor response, grid convergence, or repeatability as applicable. +- Identify artifacts, noise sources, and limitations before interpreting a larger dataset. +- Establish vocabulary and mechanisms that will be reused in the parameter study. + +Do not skip detailed baseline analysis in favor of only reporting aggregate trends. The baseline case should make the later parametric results credible and easier to interpret. + +## Hypothesis-Driven DOE + +Design experiments, simulations, and parametric studies around hypotheses rather than exhaustive parameter sweeps. + +For each DOE block, state: + +- The hypothesis being tested. +- The physical mechanism behind the hypothesis. +- The input parameters that can isolate or stress that mechanism. +- The output metrics that would support or refute the hypothesis. +- The controls, baseline, and comparison cases. +- The expected outcomes and how each possible outcome would improve understanding. + +Avoid varying every independent parameter over many levels just because the parameters exist. For example, three inputs with ten levels each creates 1000 cases, but this is often an exhaustive search rather than an experiment designed to answer a question. + +A good DOE should be useful whether the hypothesis is confirmed or rejected. If either result would be hard to interpret, redesign the cases to isolate mechanisms, reduce confounding variables, or add diagnostics. + +When many parameters matter, use a staged plan: + +1. Establish the baseline case and validate the analysis workflow. +2. Run targeted single-mechanism cases to test first-order hypotheses. +3. Add interaction cases only where a physical coupling is expected. +4. Use broader sweeps, response surfaces, or optimization only after the dominant mechanisms and useful parameter ranges are known. + +## Plotting + +Make plots support the argument, not merely display data. + +- Choose axes that reveal the mechanism, such as dimensionless groups, normalized variables, inverse length scales, heat flux, superheat, pressure drop, or pumping power. +- Label axes with symbols, names, and units. +- Show uncertainty with error bars, shaded bands, or confidence intervals when data support it. +- Use legends, markers, colors, and line styles that remain distinguishable in grayscale when possible. +- Avoid overfitting trend lines; use a model-based fit only when the model and validity range are stated. +- Include enough caption detail that the plot can be understood without rereading the methods. + +## Results And Figure Discussion + +Discuss figures in four levels: + +1. Description: State what the figure shows, including variables, conditions, samples, and uncertainty representation. +2. Observation: Identify the main trends, thresholds, extrema, slopes, regimes, or anomalies. +3. Physical explanation: Explain the observation using mechanisms, scaling, competing effects, or limiting processes. +4. Literature comparison: Compare the conclusion with existing work, noting whether it is consistent, extends prior understanding, or reveals something not previously reported. + +For multi-panel figures, describe how panels connect instead of treating them as unrelated plots. + +When discussing disagreement with existing work, first check differences in geometry, operating regime, fluid properties, measurement method, uncertainty, and data-reduction definitions. + +## Results Writing Pattern + +Use this sentence-level flow for each major result: + +1. "Figure X shows..." to orient the reader. +2. "It is observed that..." to state the trend. +3. "This trend indicates/suggests..." to interpret the result. +4. "Physically, this can be attributed to..." to explain the mechanism. +5. "This conclusion is consistent with/differs from..." to situate the result relative to prior work. +6. "Therefore..." to state the implication for the research question. + +Avoid claiming novelty only because a trend was not previously reported. State why the new observation matters and what measurement, model, or analysis made it possible. From 90e22649b520fc0c7862aff7894064b52282c8b4 Mon Sep 17 00:00:00 2001 From: Han Hu <72934230+hanhuark@users.noreply.github.com> Date: Thu, 28 May 2026 11:25:01 -0500 Subject: [PATCH 2/3] Add missing workflow command prompts --- .../commands/me-build-slides.md | 20 +++++++++++++++++++ .../commands/me-code-review.md | 20 +++++++++++++++++++ .../commands/me-data-analysis.md | 20 +++++++++++++++++++ .../commands/me-lit-review.md | 20 +++++++++++++++++++ .../commands/me-write-section.md | 19 ++++++++++++++++++ 5 files changed, 99 insertions(+) create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/commands/me-build-slides.md create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/commands/me-code-review.md create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/commands/me-data-analysis.md create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/commands/me-lit-review.md create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/commands/me-write-section.md diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-build-slides.md b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-build-slides.md new file mode 100644 index 00000000..7166d3f0 --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-build-slides.md @@ -0,0 +1,20 @@ +# Thermal-Fluid Research Presentation + +Use `mechanical-engineering-research` to build a graphics-first research presentation. + +Workflow: + +1. Define the audience, time limit, and single central message. +2. Build a slide-to-slide logic chain where each slide prepares the next. +3. Use figures, videos, schematics, animations, and baseline raw-data slides as the primary communication layer. +4. Keep text minimal and reserve it for take-home messages, labels, and caveats. +5. Write speaker notes that complement the slides rather than repeating them. +6. Place derivations, dense tables, and extra comparisons in backup slides. + +Expected output: + +- slide-by-slide outline +- visual plan for each slide +- take-home message per slide +- speaker-note bullets +- backup-slide list diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-code-review.md b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-code-review.md new file mode 100644 index 00000000..14d2006b --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-code-review.md @@ -0,0 +1,20 @@ +# Thermal-Fluid Research Code Review + +Use `mechanical-engineering-research` to write, review, or refactor research code. + +Workflow: + +1. Identify the research question and expected outputs. +2. Verify the baseline case is reproducible from raw inputs. +3. Check units, assumptions, constants, paths, metadata, and raw-data preservation. +4. Separate data processing, analysis, plotting, and simulation/ML execution when practical. +5. Add sanity checks based on physics, conservation laws, known correlations, or benchmark cases. +6. Confirm figures and tables can be traced back to scripts and processed data. + +Expected output: + +- code review findings or implementation plan +- reproducibility checklist +- suggested project structure +- tests or sanity checks +- next refactor steps diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-data-analysis.md b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-data-analysis.md new file mode 100644 index 00000000..b1798f43 --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-data-analysis.md @@ -0,0 +1,20 @@ +# Thermal-Fluid Data Analysis + +Use `mechanical-engineering-research` to plan or implement experimental, simulation, CFD, or AI-assisted data analysis. + +Workflow: + +1. Start with a representative baseline case. +2. Show the full raw-data to metric or figure pipeline on the baseline case. +3. Define metrics, units, thresholds, filters, fitting windows, uncertainty, and sanity checks. +4. Design hypothesis-driven DOE for experiments or simulations. +5. Avoid broad parameter sweeps until the dominant mechanisms and useful ranges are known. +6. Use plots to reveal mechanisms, not merely display data. + +Expected output: + +- baseline analysis plan +- DOE table or staged case matrix +- processing pipeline +- plotting plan +- validation and sanity checks diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-lit-review.md b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-lit-review.md new file mode 100644 index 00000000..2d207d25 --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-lit-review.md @@ -0,0 +1,20 @@ +# Thermal-Fluid Literature Review + +Use `mechanical-engineering-research` to produce a critical literature review for a thermal-fluid or mechanical engineering topic. + +Workflow: + +1. Define the research question and purpose of the review. +2. Identify seminal work and trace both prior references and citing papers when browsing is available. +3. Group papers by theory, mechanism, method, structure, metric, material, or unresolved challenge. +4. Use professional citation style: first-author last name plus "et al." for prose citations. +5. Treat background references as category-level citations, not one-paper-one-sentence summaries. +6. End each major prior-work group with a limitation, knowledge gap, or motivation for the present work. + +Expected output: + +- literature map +- critical synthesis +- key limitations and gaps +- recommended review figures/tables +- next papers or searches to perform diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-write-section.md b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-write-section.md new file mode 100644 index 00000000..4df3111a --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-write-section.md @@ -0,0 +1,19 @@ +# Thermal-Fluid Technical Writing + +Use `mechanical-engineering-research` to draft or revise a manuscript, proposal, report, or thesis section. + +Workflow: + +1. Identify the section type: introduction, methods, modeling, results, discussion, conclusion, proposal narrative, or response to review criteria. +2. Use clear paragraph logic: one central topic per paragraph, usually in the first sentence. +3. For background sections, move from importance to state of the art, gap, challenge, innovation, and impact. +4. For methods, include facility, procedure, instrumentation, data reduction, uncertainty, and reproducibility details. +5. For modeling, list assumptions upfront and justify each assumption. +6. For results, discuss figures through description, observation, physical explanation, and literature comparison. + +Expected output: + +- polished technical prose +- assumptions and caveats +- citation and evidence notes +- suggested figures or tables if useful From e718f739ca25edc49532fb2ec02d0f06075e0c0f Mon Sep 17 00:00:00 2001 From: Han Hu <72934230+hanhuark@users.noreply.github.com> Date: Fri, 29 May 2026 19:26:41 -0500 Subject: [PATCH 3/3] Add Claude Code metadata to thermal-fluid plugin --- .../.claude-plugin/plugin.json | 13 +++++ .../README.md | 55 +++++++++++++++---- .../commands/me-build-slides.md | 4 ++ .../commands/me-code-review.md | 4 ++ .../commands/me-data-analysis.md | 4 ++ .../commands/me-lit-review.md | 4 ++ .../commands/me-write-section.md | 4 ++ 7 files changed, 77 insertions(+), 11 deletions(-) create mode 100644 plugins/hanhuark/mechanical-engineering-research-skill/.claude-plugin/plugin.json diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/.claude-plugin/plugin.json b/plugins/hanhuark/mechanical-engineering-research-skill/.claude-plugin/plugin.json new file mode 100644 index 00000000..9493fb54 --- /dev/null +++ b/plugins/hanhuark/mechanical-engineering-research-skill/.claude-plugin/plugin.json @@ -0,0 +1,13 @@ +{ + "name": "thermal-fluid-research-workflow", + "description": "Thermal-fluid mechanical engineering research workflow for literature review, technical writing, data analysis, presentations, proposals, research coding, and AI/ML-assisted workflows.", + "version": "0.1.0", + "author": { + "name": "Han Hu", + "email": "72934230+hanhuark@users.noreply.github.com", + "url": "https://github.com/hanhuark" + }, + "homepage": "https://github.com/hanhuark/mechanical-engineering-research-skill", + "repository": "https://github.com/hanhuark/mechanical-engineering-research-skill", + "license": "MIT" +} diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/README.md b/plugins/hanhuark/mechanical-engineering-research-skill/README.md index f51f99d2..7f009a6f 100644 --- a/plugins/hanhuark/mechanical-engineering-research-skill/README.md +++ b/plugins/hanhuark/mechanical-engineering-research-skill/README.md @@ -1,12 +1,13 @@ # Thermal-Fluid Research Workflow Plugin -**A Codex plugin for thermal-fluid mechanical engineering research, proposal development, technical writing, data analysis, research coding, presentations, and AI-assisted workflows.** +**A cross-agent research workflow plugin for thermal-fluid mechanical engineering research, proposal development, technical writing, data analysis, research coding, presentations, and AI-assisted workflows.** -This repository packages the `mechanical-engineering-research` skill as a lightweight workflow plugin. The skill remains the domain judgment layer; the plugin adds a cleaner install target and reusable workflow prompts for common research tasks. +This repository packages the `mechanical-engineering-research` skill as a lightweight workflow plugin. The skill remains the domain judgment layer; the plugin adds cleaner install targets and reusable workflow prompts for common research tasks. -**Works with:** OpenAI Codex plugins and skills +**Works with:** OpenAI Codex plugins/skills and Claude Code plugins/skills [![Plugin](https://img.shields.io/badge/Codex-Plugin-blue?style=for-the-badge)](.codex-plugin/plugin.json) +[![Claude Code](https://img.shields.io/badge/Claude%20Code-Plugin-purple?style=for-the-badge)](.claude-plugin/plugin.json) [![Skill](https://img.shields.io/badge/Codex-Skill-teal?style=for-the-badge)](skills/mechanical-engineering-research/SKILL.md) [![Domain](https://img.shields.io/badge/Domain-Thermal--Fluids-orange?style=for-the-badge)](#capabilities) [![Validation](https://img.shields.io/badge/Plugin-Validated-brightgreen?style=for-the-badge)](#validation) @@ -36,7 +37,7 @@ Use it to help Codex reason more carefully about thermal-fluid research: source ## Quick Install -### From Codex Chat +### OpenAI Codex Ask Codex to install the plugin from GitHub: @@ -75,6 +76,36 @@ Copy-Item -Recurse .\skills\mechanical-engineering-research "$env:USERPROFILE\.c Restart Codex if the skill is not discovered immediately. +### Claude Code + +Claude Code can use the same repository as a plugin because it includes: + +```text +.claude-plugin/plugin.json +skills/mechanical-engineering-research/SKILL.md +commands/*.md +``` + +For local testing, clone the repository and launch Claude Code with the plugin directory: + +```bash +git clone https://github.com/hanhuark/mechanical-engineering-research-skill.git +claude --plugin-dir ./mechanical-engineering-research-skill +``` + +Then invoke the skill or workflow prompts through the plugin namespace: + +```text +/thermal-fluid-research-workflow:mechanical-engineering-research +/thermal-fluid-research-workflow:me-lit-review +/thermal-fluid-research-workflow:me-write-section +/thermal-fluid-research-workflow:me-data-analysis +/thermal-fluid-research-workflow:me-build-slides +/thermal-fluid-research-workflow:me-code-review +``` + +Claude Code should also discover the skill automatically when a task involves thermal-fluid research, mechanical-engineering literature review, manuscript writing, proposal development, research coding, plotting, or presentation planning. + --- ## Capabilities @@ -102,6 +133,8 @@ Restart Codex if the skill is not discovered immediately. mechanical-engineering-research-skill/ .codex-plugin/ plugin.json + .claude-plugin/ + plugin.json commands/ me-build-slides.md me-code-review.md @@ -134,11 +167,11 @@ The `commands/` folder contains reusable workflow prompts that can be copied int | Prompt | Use | |---|---| -| [`me-lit-review.md`](commands/me-lit-review.md) | Critical literature review and gap synthesis | -| [`me-write-section.md`](commands/me-write-section.md) | Manuscript, proposal, report, or thesis-section drafting | -| [`me-data-analysis.md`](commands/me-data-analysis.md) | Baseline-first analysis and hypothesis-driven DOE | -| [`me-build-slides.md`](commands/me-build-slides.md) | Graphics-first research presentations | -| [`me-code-review.md`](commands/me-code-review.md) | Reproducible research code review and refactoring | +| [`me-lit-review.md`](commands/me-lit-review.md) | Critical literature review and gap synthesis; Claude command `/thermal-fluid-research-workflow:me-lit-review` | +| [`me-write-section.md`](commands/me-write-section.md) | Manuscript, proposal, report, or thesis-section drafting; Claude command `/thermal-fluid-research-workflow:me-write-section` | +| [`me-data-analysis.md`](commands/me-data-analysis.md) | Baseline-first analysis and hypothesis-driven DOE; Claude command `/thermal-fluid-research-workflow:me-data-analysis` | +| [`me-build-slides.md`](commands/me-build-slides.md) | Graphics-first research presentations; Claude command `/thermal-fluid-research-workflow:me-build-slides` | +| [`me-code-review.md`](commands/me-code-review.md) | Reproducible research code review and refactoring; Claude command `/thermal-fluid-research-workflow:me-code-review` | --- @@ -218,7 +251,7 @@ python "$env:USERPROFILE\.codex\skills\.system\plugin-creator\scripts\validate_p Commit and push: ```powershell -git add .codex-plugin commands skills README.md CONTRIBUTING.md +git add .codex-plugin .claude-plugin commands skills README.md CONTRIBUTING.md git commit -m "Improve thermal-fluid research workflow plugin" git push ``` @@ -284,7 +317,7 @@ No. For full papers and proposals, use academic-research workflow tools as the p **Can I use this with Claude Code, Cursor, or other agents?** -The core skill is markdown-based and can be adapted manually. The plugin metadata here is Codex-oriented. +Yes for Claude Code. This repository includes `.claude-plugin/plugin.json` and the standard `skills//SKILL.md` structure. Claude Code users can load it with `claude --plugin-dir` or install it through a compatible Claude Code marketplace if listed there. Other agents can adapt the markdown skill manually. **How should I contribute improvements?** diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-build-slides.md b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-build-slides.md index 7166d3f0..0b0ec4ad 100644 --- a/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-build-slides.md +++ b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-build-slides.md @@ -1,3 +1,7 @@ +--- +description: Build a graphics-first thermal-fluid research presentation with slide-to-slide logic, visual plans, speaker notes, and backup-slide structure. +--- + # Thermal-Fluid Research Presentation Use `mechanical-engineering-research` to build a graphics-first research presentation. diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-code-review.md b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-code-review.md index 14d2006b..ee4ff5a2 100644 --- a/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-code-review.md +++ b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-code-review.md @@ -1,3 +1,7 @@ +--- +description: Review or refactor thermal-fluid research code for reproducibility, baseline-case traceability, units, assumptions, physics checks, and publication figures. +--- + # Thermal-Fluid Research Code Review Use `mechanical-engineering-research` to write, review, or refactor research code. diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-data-analysis.md b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-data-analysis.md index b1798f43..2fbc538d 100644 --- a/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-data-analysis.md +++ b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-data-analysis.md @@ -1,3 +1,7 @@ +--- +description: Plan thermal-fluid experimental, simulation, CFD, or AI-assisted data analysis around a baseline case, hypothesis-driven DOE, plotting, and validation checks. +--- + # Thermal-Fluid Data Analysis Use `mechanical-engineering-research` to plan or implement experimental, simulation, CFD, or AI-assisted data analysis. diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-lit-review.md b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-lit-review.md index 2d207d25..627e7ca8 100644 --- a/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-lit-review.md +++ b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-lit-review.md @@ -1,3 +1,7 @@ +--- +description: Develop a critical thermal-fluid or mechanical-engineering literature review with mechanism-based synthesis, citation grouping, and gap identification. +--- + # Thermal-Fluid Literature Review Use `mechanical-engineering-research` to produce a critical literature review for a thermal-fluid or mechanical engineering topic. diff --git a/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-write-section.md b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-write-section.md index 4df3111a..80e9a0c9 100644 --- a/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-write-section.md +++ b/plugins/hanhuark/mechanical-engineering-research-skill/commands/me-write-section.md @@ -1,3 +1,7 @@ +--- +description: Draft or revise thermal-fluid manuscript, proposal, report, or thesis sections with clear paragraph logic, methods detail, assumptions, and figure-led discussion. +--- + # Thermal-Fluid Technical Writing Use `mechanical-engineering-research` to draft or revise a manuscript, proposal, report, or thesis section.