• coding standards
• source code organization (in which file do I put $x?)
• build system
• testing policies
• documentation policies
• design
• APIs
• schedule
• infrastructure like bug tracker, source control etc.

In the end what's important is that you know what to do, and how to do it. If you don't know it, it can has two reasons: it's a hard problem and needs research, or you're not clear about some conditions, design questions or APIs. In the first case you likely just need to sit down and work on the problem, in the latter you need to ask your boss or cow-orker.

So what needs be communicated is "all you need to know".

There are various books out there that cover software project management. If my meager answer is not enough for you, you might read one of those books (though I can't recommend one in particular; but I'm sure some other monks can).

Thank you for very good post. This is very useful to me. I had some of these in mind, but your post gave me some more useful hints. I just wanted to make sure, that I communicate properly, so mutual understand and progress happens and can reflect my skills well.