Begin with the decision the document asks you to make
Download the six-file Project Reading Kit. It describes a fictional field-notes app, not a customer project. Open specification.md and write down its stated goal: capture notes offline, then hand a readable summary to a colleague. The reading task is to decide whether the proposed first version supports that goal.
Follow evidence, not just headings
Read the scope and acceptance criteria first. Follow the specification’s link to architecture.md to see where notes live and how an export is proposed. Then open decisions.md: a design choice can explain a requirement that otherwise looks arbitrary. Return to the original criterion and ask whether the supporting files answer it.
Use a simple review record: claim, supporting file, unanswered question, owner. For this fictional example, “the app works offline” needs a check of where local images and export assets come from. A diagram alone is not proof that the implementation exists.
Keep a reproducible trail
Keep the folder intact so relative links resolve. If you send feedback, cite a filename and heading rather than “the middle of the document.” Do not silently fix the specification while reviewing it; record proposed changes separately. This walkthrough works in any reader that can open the folder. Aero Markdown’s Mac app is not publicly available yet; the browser reader is useful for one file but does not follow local-file links.
For broken paths, use the relative-link guide. For reviewing a generated implementation plan, use the agent plan checklist.