It really depends on what you want to portray in your technical design document. From my experience, a lot of teams have different methods of working. Some prefer to use very detailed TDDs maintained by a technical designer and the engineering team. Whilst other teams prefer to work with more freedom and simply have a TDD with basic information, like rules, formulas and assets required.
The best thing to do first is find out what your team (or the company you want to apply for) needs in a TDD and tailor it for them.
When I write a technical design document, I like to write the brief overview of the area I'm working. I then go through the overview and expand on the idea and add values, rules and other bits of technical detail to the design. I sit with an engineer and explain to them the basic idea before I move onto the next stage. They might find a problem with you idea or problem with your design which needs editing before you can go into further detail.
After that I then explain what's required in order to get that design from paper into game. Listing out things like formulas, data values, models, textures, audio and most importantly outlining what sort of code support the design will need if a massive help to anyone else looking at this design.
One thing to consider is how you present your TDD. For example, in a 2D fighting game I would draw a 2D diagram of the animation flow and then write the technical damage rules and timing values. This is a lot more useful for an engineer and artist as opposed to an array in excel with a list of moves and damage values.
I found this on youtube. It seems like a good way to get started if you want an example:
Hope this has helped. :)
cheers fellas 
i really appreciate the help and direction im getting here, thank you, 
