Docx review

Word document review and commenting

Most professionals review and redline in Microsoft Word. When you mark up a doc, produce a real Word file with native comments/tracked-changes, not a markdown summary. This skill is the canonical procedure. The engine is integrations/docx/docx_comments.py (use it, do NOT write a new per-doc build_*_review.py).

The non-negotiable rules

1. Timestamp = the real time. Always. A Word comment's w:date must be a full ISO-8601 datetime in UTC, e.g. 2026-06-24T11:41:00Z. NEVER a date-only string (Word renders a date with no time as 00:00 / midnight, which is the bug we are fixing) and NEVER a hardcoded placeholder like T09:00:00Z. The helper defaults w:date to datetime.now(timezone.utc), so just let it stamp the real moment. Only pass --when to reproduce a known timestamp, and it must include a Thh:mm:ss (the helper rejects date-only input).
2. Register the author in word/people.xml. Word silently refuses to THREAD a reply whose author is not registered. The helper writes the <w15:person> entry with a presenceInfo userId automatically.
3. Author as the user, first person. Comments speak in the user's voice — match the tone and phrasing captured in context/writing-style.md.
4. Always emit a markdown mirror (--record OUT.md). The user can transpose it by hand if they cannot open the Word file. The deliverable is BOTH the .docx and the .md record.
5. Reconcile against the latest meeting/transcript before finalising. The user's spoken decisions OVERRIDE anything you drafted. Pull the most recent relevant transcript and update the comments to their actual position.

When marking up a doc that already has comments

• Thread replies, do not dump standalone bubbles. If your point ANSWERS an existing comment (or a tag directed at the user), make it a threaded reply under that comment. Only genuinely new points (no existing comment) are standalone.
• The threading round-trip (this is the part that bites). Word regenerates any hand-injected w14:paraId on open/save, which orphans your w15:paraIdParent, so a one-shot injected reply never threads. The reliable flow:
  1. Inject the reply as a standalone comment (any paraId) with the helper.
  2. Have the user open the doc and Cmd+S once (Word stamps native paraIds).
  3. Re-read the saved file, find the reply's now-native paraId and the parent comment's paraId, and set w15:paraIdParent in commentsExtended.xml to link them.
  • Pre-existing parent comments keep their paraIds through saves; only injected ones get re-stamped. Standalone comments need no round-trip. Verify by reading the thread map (comment id -> paraIdParent -> parent author).
• Tracked changes (w:ins / w:del with w:author + real w:date) survive saves fine.

How to run it

# comments.json: a list of {anchor, text} (+ optional tracked_insert)
python3 integrations/docx/docx_comments.py SRC.docx OUT.docx comments.json \
    --author "Your Name" --initials YN --email [email protected] \
    --record OUT.md
# --when is OMITTED on purpose: the helper stamps the real current UTC time.

comments.json schema:

[
  {"anchor": "verbatim substring to attach the comment to", "text": "the comment body"},
  {"anchor": "...", "text": "...", "tracked_insert": "inline tracked text to append to that para"},
  {"anchor": "...", "insert_blocks": [
      {"h": "Heading text", "level": 3},
      {"p": "paragraph with **bold** spans"},
      {"li": "bullet item"},
      {"table": {"header": ["A", "B"], "rows": [["1", "2"]]}}
  ]}
]

insert_blocks inserts whole tracked paragraphs/headings/bullets/tables AFTER the anchor paragraph. Use it to FILL OUT a request/response doc as tracked insertions. Table rows carry w:trPr/w:ins (Word's tracked-row-insert) so accept-all keeps them and reject-all removes the whole table. Items are processed in order, so a later comment can anchor on text inserted by an earlier item. Caveat: pandoc's --track-changes=reject does not honour row-level marks (leaves empty grids); trust Word, and verify content with --track-changes=accept.

Or call it as a library: from integrations.docx.docx_comments import add_comments.

Finalizing: integrations/docx/docx_finalize.py SRC.docx OUT.docx [--stamp-after "marker" --stamp " - FINAL"] accepts every tracked insertion, strips all comments (anchors + parts) and optionally stamps a version suffix — use it to produce the clean recipient copy from the tracked working doc.

The helper: creates the comment parts when missing AND normalises pandoc's empty self-closing comments.xml (adds the w14 namespace); wires comments.xml + commentsExtended.xml + commentsIds.xml + content-types + rels + people.xml; verifies the output re-opens and counts the comments; reports any anchors it could not find (fix those, do not ship a silent miss).

Output location & packaging

• Working/source format is markdown; the deliverable is the .docx.
• Put review outputs under outputs/ by subject. When sending a set, bundle a single numbered zip (0 = the map/overview, then the docs).
• Structural visuals must be images (Draw.IO / SVG->PNG), never ASCII trees or tables (they render badly in Word).