Building a skeleton first, and muscles second, is surely best in most cases. Though there are times when the other way around is best. For example when you dream up a very interesting enemy, design it without any limits imposed yet, and then try and think of a unique mechanic that will organically flow from the creature you've just conjured up. In this case, you're likely to get a more imaginative end result than if just you built a mechanic for a 100x150px box and then skinned it.
Though in other cases, the reverse is true again I spent the first month or so making my game with just blocks, and it quickly became apparent that the most fun shape for my protaganist was a small 50x50px square - this better enabled zippy, bouncy movement in all directions, and naturally lent itself to Spryke's ceiling-hugging mechanic. That 50x50px block is the main reason Spryke ended up in ball-shaped as she now is. Had I started with graphics first, I probably would have gone for something more rectangular and/or humanoid, and I probably would have made the character bigger, to ensure I could fit more graphical detail in...and I would have ended up with a less fun game because of it.
Also, I'm sure I'm not the only one who sometimes tends to take a 'ping-pong' approach: code-graphics-code-graphics-etc. I'll do code with rough placeholders first. When that's working well, I'll add nice graphic stills. Once the graphics are in, weaknesses of the mechanics tend to show more clearly - like where they seem too clunky and don't match the form of the graphics, for example. So I'll polish up the code again until the mechanics feel the way the graphics look. Next, I'll do animation. That tends to dramatically change the feel of movement and mechanics, which calls for another pass at the code.....and so on.
Spryke's core movement mechanics have probably been through 7 or so such iterations so far. Every time I add another piece of the puzzle - a smoother camera, some code optimisations, some particle effects - it sheds light on another area where the movement can be improved. This sort of approach is too time-expensive to use everywhere in your game, of course, but for the core aspects, you'll likely end up with a superior result than if you had just gone the route of code-->graphics-->finished.