I can suggest some skills based on personal experience. For one thing, as recently mentioned by other people your hours required will increase if you have to share your brain over a number of projects or unrelated tasks.

I also find (don't necessarily exploit well but hey) that time spent out of the office often provides valuable insights.

In other words the ability to manage your development efforts to include perspective and relaxation (i.e. no hairy deadlines with manager types hanging over you) is pretty significant. The corollary is that the skill of accurately predicting how much time a task will take is critical but until you are a guru at it you need to have a buffer zone and risk management in place.

I'd also say that regarding necessary skills, you will need to be able to critically analyze the problem statement to figure out what the problem really is, in other words you might have to spend a significant part of the 75% up front to find out what the client actually wants/needs. I usually write a document which says, "So you want this, right?" and then we are on the same page. You can try to keep that fuzzy glow of ambiguity but it can bite back ("But of course we need a secure idiot proof whiz bang administration interface", etc.)

I would say that if you are building a system and getting paid by somebody else, then some time is going to be spent on setting up a framework (XP has some ideas about this) that lets you stay sane and avoid feature creep and other requests for the impossible.

It depends what kind of business you are in; it is possible that people will not value the time you spend on maintenance or not want you to do it. So communications skills are pretty important.

Right up there, documentation skills will save you not to mention people who come after you. So keep a finely detailed record of all communications you get from people about the project (helps unweave stringy masses of requests and can keep your job for you or get you a new one) and also keep a log of the work you do for your own sanity.

You also can use engineering skills which will free you from coder hell and turn it into an engineering problem. You get a sense of equilibrium and can also decide between various strategies based on what the system is fundamentally going to have to be able to handle, instead of starting with one idea and then realizing you have to keep tweaking the whole thing into some other direction. For example it may be that thinking about it from a user interaction standpoint, or in terms of performance requirements, will be more important. Also if you break things into small tasks and set yourself up for a series of wins (punch the air, it works!) you have a tool for effectively managing your resources (you and your time). So engineering skills (as separate from from programming skills) are important to keep things on an even keel, and fun.