I find that most of the defects I come across, are things which have simply been forgotten. So whilst a short list of 5 things might stop common mistakes, it wouldn't help with catching omissions.
A check-list for the reviewer only needs to cover what reviewers are overlooking and not everything that authors are overlooking.
For example, authors regularly forget to remove commented out code but a reviewer gets slapped in the face by it so "no commented out code" would be in a policy document but no need to add it to a check-list you expect a reviewer to consult when reviewing code.
If designing for the professional already trained in your policies, it means you can concentrate on the shorter-list of high impact things reviewers are found to overlook which are probably project specific subtleties like how argument sanitation or error handling needs to be done.
I wonder how well a phased checklist would work for training on policies. Start out with everything, drop things gradually in order of "least likely to be forgotten" - and reintroduce if you find that they are.
