docx

name	docx
description	Work with Microsoft Word DOCX files safely. Use when the user asks to inspect, compare, revise, polish, generate, or prepare Word documents, especially SOWs and proposals that need consistent DOCX-ready structure.
tools	["rag_query","request_clarification"]

docx

Overview

Use this skill for .docx and .doc files. Word files are binary OOXML, so the agent should not treat them as plain UTF-8 text. This skill keeps document work grounded and gives proposal-writing a consistent DOCX-ready output contract.

Rules

• Never call read_file on a raw .docx or .doc.
• Prefer indexed document text, derived artifacts, or explicit user-provided excerpts for content inspection.
• If the user provides a DOCX as a style example, extract the structure and writing patterns, not just the topic.
• Do not claim exact Word pagination, headers, footers, comments, tracked changes, or visual layout unless a renderer or DOCX-specific tool confirms them.
• For generated documents, keep markdown as the canonical editable source unless a DOCX export tool is explicitly available.
• If the task is a proposal, SOW, commercial proposal, RFP response, or customer-facing scope document, load proposal-writing and follow its revision and DOCX-ready rules.

Workflow

1. Determine the DOCX task type.

   • Content question or summary
   • Style/template extraction
   • Comparison between two documents
   • Proposal/SOW revision
   • New DOCX-ready document generation

2. Inspect safely.

   • If the DOCX is indexed, use rag_query against the concrete file path.
   • If a derived markdown/text preview exists, use that as the readable source.
   • If the document is not indexed and no derived artifact exists, ask for an exported PDF/text version or use another available DOCX-aware tool if present.

3. Extract structure when using a DOCX as a template. Capture:

   • title block fields
   • heading hierarchy
   • recurring tables
   • signature blocks
   • assumptions / exclusions / acceptance criteria patterns
   • level of detail and commercial tone

4. For proposal/SOW output.

   • Use proposal-writing.
   • Produce /Final_Proposal.md as the canonical source.
   • Make it DOCX-ready with clean numbered headings, tables, plain bullets, and signature blocks.
   • Do not append revised content after old content; rewrite affected sections and rebuild the final document.

5. For exact DOCX output.

   • If a DOCX export/edit tool is available, use it after the markdown source is verified.
   • If no DOCX export/edit tool is available, state that the workspace has a DOCX-ready markdown source and identify any export limitation.

Good uses

• Compare a polished SOW DOCX against a weaker generated proposal.
• Pull heading structure and table patterns from a Word proposal.
• Prepare a proposal in markdown that can be exported cleanly to Word.
• Explain likely limitations when Word layout fidelity matters.

Avoid

• UTF-8 decoding Word binaries.
• Appending "improved" material after an existing document instead of revising it.
• Treating a DOCX preview as exact Microsoft Word layout.