---

name: development-extensions description: "Guides OpenMM maintainer and extension-author work on C++ core APIs, Python wrappers, serialization, plugins, platform kernels, CMake builds, and focused tests." disable-model-invocation: true metadata: disco-role: operating license: MIT, GPL, LGPL

OpenMM Development Extensions

Use this sub-skill when the task is to change or extend OpenMM itself rather than to run ordinary molecular simulations. It is for maintainers and extension authors working on C++ APIs, implementation classes, kernels, plugins, serialization, Python wrapper generation, or build/test triage.

Route by Task

• For repository layout, ownership boundaries, and the public C++ to implementation to kernel call chain, read references/repository-architecture.md.
• For configuring builds, selecting CMake options, wrapper builds, ctest, and Python test candidates, read references/build-test-workflows.md.
• For adding a C++ Force, Integrator, plugin, platform kernel, serialization proxy, or shared CUDA/OpenCL/HIP implementation, read references/plugin-and-platform-development.md.
• For symptoms such as missing platform kernels, plugin load order problems, wrapper build environment variables, serialization compatibility, CMake option mistakes, and ABI/compiler issues, read references/troubleshooting.md.

Boundaries

• Stay here for maintainer workflows: C++ API and implementation edits, platform-specific kernels, plugin registration, serialization proxies, Python wrapper maintenance, CMake build/test layout, and contribution-safe test selection.
• Route normal Python simulation recipes, reporters, checkpoints, and application workflows to ../simulation-workflows/SKILL.md.
• Route force-field XML, ForceField, Modeller, PDB/mmCIF, and modeling data workflows to ../force-fields-modeling/SKILL.md.
• Route user-level custom expression forces and Python CustomIntegrator recipes to ../custom-forces-integrators/SKILL.md; return here only when the user needs a compiled C++ API, kernel, or plugin.
• Route runtime platform choice, precision/performance tuning, and hardware-facing simulation advice to ../platforms-performance/SKILL.md; return here for implementing or debugging platform code.

Maintainer Defaults

• Treat C++ build, plugin, wrapper-generation, and native test commands as checkout/build-tree workflows. Do not present them as safe zero-cost verification unless the user has an existing build tree and asks to run them.
• For a new OpenMM feature, check that the API, implementation, serialization, Python exposure, documentation, and tests are all considered; OpenMM’s contribution guidance expects this breadth for nontrivial features.
• Prefer the Reference platform as the first correctness implementation, then add CPU and Common Compute/GPU implementations where the feature requires them.
• If a useful source helper is mentioned, keep it as reference-only unless it can run independent of an OpenMM checkout/build tree. The maintainer helpers for ctest selection and wrapper generation are intentionally not bundled as runtime scripts because they depend on generated build products and source-tree state.