Use when when you need to understand how a multi-instrument mass spectrometry platform (like mzmine) decides which processing module receives a given dataset based on its declared data type (LC vs. GC vs. IMS vs. MS imaging).
Scanned 9/12/2026
Install to Claude Code
npx -y skills add HolobiomicsLab/asb-skill-collections --skill module-dispatch-architecture-analysis --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Module Dispatch Architecture Analysis?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/holobiomicslab-module-dispatch-architecture-analysis-920c49de)More formats (shields.io, HTML) on the badges page.
---
name: module-dispatch-architecture-analysis
description: Use when when you need to understand how a multi-instrument mass spectrometry platform (like mzmine) decides which processing module receives a given dataset based on its declared data type (LC vs. GC vs. IMS vs. MS imaging).
license: CC-BY-4.0
metadata:
edam_operation: http://edamontology.org/operation_3439
edam_topics:
- http://edamontology.org/topic_0121
- http://edamontology.org/topic_3520
tools:
- mzmine
- JDK 25
- JavaFX 24
techniques:
- LC-MS
- GC-MS
- ion-mobility-MS
derived_from:
- doi: 10.1038/s41467-021-23953-9
title: iimn
evidence_spans:
- mzmine is an open-source software for mass spectrometry data processing
- JDK version-25-blue
- JavaFX version-24
claims: []
provenance:
collection: https://w3id.org/holobiomicslab/asb-skill/collection/metabolomics/v2
assembled_by: scripts/collect_metabolomics_collection.py
sources:
- build: coll_iimn
doi: 10.1038/s41467-021-23953-9
title: iimn
dedup_kept_from: coll_iimn
schema_version: 0.2.0
attribution:
generator: AgenticScienceBuilder
original_doi: 10.1038/s41467-021-23953-9
all_source_dois:
- 10.1038/s41467-021-23953-9
zenodo_doi: 10.5281/zenodo.20794027
curators: []
promoter: Louis-Félix Nothias
sponsor: CNRS & Université Côte d'Azur
---
# module-dispatch-architecture-analysis
## Summary
Systematic tracing of conditional branching and factory patterns in a scientific software codebase to reconstruct how input data types (LC, GC, IMS, MS imaging) are routed to their corresponding processing modules. This skill enables reverse-engineering of extensible module dispatch logic in large analytical pipelines.
## When to use
When you need to understand how a multi-instrument mass spectrometry platform (like mzmine) decides which processing module receives a given dataset based on its declared data type (LC vs. GC vs. IMS vs. MS imaging). Use this skill when the codebase lacks explicit dispatch documentation, or when you need to audit whether new instrument types can be added without breaking existing routing logic.
## When NOT to use
- Input is a single processed dataset (mzML, NetCDF) without access to the source codebase — use this skill to trace design, not to process data files.
- Goal is to run mzmine on your own samples rather than to understand its internal routing architecture — refer to the command-line interface or user documentation instead.
- You need to extend mzmine with a new instrument type — this skill provides understanding, but actual extension requires also implementing the new module interface and registering it with the factory.
## Inputs
- mzmine source code repository (Java codebase with JDK 25+)
- Data-type declaration interface or enum definitions
- Module initialization and factory pattern code
- Conditional branching logic (if/switch statements)
- Configuration and parameter validation code
## Outputs
- Control-flow diagram or pseudocode of dispatch logic
- Table mapping data types (LC, GC, IMS, MS imaging) to processing modules
- List of routing conditions and thresholds
- Instrument/format coverage matrix per module
- Fallback behavior and exception handling paths
## How to apply
Begin by locating the main entry point and module initialization code in the source repository (e.g., github.com/mzmine/mzmine). Identify the data-type declaration interface or enum that classifies input as LC, GC, IMS, or MS imaging. Trace all conditional branching (if/switch statements) and factory-pattern instantiations that map each data type to its target module, noting parameter checks and fallback behavior. Extract routing conditions, thresholds, and exception handlers. Finally, synthesize the complete routing logic as a control-flow diagram or pseudocode, documenting each pathway, the criteria that trigger it, and the set of instruments or file formats supported by each module.
## Related tools
- **mzmine** (Mass spectrometry data processing platform whose module dispatch architecture is being traced; provides the source code, data-type enums, and factory patterns to analyze) — https://github.com/mzmine/mzmine
- **JDK 25** (Java compiler and runtime environment required to build and inspect the mzmine source code)
- **JavaFX 24** (GUI framework used in mzmine; module initialization may be tied to UI components, so tracing dispatch may intersect with JavaFX event handling)
## Evaluation signals
- Control-flow diagram covers all four data types (LC, GC, IMS, MS imaging) mentioned in the README and has no unreachable code paths.
- Each data type maps to at least one concrete processing module with a documented fallback or exception case.
- Routing conditions can be traced from enum definitions or interfaces back to the factory/conditional code without gaps.
- Coverage matrix shows which instruments or file formats are supported by each module pathway, matching or exceeding the README claim of 'most MS instruments'.
- All parameter validation thresholds and dispatch criteria are explicitly documented with their source locations in the codebase.
## Limitations
- mzmine's module dispatch logic may be distributed across multiple files (entry points, factories, module interfaces); tracing requires patience and may miss edge cases if custom loaders or plugins override default routing.
- No changelog was found, so historical changes to dispatch logic or deprecated data types cannot be confirmed without git history inspection.
- Fallback behavior and error handling paths may be implicit (e.g., null checks or exception catches) rather than explicitly documented, requiring careful code review.
- The analysis produces design documentation but does not validate whether the routing logic actually works correctly on real datasets without executing test cases.
## Evidence
- [readme] mzmine is an open-source software for mass spectrometry data processing: "mzmine is an open-source software for mass spectrometry data processing"
- [readme] mzmine supports LC, GC, IMS, MS imaging, and most MS instruments: "Support includes liquid chromatography (LC), gas chromatography (GC), ion mobility spectrometry (IMS), MS imaging (e.g., MALDI), and most MS instruments"
- [readme] mzmine provides flexible and easily extendable software with a complete set of modules covering the entire MS data analysis workflow: "provide a user-friendly, flexible and easily extendable software with a complete set of modules covering the entire MS data analysis workflow"
- [other] Trace conditional branching logic and factory pattern that maps each data type to its processing module: "Trace the conditional branching logic (if/switch statements or factory pattern) that maps each data type to its corresponding processing module"
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!