To review a Markdown file generated by Claude Code, start with a saved .md file: ask Claude Code to write the plan into your project, open it in a rendered reader, and check the assumptions and acceptance criteria before requesting revisions. This gives you a document you can revisit as the implementation changes.
The example below uses docs/implementation-plan.md. You can review it in the browser on mdview.io or read it locally with mdview Desktop for Windows 11. The broader AI Markdown viewer guide covers chat responses and other AI-generated documents; this workflow focuses on a file saved in a project.
Run Claude Code in your project and give it a concrete documentation task. For example:
Inspect the existing CSV export code. Write a proposed implementation
plan to docs/implementation-plan.md. Include the current behavior,
assumptions to verify, acceptance criteria, affected files, a small
Mermaid flowchart, and validation steps. Do not change application code
yet. Identify anything you could not confirm from the repository.This is an example prompt, not a special command or guaranteed output format. Check that the file was actually created and that it describes your project. Anthropic's Claude Code workflows include working with documentation and Markdown folders.
Keep related documents together:
project/
├── README.md
└── docs/
├── implementation-plan.md
└── export-format.mdA stable filename makes it easier to review the next revision and refer to the same plan in a follow-up request.
In the web viewer, open docs/implementation-plan.md using the local-file picker or paste its contents. Check that headings, tables, and fenced code blocks appear as intended. If you opened a file in the browser, reopen the updated file after Claude Code saves a revision; the browser view is not a live connection to that file.
On Windows 11, install mdview Desktop and open the .md file with it. Reading Markdown, Mermaid, and LaTeX math works locally on the Free plan. Pro adds folder browsing, linked documents, and live reload after a file is saved. The reader does not edit your plan: make revisions through Claude Code or your usual editor.
If Claude Code is running in WSL, open the file from its actual project folder or save it to a Windows-accessible folder. Avoid maintaining a second copied version that quietly becomes stale.
Start with the proposed behavior. A plan for CSV export might contain this small acceptance table:
| Scenario | Expected result | Evidence to request |
|---|---|---|
| Export a filtered table | Only matching rows appear | An example with one excluded row |
| A cell contains a comma | The cell remains one CSV field | Parsed output with a comma-containing value |
| No rows match | The documented empty result is produced | A check against the agreed product behavior |
Ask whether each requirement is supported by the repository, inferred by the agent, or still awaiting a decision. A polished table can make an unsupported assumption look settled. Follow the affected file references and check that the proposed change matches the current implementation.
For a Mermaid block, inspect what the diagram communicates as well as whether it renders. Here is a minimal process diagram:
Does the plan apply filters before encoding, and does the code do the same? If labels become raw source or a diagram fails, use the Mermaid troubleshooting guide. Reviewing the document helps identify questions; verify the implementation separately with the appropriate code review and tests.
From docs/implementation-plan.md, this link refers to its sibling document:
[CSV format](./export-format.md)Check that the destination exists. Opening or sharing a single Markdown file does not automatically include sibling files or image folders. Keep the project folder available for a local linked-document workflow, or use published URLs when sharing documents separately.
The local images and relative-links guide explains path resolution in detail. Do not replace a working repository path merely because a detached preview lacks the referenced file.
Give Claude Code feedback against the saved document:
Revise docs/implementation-plan.md: explicitly distinguish confirmed
behavior from assumptions. Add the empty-table acceptance case and
explain how CSV quoting will be validated. Keep implementation changes
out of this revision. Summarize what changed in the plan.With desktop Pro live reload, the reader updates when the file is saved. Otherwise, reopen the file after the save. Compare the revised acceptance criteria and assumptions with your feedback. Use a source diff when you need to see exactly what changed; a rendered reading view does not replace that comparison.
For a teammate who needs a browser link, open the agreed revision in the web viewer and share it as a rendered document. Check the linked resources from the recipient's context and confirm that the shared content is the version you reviewed. Later changes to the local source do not automatically update a published copy.
Keep the saved project file as the source you revise. The practical loop is to save a plan, read it, ask specific questions, revise the same file, and verify the resulting implementation against its acceptance criteria.