contract-redline-docx

name	contract-redline-docx
description	Produces a Word .docx with tracked changes (Word-native revision marks) of a contract — the file you actually send to opposing counsel. Wraps the output of /vallor:contract-redline (or builds the redline from scratch if no prior run exists), invokes python-docx + tracked-changes XML, and emits a reviewer-ready .docx with a cover memo. Use when the user says "redline in word", "send to opposing counsel", "tracked changes docx", "build the docx redline", "put this in Word", "make it a redline file", or after contract-redline has produced markdown that needs to ship.
argument-hint	[contract-path-or-redline-md] [--reviewer-name <name>] [--mode external|internal]

/vallor:contract-redline-docx

Purpose

Markdown redlines are great for diffing and review; opposing counsel wants a Word file with revision marks. This skill produces that file — with Word's native tracked-changes XML, the right reviewer name, the right author metadata, and a cover memo at the top — so it lands the way a partner would have sent it.

Inputs

Two paths, depending on prior state:

1. Path A — redline already exists. User points at a markdown redline produced by /vallor:contract-redline (or one written by hand). This skill converts the proposed-language changes to tracked Word revisions against the original source document. The original must be available (path passed in or located in the matter folder).

2. Path B — fresh. User points at a contract PDF/DOCX with no prior redline. This skill runs the redline workflow internally (same logic as contract-redline), then converts.

Path A is preferred — it lets the user review the redline in markdown first, then ship. The skill prompts for Path B only when no markdown redline is found.

Load context first

1. Read ~/.claude/plugins/config/vallor/CLAUDE.md. Bounce on placeholders.
2. Determine the side (sales / purchasing).
3. Apply the /design skill — the .docx uses Times New Roman 11pt body, the plugin's footer, and the work-product header (or jurisdiction-correct equivalent).
4. Read the source contract (PDF or DOCX). For PDF inputs, extract text with layout preserved; convert to DOCX first using pandoc or python-docx.

Ask the user for context (optional but encouraged)

Use the AskUserQuestion tool to calibrate the .docx before generating. The file ships to opposing counsel — a wrong author name or mode is embarrassing.

Up front (before generating the docx): Ask 1-3 short questions when not obvious from the inputs or practice profile:

• Mode: external (for opposing counsel — strips internal markings) / internal (keeps [review] and reviewer notes)
• Reviewer attribution: which name/email to embed in tracked-changes XML (default: practice-profile reviewer)
• Cover memo tone: tight ("we propose the attached changes") / collaborative ("happy to discuss any of these") / firm ("the marked items are required")
• Whether to include explanatory comments inline or strip them to a separate redline cover

Mid-flight (after applying the markdown redline): After applying changes to the docx, surface concrete asks before guessing on:

• Items the markdown flagged [review] — drop, soft-comment, or escalate before sending
• Edits that landed in oddly-formatted source paragraphs (tables, footnotes) — confirm before mangling
• Whether to suppress trivial whitespace / numbering corrections to keep the tracked-changes list focused

Rules:

• Every question must offer a reasonable default the user can pick to skip ahead.
• Ask follow-ups when answers reveal more depth or a non-default choice.
• Cap a single round at ~3 questions.
• Skip when the user has signaled a fast / default run.

Workflow

Step 1 — Confirm reviewer identity and mode

The tracked-changes XML embeds the author of each revision. Confirm before writing:

"I'm going to write tracked changes attributed to [reviewer name from practice profile] with email [email]. Mode is [external = for opposing counsel / internal = for in-house review]. The external mode strips the work-product header and any [review] flags. Internal mode keeps them. Confirm?"

Wait for confirmation. If the user wants a different reviewer name (e.g., a senior partner whose name should appear on the file), apply.

Step 2 — Build the change set

Read the source DOCX and the redline markdown. For each redline entry:

Markdown action	DOCX action
~~text~~ (strikethrough)	<w:del> revision, attributed to reviewer, dated today
**bold inserted text** block following the strike	<w:ins> revision, same author/date
> WHY: … annotation	<w:comment> on the affected span, attributed to reviewer
> FALLBACK: …	<w:comment> with prefix [Fallback] so opposing counsel sees it as a position, not a demand
● HIGH / ● BLOCKING severity markers	Stripped in external mode; preserved as [INTERNAL: severity] comments in internal mode

Use python-docx for the file itself and direct OOXML manipulation for the tracked changes (python-docx alone doesn't write <w:ins> / <w:del> natively). The reference implementation lives at references/docx-tracked-changes.md.

Step 3 — Assemble the cover memo

A short cover memo precedes the file in the message but is NOT embedded in the file. Format:

Hi [opposing counsel name],

Attached please find our redline to the [agreement type]. The key positions are
summarized below; happy to discuss any of them.

  • [Issue 1 in one sentence — neutral business framing]
  • [Issue 2]
  • [Issue 3]

The substantive changes are in tracked changes throughout. Comments mark spots
where I've offered fallback language we'd accept.

[Reviewer name]
[Firm / company]

The cover memo is the first thing the user copies into email. It is plain text, no markdown ornamentation. It is generated separately so the user can edit it before sending.

Step 4 — Write the .docx

Output path: ~/.claude/plugins/config/vallor/redlines/<YYYY-MM-DD>-<counterparty>-<type>-redline.docx

(Or matter folder if workspaces are on.)

Validation before writing:

• All redline entries map to a span in the source. If a span can't be located, surface it: "I can't find this language in the source — line 412 of the redline. Was the original clause renumbered between drafts?" Don't silently drop the change.
• Word can open the file (test by re-reading it with python-docx after writing).
• The <w:settings> block has <w:trackChanges/> set so changes appear as revisions, not committed edits.

Step 5 — Deliver

Redline.docx is ready. Saved to [path].

Author: [Reviewer] Mode: [external/internal] Revisions: [N insertions, M deletions, K comments]

The cover memo (above) is plain text — copy it into your email when you send the file.

Decision tree:

1. Send via DocuSign / outbound email — if the user wants to ship now.
2. Apply revisions to the .docx and produce a clean v2 — for internal sign-off before shipping (the v2 reflects all changes accepted; the redline.docx is the tracked-change version).
3. Build the approval deck — /vallor:contract-approval-deck.
4. Stop here — file is saved.

Constraints

• The skill never sends the file. The user sends. The skill produces.
• It never modifies the source contract — always writes a new file.
• It never invents language. Every insertion must trace back to a position in the practice profile, the contract brief, or a position the user explicitly stated.

External mode rules

When --mode external:

• Strip the work-product header from the .docx itself (it stays on internal copies and on the cover memo template, but never on the file going to opposing counsel).
• Strip all [review] and [BLOCKING] severity markers from comments — these are internal-only. Reframe the underlying position in neutral business terms.
• Strip any internal escalation references ("GC approval required") — these are internal-only.
• Keep substantive comments that explain the proposed position (e.g., "Carving IP indemnification above the cap is standard practice for SaaS at this scale").

Internal mode rules

When --mode internal:

• Keep the work-product header at the top of the document.
• Keep severity markers in comments ([● HIGH] Cap base on Never-accept list).
• Keep escalation references.
• Add a footer to every page: INTERNAL DRAFT — NOT FOR EXTERNAL DISTRIBUTION.

Examples

/vallor:contract-redline-docx redlines/acme-msa.md

/vallor:contract-redline-docx acme-msa.pdf --mode external

/vallor:contract-redline-docx --reviewer-name "Jane Smith, General Counsel" --mode external