You're absolutely right about how you look on paper (skills) versus the things you've actually DONE while in the field, and how that makes you awesome. I generally just make a very short and simple bulleted list of skills for expected information, but then I make it a point to talk about how my performance specifically affected projects I worked on. So I list specific things under my job history that I did, like maybe:
Dec 2007- Aug 2012, Company A
• On top of regular duties, volunteered for special pilot program to launch and support new product, resulting in $3.5M new sales in Q4 2011
• Identified API feed code problem outside of my regular job duties and volunteered to help fix it, saving company 20% in claims over Q1 2012
• Pioneered new training program for new hires to quickly get them up to speed for agile integration, saving 3 months time and training costs
I usually try and do about 5-7 of these, keeping them short and sweet, per relevant position. Some positions have less, but if I've done a whole lot of good stuff, I want that known.
Take a look at all those guys who have similar or identical resumes, and then see if you can figure out a way to make yourself sound better than them, while still having those same skills. In my experience it's about having specific things you can show on a resume to get someone interested, then talk to in an interview so people go "hey, this guy really goes out of his way to work really hard and get stuff done" vs the guy who just lists skills only.
Something else I've noticed is how... really inept some people are despite looking good on paper. As in they don't know how to just get around fast in an OS, or don't readily pick up methods to work faster without someone having to hold their hand. If you're the kind of person who learns systems on their own, makes it a point to ask questions, and become a subject matter expert, this is really important to show! This is the ideal employee.
It's tough to put that into words on a resume in a bullet point without sounding like an ass, but you could do something like:
• Go to person on team for process improvements, workflow questions, subject matter expert for x and y systems
• Volunteered to mentor other employees to solidify their knowledge of workflows