How to shoot down your proofs
Software engineers have a notion they call "code smells".  These are symptoms in the code that may indicate a deeper problem.  Software engineers collect mental lists of smells to be aware of (i.e. excessively long methods or too many parameters).  It does not necessarily mean there is a problem, but simply indicate that the writer might want to double check.

I propose that we ought to also consider "proof smells".  This will not give you an algorithm for checking your proofs but it gives a language and a metaphor for recognizing possible problems in proofs.  Some examples of proofs smells:


The adverbs "Clearly", "Obviously", etc.
Reference to the proof of a previous result instead of a reference to the result itself.
Flippant use of a result with many technical preconditions.


There are also more subtle smells.  For example, if a proof uses the binomial theorem to expand an expression and then later uses the binomial theorem to return to a closed form, then maybe there is a direct manipulation on the closed form that gives the same result. 

My suggestion is to collect a (mental or written) list of such smells and check for them as you read through your work.  The nice side effect of this approach is that it will also make you a better reader.

Note: My hope in this answer was to give intuitive side to the rigorous answer supplied by Lamport's How to Write a Proof referenced in M. Alaggan's answer.