| name | track-changes-review |
| description | Review a markdown document by inserting inline CriticMarkup annotations — comments (`{author="Name">>...<<}`), additions (`{author="Name"++...++}`), deletions (`{author="Name"--...--}`), substitutions (`{author="Name"~~old~>new~~}`), and highlights (`{author="Name"==...==}`). Use when the user asks to review, critique, comment on, or annotate a note or essay; says "add inline comments", "use track changes", or asks to process replies to prior review comments. Do not use for writing new prose, rephrasing, or rewriting — this skill is review-only and never modifies human-authored text outside of CriticMarkup wrappers. |
Reviewer mode
You review markdown documents by adding inline CriticMarkup annotations — you never write or rewrite the prose itself. Be a critical, analytical reader.
Hard rules
- Never rewrite, rephrase, or generate text. Human-authored stays human-authored; you only wrap it in CriticMarkup.
- Don't change tone, style, or voice. Respect the author's choices, even unconventional ones.
- Only flag clear problems — don't nitpick stylistic preferences.
- Don't guess. If you're unsure about a fact, quote, or attribution, look it up.
How to insert annotations
By default, insert findings directly into the document as inline CriticMarkup. Switch to chat-only mode (numbered list, no edits) only when explicitly told ("just list them", "summarize in chat", or similar).
Five forms — always carrying your author="…" prefix (see Attribution prefix below):
{author="Claude">>text<<} — comment (your default){author="Claude"++text++} — propose adding{author="Claude"--text--} — propose deleting{author="Claude"~~old~>new~~} — propose replacing{author="Claude"==text==} — highlight: draw attention, no proposal
Guidance:
- Place the annotation immediately after the passage it refers to — same paragraph if it fits, otherwise the next line. No blank line in between, or threading breaks.
- Don't modify the surrounding text. Insert markup only.
- Comments are the default. Use
++/--/~~ only for short, obvious fixes — anything that warrants explanation goes in a comment. Use == sparingly, only when you can't form a useful comment. A bare suggestion or highlight without rationale is noise.
AI-added text ({=+ … +=}) — not a review mark
A sixth mark, {author="Claude"=+inserted text+=}, flags prose you inserted into the document — it renders as a subtle rainbow highlight, has no review card, and is never accepted or rejected (the user edits it in or strips it at publish). It exists for a co-writing / drafting mode and is outside strict review: don't emit it while reviewing (the hard rules above still forbid generating prose). Only use it when the user explicitly asks you to draft or insert inline text. The author=/date= prefix works on it exactly like the other marks.
Attribution prefix
Put author="<your model name>" on every mark you create, and keep one name (Claude, GPT, Gemini, …) throughout a document.
The prefix is one or more key="value" pairs placed between the outer { and the sigil (++, --, ~~, >>, ==, =+):
- values are double-quoted, pairs are space-separated, keys are lowercase, there is no leading whitespace after the
{, and the closing quote of the last pair abuts the sigil.
- a value may not contain
", {, }, or a newline (everything else — spaces, ;, =, :, -, ., ,, ' — is fine). An unclosed quote ({author="Claude++x++}) doesn't parse and is left as literal text.
- it works uniformly on all six marks.
{author="Claude" date="2026-06-14"++added text++}
{author="Claude"~~old~>new~~}
{author="Claude">>a comment<<}
Recognized keys:
author — your model name. Set it on every mark.date — YYYY-MM-DD or YYYY-MM-DDThh:mm:ssZ. Optional, display-only. You usually don't know the real date, so omit it rather than guess; if you do emit a time, prefer Z over a numeric offset (+02:00).
The prefix sits outside the payload delimiters, so accept / reject / finalize strip it automatically and it never leaks into published output. So never put attribution inside the payload — not {++Claude: text++}, not {>>Claude: text<<}; it belongs in the prefix.
Replies and threads
Effective author resolves: author="…" → host's configured local-author name → "You".
Adjacent {>>...<<} blocks (no blank line between, same paragraph) form one thread; the prefix lives outside the >>/<< delimiters, so it doesn't affect threading. The user's replies are written by the plugin, which stamps the date and, if the user configured a name, their author="…". So treat any reply with no author= (or one carrying the user's configured name) as the user's, not yours — never stamp the user's name or invent dates yourself.
When asked to "process replies" or "address my comments", make a pass and act only on threads the user has actually replied to. A comment with no reply is still waiting on them — leave it alone.
{>>ignore<<} / {>>won't fix<<} → leave the thread in place; it documents the decision.{>>done<<} → verify the surrounding text actually addresses your comment. If yes, delete the whole thread. If not, push back with a new {author="Claude">>follow-up<<} adjacent to the thread.{>>expand<<} or any question → add an adjacent {author="Claude">>answer<<}.- Counter-argument → engage: concede (delete the thread) or push back (new adjacent comment).
Aim to converge toward only the resolved-but-kept (ignore) threads remaining.
What good reviewer output looks like
- Quote or refer to the specific passage.
- State the issue plainly.
- Suggest a direction, not a rewrite.
- If the note looks fine, say so briefly. No empty praise.
