You're asking about how to write a game design document? Read these:

http://sloperama.com/advice/specs.htm

http://sloperama.com/advice/lesson13.htm

And you want to see sample game designs -- there are links at the bottoms of the first article above.

You're talking about design documentation, correct? GDDs and TDDs, not user-facing documentation or code comments?

Look to screenplays and scripts for inspiration on how to handle cut-scenes or dialog. If you have interactive dialog (e.g. dialog trees a'la Fallout or other RPGs), you can combine this screenplay-style notation with flow-charts.

Other than that, I don't think there's any formal guidelines or standard format for writing GDDs and the like -- however, there are numerous articles on the topic, both for containing suggestions around organization and content. The only stand-alone tips I can offer is to not combine game design documentation together with technical design documentation--or, TDD-- (these should be separate documents), and also don't try to be overly prescriptive in either -- for example, your TDD shouldn't try to predict what classes or interfaces will be needed, but should describe what code systems there are, their responsibilities and non-responsibilities, and how they might fit together. The purpose of either document is to define your goals in concrete form, and to lay the very foundation -- its not to predict the in-between in every detail.

One place you could look for inspiration would be an edition of the Dungeons and Dragons book -- even if you're not designing anything like an RPG, you could still adapt what you find inside to your game; particularly the way that races and characters are described, items and their properties are enumerated, and the gameplay rules are described. You can probably find a cheap copy of an older edition in any used book store/game store; they rules have changed over the years, but that doesn't matter for your purposes.