Think Vitamin's Clive Howard says "Wireframing is one of the first steps in your planning process and arguably it’s one of the most important ones." In this article, Howard goes through the wireframing process, discussing who should be involved, which tools to use, and offers sound tips to enable you to make better wireframes.
Among my favorite points are those about ownership and involvement. This is to do with ensuring that someone is driving the process and iterations, and making sure that the interaction design process doesn't happen in a vacuum, but is reviewed, validated, and informed by key team members, e.g. engineers, as you're creating them.
I also like the points about fidelity, and avoiding doing too much design. That said, if you're also the visual designer, or can base the visual language of the wireframe to the visual language of agreed upon visual design specs, then I don't see a problem doing that.
What I don't agree with, is that you want to avoid designing behaviors such as Flash or AJAX. Wireframes, storyboards, and sketches are the precisely place to explore how websites and applications should behave. You needn't be as specific as specifying types of transitions, just generalized behaviors and relationship to system logic. If you don't specify behaviors, decisions will get made without your input. If that's fine with you, leave them out. But you're supposed to be the expert on your users, how they've modeled the site or app, and what they expect to do there.
Lastly, one point that is missing for me is know how to pitch/present the wireframes. These aren't just documents to be chucked over the wall. While they should be able to stand on their own when it comes time to design or develop what you've specified, your job is not done when you've shipped the doc. You have to present and justify, explain details, and answer to questions that will undoubtedly arise about how things behave. For this reason, I rely very heavily on annotating wireframes and storyboarding behaviors. Those questions will need to get answered eventually. If you don't think you deserve to be in that conversation, leave them out, because someone else will make those decisions without you. But if you intend to be involved in the user experience, why not be involved in every aspect of design, and make sure your wireframing process allows others to be inform what you produce.
There's quite a bit of good stuff in Howard's points, so be sure to read the article to find out what each of the bullet points above refer to.
http://thinkvitamin.com/features/20-steps-to-better-wireframing/