There's a lot of different directions you could go with this. What kind of game are you making, and what does type Mob represent? It sounds like you need to separate your concerns more.
How do I termine which mobs has which skills?
If each skill is its own class, and each skill extends the Skill class, then that leads me to think you should have a Vector.Vector.<Skill>
field in the Mob class.
Assuming you need to instantiate the skill for purposes of state management (like cooldowns and other things), then this Vector. would contain objects which are-a Skill. To search for a specific skill, it could be useful to give Skill a property called Name which is overridden by subclasses of Skill. Then you can search through a mob's Vector. looking at the name of each skill until you find the one you're looking for.
A more robust solution would be to analyze your gameplay such that you don't even need to subclass Skill, and you could create entirely new skills by setting the properties of the skill class accordingly.
And which skill will they later be able to retrieve (by reaching a certain level etc).
This is a larger architecture question.
How does the player actually execute the skill
Presumably, the player is a Mob, and there's a keyboard mapping such that Attack gets called. Why do you have a separate function, executeAttack defined in the Tackle class?
and how is it determine if it hits.
This is something you need to decide. Read up on collision detection for checking if a point intersects a region on the screen, or find a D&D rulebook and look at how the Difficult Class system works.
It sounds like you're biting off more than you can chew. Try breaking this game down into something simpler. Build individual aspects of it into smaller games, then as you learn more you will be able to assemble the bits and pieces you've learned on the way into something bigger.