Well, how do your two actions fit within the business processes you're modeling?
Clean Architecture doesn't tell you how to define use cases. This is up to you and your conceptual understanding of the domain. Nobody who's not involved with the project you're on can tell you what to do here - besides providing generalized advice. This is for you to determine/design.
Basically, to figure this out, ask yourself (or other stakeholders) if the similarity is only superficial (the superficial mechanics are the same, but on a deeper level the use cases have aspects that you deem sufficiently different), or if the core logic and the role they play within the context of the domain is largely the same for both, meaning there's a way to come up with a unified representation of these use cases in your code/architecture. A proxy for that could be to find out whether or not the business already treats, in their existing procedures/workflows, these use cases as separate. Another thing to consider is if the similarity is expected to be temporary - are these use cases expected to evolve into different directions as you develop the software? If you aren't sure how to answer these questions, you can ask your customers / users / domain experts for more info.
Note that, if your requirements are vague, or represent only an initial pass of the spec, you may start off one way based on what you initially know, then figure out later on, as you learn more, that you should merge or split them. That's fine. On the other hand, if, early in the process, you have a deep understanding of the what-s and the why-s that are behind your requirements, you might be able to come up with use cases (or some other form of conceptual/architectural decomposition) that you won't have to reshuffle later.
What I'm trying to say is, as posed, the question doesn't really make sense. The question of which specific use cases you have is not something prescribed by Clean Architecture (which is a generalized idea) - this is the analysis part, the "some design up front"1 part of Agile. This is you (and/or your team) trying to figure what it is that your customer actually needs you to build for them and why, and trying to capture this understanding as a set of use cases that align with their business needs (but that, ultimately, you made up based on what you understood).
If you're experiencing "analysis paralysis", then just pick one or the other, and then keep track of how it's working out. If you run into design problems later, you'll probably be in a better position to correct them and incrementally redesign - if you don't wait too long and try to shoehorn things that fit less and less for the sake of "consistency".
1 Agile recommend against "big design up front", but some people wrongly interpret that to mean "no design up front at all". There has to be some amount of analysis/design, it's just that it should happen in smaller chunks, with faster feedback, and iteratively (dropping off over time as you hone in on the right architecture).