Nice implementation and refactoring, few suggestions:

AbstractCommand class

I created a base class for all subcommands, AbstractCommand.

• I think a better name is SubCommand. The type of the class doesn't need to be in the name.

• The instance variable commandName can be shorten to name, since it's implicit that it's the subcommand name.

• The second argument of the method execute is called arg2, a better name could be label.

• The method execute returns nothing. How to know the result of the command? How to handle errors and exceptions? Consider to return at least a boolean.

AbstractConfirmCommand class

This class seems to check if the confirm argument is where is supposed to be and then invoke withConfirm or withoutConfirm accordingly. There is no example of a subclass so I'll limit the review to what I see:

• The chain of if()-return should be replaced with if()-else if()-else and remove. No need for the returnempty return.
• A better class name could be ConfirmedCommand
• Pushing common behavior up to a parent class is ok, but I am not sure if splitting the method execute to withConfirm and withoutConfirm is a good idea. You are basically forcing all subclasses to overrideimplement two methods instead of one.

CommandRegistry class

• If it's a registry, it shouldn't execute the commands, that. That is the job of the CommandExecutor.
• Instead of a Set consider using a Map<String,SubCommand>, it's way more efficient infor retrieving data.

I suggest to add a method addCommand to ClanCommand (which is your CommandExecutor) and store the subcommands in a map.

ClanCommand class

• Since it implements CommandExecutor, I would call it ClanCommandExecutor.
• I am notSame as before, instead of a fanchain of if()-do something and return true-if()-do something and return true. Find consider to find the conditions to fail first with if this than return false, then use if-else if-else, and at the endfinally return true.

There is a design pattern called Command which I suggest you to check out.