Hi everyone, We’re exploring the implementation of optional UMI-aware preprocessing in nf-core/atacseq and wanted to get some feedback before starting the work. The motivation comes from the UMI-ATAC-seq protocol described by Li et al. (Communications Biology, 2020), which introduces a UMI on Read 1 to distinguish true PCR duplicates from independently generated fragments. Compared to conventional coordinate-based deduplication, the paper reports improved duplicate classification and better recovery of signal in highly accessible chromatin, ultimately leading to increased transcription factor footprint sensitivity. We’ve reviewed both the publication and the accompanying implementation. While the original code demonstrates the methodology, it appears to be tightly coupled to the specific workflow described in the paper and relies on several implementation choices (custom batching, bespoke scripts, limited scalability) that make it difficult to integrate directly into a production-grade Nextflow pipeline. Instead, we’re considering a native nf-core implementation that would: • introduce an optional --with_umi execution path; • reuse existing nf-core modules wherever possible (e.g. Cutadapt, UMI-tools, alignment, samtools); • implement only the protocol-specific preprocessing steps locally (primarily Mosaic End processing and associated workflow logic); • delegate all parallelisation to Nextflow rather than implementing manual file splitting or thread management; • validate the implementation by reproducing the key benchmark figures reported in the original publication. We’d like to understand whether this is something the community would be interested in accepting as a contribution to nf-core/atacseq. In particular, we’d appreciate feedback on a few architectural questions: 1. Would support for this protocol be considered in scope for nf-core/atacseq? 2. If so, would you recommend implementing the UMI preprocessing as: ◦ a local subworkflow specific to nf-core/atacseq, or ◦ new reusable nf-core modules where appropriate? To our knowledge this protocol applies only to ATAC-seq experiments. 3. For protocol-specific processing steps (such as Mosaic End trimming), would you generally prefer keeping them local to the pipeline, or would there be interest in modularising them despite their limited reuse? 4. Are there any architectural patterns in existing nf-core pipelines that you would recommend following for optional protocol-specific preprocessing branches? If there’s interest, we’d be happy to open an issue outlining the proposed design before starting the implementation so we can align with nf-core conventions from the outset. Thanks!

Hi Francesco, I like the idea tbh and there is a umi deduplication nf-core subworkflow already available, would need to dig into it whether one can easily integrate it. Happy to further elaborate on that, so potentially open an issue and we see how to get things implemented in a generalized manner so it could be used with other UMI-based library prep protocol as well. TL;DR -> Could you open an issue, including a link to the paper and propose what you think would be useful to implement?