mohitagw15856
036511ab3e
Broadens both reach (more tools) and content types (an MCP server), continuing the multi-platform story. Windsurf + Aider: - build-exports.mjs gains two platforms: exports/windsurf/*.md (workspace rules, trigger: model_decision) and exports/aider/*.md (conventions for `aider --read`). Now 5 platforms (ChatGPT, Gemini, Cursor, Windsurf, Aider). - install.sh + bin/cli.mjs install both (windsurf -> .windsurf/rules, aider -> .aider/skills with a --read hint); generated README index is excluded from copies. - One-line windsurf-install.sh / aider-install.sh wrappers for parity. MCP server (new content type): - mcp/server.mjs — zero-dependency stdio MCP server exposing list_skills, search_skills, get_skill. Published as a second bin (pm-claude-skills-mcp). Logs to stderr; reads bundled skills/ at startup. mcp/README.md documents client config. Also: README hero "See it in action" demo placement (ready to swap in a GIF; recording guide in web/docs-assets/README.md), Works-With table + exports + install docs updated, CHANGELOG Unreleased. package.json files/bin updated. Claude-Session: https://claude.ai/code/session_016JWn5jRD5tcEFKrubjQ6Px Co-authored-by: Claude <noreply@anthropic.com>
125 lines
4.9 KiB
Markdown
125 lines
4.9 KiB
Markdown
# Word Doc Tracked Changes Skill
|
|
|
|
Produces properly-structured tracked changes for a Word document — insertions, deletions, replacements, and margin comments formatted so they can be applied directly to the source document. Built to leverage Opus 4.7 improvements in .docx redlining and tracked changes generation.
|
|
|
|
## Required Inputs
|
|
|
|
Ask the user for these if not provided:
|
|
- **The document** (paste the text or upload the .docx)
|
|
- **Review type** (legal review / copy edit / substantive rewrite / compliance check / plain English rewrite)
|
|
- **Review scope** (full document / specific sections / specific clause type)
|
|
- **Reviewer role** (author / manager / legal counsel / subject matter expert)
|
|
|
|
## Output Structure
|
|
|
|
### 1. Redline Summary
|
|
|
|
**Document:** [Name or identifier]
|
|
**Review type:** [As stated]
|
|
**Reviewer:** [Role]
|
|
**Total changes:** [Insertions: N / Deletions: N / Comments: N]
|
|
**Overall assessment:** [1-2 sentences — is this document close to final, or does it need substantial revision?]
|
|
|
|
### 2. Top-Level Changes
|
|
|
|
Changes that affect the meaning or structure of the document:
|
|
|
|
**Change N — [Section or paragraph reference]**
|
|
- Original: "[Exact original text]"
|
|
- Suggested: "[Proposed new text]"
|
|
- Reason: [Why this change — substantive/legal/clarity]
|
|
|
|
### 3. Line-by-Line Tracked Changes
|
|
|
|
For each paragraph that needs changes, format as:
|
|
|
|
**[Paragraph reference — e.g. "Section 3, Paragraph 2"]**
|
|
|
|
Original:
|
|
> [Exact original paragraph]
|
|
|
|
Tracked changes:
|
|
> [Same paragraph with deletions marked as ~~strikethrough~~ and insertions marked as **bold**]
|
|
|
|
Clean version:
|
|
> [Final clean text after applying changes]
|
|
|
|
### 4. Margin Comments
|
|
|
|
Comments that flag issues without proposing a specific wording change:
|
|
|
|
**Comment N — [Location]**
|
|
"[Comment text — written as the reviewer would write it. Direct, specific, actionable.]"
|
|
|
|
Comments are for things like:
|
|
- "This clause conflicts with Section 7 — please reconcile"
|
|
- "Missing definition of [term] used throughout"
|
|
- "Confirm figure with finance team"
|
|
|
|
### 5. Stylistic Edits
|
|
|
|
Line-level stylistic changes (if scope includes copy editing):
|
|
|
|
| Location | Before | After | Reason |
|
|
|---|---|---|---|
|
|
| Para 3 | [Text] | [Text] | [Readability/grammar/consistency] |
|
|
|
|
### 6. Pattern Flags
|
|
|
|
Issues that repeat across the document:
|
|
|
|
**[Pattern — e.g. "Passive voice overuse"]**
|
|
- Instances: [count]
|
|
- Examples: [2-3 specific locations]
|
|
- Suggested approach: [How to address]
|
|
|
|
### 7. Review Completeness
|
|
|
|
| Review dimension | Covered |
|
|
|---|---|
|
|
| Grammar and syntax | Yes / No |
|
|
| Clarity and readability | Yes / No |
|
|
| Substantive accuracy | Yes / No / N/A |
|
|
| Compliance/legal check | Yes / No / N/A |
|
|
| Consistency with referenced documents | Yes / No / N/A |
|
|
|
|
### 8. How to Apply These Changes
|
|
|
|
Instructions for applying the redline:
|
|
|
|
**In Microsoft Word:**
|
|
1. Enable Track Changes (Review tab → Track Changes)
|
|
2. Apply the changes from Section 3 in order
|
|
3. Add comments from Section 4 using Review → New Comment
|
|
4. Send the redlined document back to the reviewer
|
|
|
|
**In Google Docs:**
|
|
1. Switch to Suggesting mode (top right pencil icon)
|
|
2. Apply the changes from Section 3
|
|
3. Add comments using the comment button in the margin
|
|
|
|
## Quality Checks
|
|
- [ ] Every tracked change has the original text preserved exactly
|
|
- [ ] Substantive changes are separated from stylistic changes
|
|
- [ ] Comments are written as the reviewer would write them, not meta-commentary
|
|
- [ ] Pattern issues identified separately from individual changes
|
|
- [ ] Application instructions match the target platform
|
|
|
|
## Anti-Patterns
|
|
|
|
- [ ] Do not paraphrase original text when creating tracked deletions — the original text must be preserved exactly, character for character, or the tracked change cannot be reviewed against source
|
|
- [ ] Do not mix substantive changes with stylistic edits in the same section — reviewers need to approve substantive changes at a different threshold than copy edits
|
|
- [ ] Do not write margin comments as meta-commentary about the review process ("This section needs work") — comments must be actionable instructions the author can act on
|
|
- [ ] Do not flag every imperfect sentence as a change — over-redlining trains authors to accept changes without reading, which defeats the purpose of tracked review
|
|
- [ ] Do not produce a redline without a summary of top-level changes — reviewers read the summary first and use it to decide which changes to scrutinise in detail
|
|
|
|
## Example Trigger Phrases
|
|
- "Redline this contract"
|
|
- "Create tracked changes for this document"
|
|
- "Mark up this document with proposed edits"
|
|
- "Review this and suggest changes in tracked changes format"
|
|
- "Give me a redline version of this draft"
|
|
|
|
## Why This Works Better on Opus 4.7
|
|
Tracked changes require the model to preserve source text exactly while suggesting alternatives — earlier models would paraphrase the original or lose track of which text was original vs suggested. Opus 4.7 improvements specifically target this workflow.
|