This project is less about inventing a new microbial genomics method and more about making a common analysis path less fragile.
In bacterial whole-genome sequencing, the individual tools are familiar: QC, trimming, assembly, polishing, annotation, screening, and phylogeny. The hard part is often the handoff between them. Which files are expected? Which samples have long reads? Which outputs should exist at the end? Which environment was used for each tool?
The workflow uses Snakemake to make those handoffs explicit.
The first decision is whether a sample has long reads. If it does, the workflow can use a hybrid assembly route. If not, it follows a short-read assembly route. After that, the pipeline moves through polishing, assembly quality control, annotation, optional screening, comparative genomics, and reporting.
The final targets are deliberately review-friendly: MultiQC reports, long-read QC summaries, QUAST reports, BUSCO summaries, Bakta annotation files, optional MLST/AMR/virulence/plasmid screening outputs, a screening summary spreadsheet, and core-genome tree files.
That output design matters. A workflow is not only for the person who runs it. It is also for the collaborator who wants a report, the reviewer who wants to understand the analysis path, and the future version of you who has to rerun it.
Snakemake fits because it turns the analysis into a graph. Conda environments are split by module, so QC, assembly, annotation, screening, and reporting do not all depend on one overloaded environment.
I would not call the current repo a finished production pipeline yet. The missing piece is an easy public test run. A tiny dataset and CI dry-run would make the workflow much easier to validate from scratch.
As a research-engineering artifact, though, it shows the thing I wanted it to show: clear inputs, modular rules, declared outputs, and a path from reads to files that someone else can inspect.
References and artifacts: the workflow is in the bacterial genome analysis repository.