Of all the risks in a project, the number that are mitigated by review seem rather small to me. My gut reaction is that they fall into a category of not trusting someone to do their job well. Pairing while coding is continuous review, so that's taken care of. If you can't pair, a "second pair of eyes before check in" rule is better than nothing. Other artifacts should turn into software in very short order, so rapid feedback is the mitigation strategy. What else would you want to review?
All those other risks, which we might call "any uncertainty in the schedule", are mitigated by trying to become more certain. I've been in project launches with a new team with new managers using a new language on a new platform for new customers in a new business domain. There was nothing but uncertainty. You want to know "how long will it take to build a medium sized feature" in that world, you gotta go build a couple and measure. Uncertainty falls away pretty quickly when you have solid experience. Agile's emphasis on frequent delivery of running tested features fits very nicely.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
With other words, with an Agile approach, every other week you are reviewing a fully running, tested, documented system. That will mitigate most of the risks.
If there are still risks that you can only mitigate by reviewing documentation, you are surely allowed to do that with an Agile approach, though.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus