Generally it's not a good idea to do that because you are essentially storing game state into the skeleton. Eg, if your character has a sword equipped, a good design would store that in the data model for your character. Game logic checks that to find if the character has a sword when dealing damage, etc.
You would not want game logic to check what attachment the skeleton has in order to determine if it has a sword. You certainly could, but storing game state in the skeleton like this is messy and will make serializing your game state difficult (eg for saving the entire game state).
You can apply the game state to configure attachments, bones, etc on skeleton every frame, usually after you apply animations, or you can do it only when the state changes (eg the player equips a sword or the entire game state was just restored from a saved game).
Ideally you even store what is needed to know what animations to apply in the game state. Eg the game state defines whether the character is running or walking or falling or getting hit. From that you can determine what animations you should be playing. If you are already playing the right animation, you just let it play, otherwise you set the right animation. You can see that being done in Super Spineboy in this code.
If you really want the behavior you described and don't want to continue using separate animations to achieve it, you can modify AnimationState. I described how it might be done here:
Chaining animation resets elements to their set-up pose.
