Question about module conventions: https://github.com/nf-core/modules/pull/10959#discussion_r2961313461

I would personnaly keep the old way

TOOLS/SUBTOOLS

and put back all

mcstaging

process into their respective folder. The issue for me would be the duplication of tools in different folder when people consider they have different purpose. The PR can be merged for the moment, but a new one should put back everything properly. The problem would then be : do we need to deprecate them, if we only changed their place ?

They should not have been merged in the first place but I guess stuff like this is hard to spot (I only spotted this because we discussed the topic issue in the first place).

This is indeed tricky, maybe we could look at all the process that doesn't contains

tools

and

subtools

in the script block ?

Yes probably and then also check how many pipelines use the tools. I guess this can be done automated and then add all of these modules to an issue and then we can have claude check all of those or something (not too big in the agent game but this seems to be a perfect task for an agent) and then we apply changes and deprecations where needed and also add some warnings or more comments to the template and the docs? pinging @Rike Hanssen for agent automation for this task haha

😄 let me know what you need.

I think we all agree there that this should not have happen

@Rike Hanssen here: we essentially want to do what I wrote above

Yes probably and then also check how many pipelines use the tools. I guess this can be done automated and then add all of these modules to an issue and then we can have claude check all of those or something (not too big in the agent game but this seems to be a perfect task for an agent) and then we apply changes and deprecations where needed and also add some warnings or more comments to the template and the docs?

• how many pipelines use a module: is mapped on the website already. It's just tough because they get used externally a lot as well for which we have no visibility. Don't think claude will be able to find those eithe

ok then lets rather use claude to find the modules that are named incorrectly and create issues for each of them and then assign one of us to the issue then we check whether claude was correct and if yes we mark that in the issue and then we let claude do the moving of each of those modules and deprecate the "old" location

BTW, I had a talk with @Krešimir Beštak and he have a solution that I like

Claude is compiliing a list now

Looks good, from a quick look I can see minor mistakes, but all good, thank you so much Rike

Wonderful ! How do you want to manage the discussions ? 39 tools onto just one Github thread may be unwieldy

@Famke Bäuerle suggested human review to check if true and then create a separate PR/issue and update the meta issue with the number. Does that seem sensibel @Matthieu Muffato?

Yes when someone wants to make a change. There’s already a process in place in GitHub + #CQY2U5QU9. That’ll guarantee someone else agrees with the assessment. I’m thinking : equally there should be a review when someone thinks no change is required. For instance, I want to argue

fcs/fcsadaptor

should keep its name even though the command is

av_screen_x

. I don’t think it’s someone I should be allowed to decide myself. I’d want to explain why somewhere and someone else to approve/reject. Exactly like a PR but with no code change. I don’t mean to burden the whole process. Just have another pair of eyes check the decision of each module, like all the other changes we do in the repo.

I started reviewing the listed modules, good news is that most of these are a false alarm 🎉