Review

Key Rules

• Always open first: Call ezra_open before any read/edit/suggest/comment operation on a document.
• Always read first: Call ezra_read before any edit or suggest operation.
• Suggestions over edits: Default to ezra_suggest so the human can accept or reject. Use ezra_edit only when explicitly asked or for trivial fixes.
• ezra_read returns markdown: ezra_read output includes markdown syntax (##, **, *, etc.), line number prefixes, and tracked change markers ([+text+], [-text-]). This is for your understanding of the document structure — do NOT pass markdown syntax, line numbers, or tracked change markers into other tools.
• Plain text for matching: When calling ezra_edit, ezra_suggest, or ezra_comment, match against the plain text content only — strip markdown syntax (##, **, *), line number prefixes, and tracked change markers ([+text+], [-text-]) from ezra_read output.
• Use spans to reduce output: For ezra_edit and ezra_suggest, use old_end to specify a span instead of repeating the full text — provide just the first few words as old_string and the last few words as old_end. Similarly, use anchor_end for ezra_comment to define an anchor span.
• Anchor text must exist: For ezra_comment, the anchor_text must be an exact substring of the document's plain text.
• Use ezra_write for full rewrites: When replacing all content or writing to an empty document, use ezra_write instead of ezra_edit. It accepts markdown and replaces the entire document.
• Markdown input for ezra_write and ezra_import: These two tools accept markdown (headings, bold, italic, links, lists, etc.). All other tools that take content (ezra_edit, ezra_suggest, ezra_comment, ezra_reply) take plain text only.
• Don't duplicate unless asked: Always work on the existing document. Only use ezra_duplicate when the user explicitly asks to create a new version or copy.
• One change at a time: Make targeted, surgical edits. Don't rewrite entire sections unless asked.
• Unresolved comments are action items: When the user has left unresolved comments, treat them as instructions. Act on each one, then resolve with a note.
• Don't touch user's tracked changes: The user's insertions and deletions are intentional. Don't accept, reject, or overwrite them unless explicitly asked.
• NEVER summarize: After completing work, produce ZERO summary output. No bullet points, no lists of findings, no "here's what I flagged", no themes, no counts, no categories, no recap of any kind. The user sees everything in the browser. Just provide the URL.