Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Is what you've posted a good approach? Probably not. (There, your question has been [also probably] correctly answered. Please mark my response so. 
)
Oh, you're looking for "any help" too? Can I get bonus points? (I hope you don't my joking responses, so seriously . . .)
Something that might be an issue, I see you're using a gigE interface for your WAN hand-off. QoS only "triggers" when there's congestion. If your WAN has a logical bandwidth cap you'll want to shape for that value. This allows your QoS policy to "trigger" when there would be congestion against that bandwidth limit.
When using a shaper, most I believe, don't account for L2 overhead, but provider bandwidth caps usually do. So, whatever the bandwidth cap is, to more accurately shape for it, you'll want to set the shaper about 15% lower. This is especially needed for time sensitive traffic.
Whether a shaper or interface causes congestion, you then define a policy how to manage that congestion. Real-time traffic, often does use LLQ, as you're doing with your Skype traffic, but Cisco recommends LLQ never use more than about 1/3 of your bandwidth. Cisco recommends this, so that the prioritized traffic isn't real adverse to non-LLQ traffic, but if you really need more than 1/3 of bandwidth for LLQ, you probably don't have enough overall bandwidth.
By default, faster interfaces use FIFO queuing, which allows bandwidth hogs to be adverse to light bandwidth using flows. Often using fair-queuing for every flow is sufficient, but if some traffic needs even higher preference, you can break it out.
So, if your interface is the actual bandwidth limit, something as simple as:
policy-map Sample
class class-default
fair-queue
Might be sufficient.
If you need a shaper, you have a parent policy and child (the parent is what is applied to interface), e.g.
policy-map ParentSample
shape average <bandwidth limit - 15%>
service-policy Sample !from above
If you find you do need to break out Skype, you can try something like:
policy-map Sample
class skype
bandwidth percent 99
fair-queue
class class-default
bandwidth percent 1
You can experiment with the bandwidth percentages, but the above will give skype LLQ like priority, not limit it with an implicit policer, FQ any congestion between Skype flows.
