mcpField
D
docx

docx

github.com/fcakyonドキュメント1.2k47 回インストール1 日前に更新
リポジトリ

docx について

DOCX 文書の作成、編集、分析を支援するスキルです。docx-js による生成、XML 編集、コンテンツ抽出、コメント、変更履歴、出力検証を扱います。

主な機能

  1. 01docx-js による文書作成
  2. 02XML による既存 DOCX の編集
  3. 03pandoc によるコンテンツ抽出
  4. 04コメントと変更履歴の追加
  5. 05文書の検証とレンダリング

活用シーン

  1. 01DOCX 文書の新規作成
  2. 02既存文書の修正
  3. 03文書テキストのレビューや注釈
  4. 04レンダリング結果とスキーマの確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/fcakyon/claude-codex-settings --skill docx

インストール後、Claude Code で/docxを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

LICENSE.txt
scripts/
__init__.py
accept_changes.py
comment.py
merge_runs.py
scripts/office/helpers/
__init__.py
pptx_chart.py
pptx_slide.py
pptx_theme.py
scripts/office/schemas/ecma/fouth-edition/
opc-contentTypes.xsd
opc-coreProperties.xsd
opc-digSig.xsd
opc-relationships.xsd
scripts/office/schemas/ISO-IEC29500-4_2016/
dml-chart.xsd
dml-chartDrawing.xsd
dml-diagram.xsd
dml-lockedCanvas.xsd
dml-main.xsd
dml-picture.xsd
dml-spreadsheetDrawing.xsd
dml-wordprocessingDrawing.xsd
pml.xsd
shared-additionalCharacteristics.xsd
shared-bibliography.xsd
shared-commonSimpleTypes.xsd
shared-customXmlDataProperties.xsd
shared-customXmlSchemaProperties.xsd
shared-documentPropertiesCustom.xsd
shared-documentPropertiesExtended.xsd
shared-documentPropertiesVariantTypes.xsd

詳細

DOCX の作成、編集、分析

.docx は XML ファイルの ZIP アーカイブです。タスクに応じてアプローチを選択してください。

タスクアプローチ
新しいドキュメントを作成するdocx（npm）スクリプトを作成します — 以下の注意点を参照してください
既存のドキュメントを編集するunzip → word/document.xml を編集 → zip（docx-js は既存のファイルを開けません）
コンテンツを読み取るpandoc -t markdown file.docx

以下のスクリプトパスは、このスキルのディレクトリからの相対パスです。

docx-js での作成 — 注意点

docx は事前にインストールされています — 先に npm install を実行せず、スクリプトを作成して require('docx') を直接呼び出してください。この require に失敗した場合に限り、npm install docx を実行してください。モデルは API を把握しています。注意すべき落とし穴は次のとおりです。

  • ページサイズのデフォルトは A4 です。 米国レターサイズにするには、page: { size: { width: 12240, height: 15840 } } を設定してください（DXA、1440 = 1″）。
  • 横向き： 縦向きの寸法を渡し、orientation: PageOrientation.LANDSCAPE を指定してください — docx-js が内部で幅と高さを入れ替えます。
  • 表には幅の指定が 2 か所必要です： 表の columnWidths と各セルの width を、どちらも WidthType.DXA で設定してください（PERCENTAGE は Google Docs で正しく表示されません）。列幅の合計は表の幅と一致させてください。
  • 表の網かけ： ShadingType.SOLID は黒く表示されるため、必ず ShadingType.CLEAR を使用してください。
  • リスト： • を直接挿入しないでください。LevelFormat.BULLET を使った numbering 設定を使用してください。
  • ImageRun には type: が必須です（"png"、"jpg" など）。
  • PageBreak は Paragraph の中に入れてください。
  • \n は使用しないでください — 個別の Paragraph 要素を使用してください。
  • 目次： 見出しには組み込みの HeadingLevel.* を使用してください。カスタムの見出しスタイルは outlineLevel を設定しないと目次に表示されません。
  • 横罫線の代わりに表を使わないでください — 代わりに段落の下罫線を使用してください。
  • ドットリーダー／同じ行の右寄せ： TextRun の中で PositionalTab（alignment: PositionalTabAlignment.RIGHT、leader: PositionalTabLeader.DOT）を使用してください。. や空白による埋め合わせは使わないでください。

出力を確認する

.docx を作成した後、レンダリングして内容を確認してください。

python scripts/office/soffice.py --headless --convert-to pdf output.docx
pdftoppm -jpeg -r 100 output.pdf page
ls page-*.jpg   # then Read the images

pdftoppm はページ番号をページ総数の桁数に合わせてゼロ埋めします（page-01.jpg…page-12.jpg）。

既存のドキュメントの編集

古い .doc ファイルは、先に変換する必要があります：python scripts/office/soffice.py --headless --convert-to docx file.doc。

unzip -q doc.docx -d unpacked/
find unpacked -type l -delete   # strip symlink entries — docx from external parties is untrusted
python scripts/merge_runs.py unpacked/   # coalesce fragmented runs so text is findable
# edit unpacked/word/document.xml in place — do NOT reformat or pretty-print
(cd unpacked && rm -f ../out.docx && zip -Xr ../out.docx .)
python scripts/office/validate.py out.docx --original doc.docx   # XSD checks; --auto-repair fixes common issues
# redlining? add --author "<the name you redlined under>" to check every edit is tracked

Word では、テキストが多数の <w:r> ラン（変更履歴 ID、スペルチェックマーカーなど）に分割されるため、ドキュメント上で確認できるフレーズが、XML 内で連続した文字列として存在するとは限りません。merge_runs.py は、コンテンツやレンダリングを変えずに、word/document.xml 内の隣接する書式が同じランを結合します。また、.docx を直接指定することもできます（python scripts/merge_runs.py doc.docx -o merged.docx）。

変更履歴： 変更履歴を記録する場合は、--author "<the name you redlined under>" を指定して検証してください（--original が必要です）。これにより、変更したにもかかわらず <w:ins>／<w:del> で囲まれていないテキストが報告されます。これは誤って発生しやすく、変更を承認した表示では見えません。ランは w:id、w:author、w:date 属性を付けた <w:ins>／<w:del> で囲みます。<w:del> 内のテキスト要素は <w:t> ではなく <w:delText> です。段落記号の削除（<w:pPr><w:rPr><w:del w:id=".." w:author=".." w:date=".."/></w:rPr></w:pPr>）は、「この段落を次の段落に結合する」という意味です。そのため、段落全体を削除するには、これに加えてすべてのランを <w:del> で囲みます。<w:del/> は rPr のほかの子要素より前に置く必要があります。順序はスキーマで定められています。

すべての変更履歴を承認したクリーンなコピーを作成するには、python scripts/accept_changes.py in.docx out.docx を実行します。

削除された段落記号を承認すると、その段落は下の段落に結合されるため、ランがすべて削除された段落は消えます。Word ではそのように処理されますが、accept_changes.py と pandoc --track-changes=accept では常にそうなるとは限りません。どちらも同じように失敗します。削除されたテキストは取り除きますが、空になった段落を残すため、自動採番された段落の場合、余分な空の箇条書きとして表示されます。

  • pandoc --track-changes=accept は段落を結合しません。
  • accept_changes.py（LibreOffice）は正しく結合しますが、削除された段落の後に空のスペーサー段落がある場合を除きます。

どちらの表示でも空の箇条書きが表示される場合、それは表示上の問題であり、ドキュメントの欠陥ではありません。段落の削除は XML で確認してください。

コメント

コメントには、相互に関連付けられた 6 つのファイルが必要です。ヘルパーを使用してください。document.xml も編集する場合はディレクトリモード（解凍／再圧縮の手間を省けます）、それ以外の場合は .docx 直接モードを使用します。

# Against an already-unpacked directory (preferred when also placing markers)
python scripts/comment.py unpacked/ "Fees & expenses cap is too low"
python scripts/comment.py unpacked/ "Agreed" --parent 0

# Against a .docx directly
python scripts/comment.py contract.docx "This cap is too low" -o annotated.docx

このスクリプトは、comments.xml、commentsExtended.xml、commentsIds.xml、commentsExtensible.xml、リレーションシップ、コンテンツタイプのオーバーライドを書き込みます。コメント ID は自動で割り当てられます。続いて、コメントを特定のテキストにアンカーするため、word/document.xml に追加する <w:commentRangeStart>／<w:commentRangeEnd>／<w:commentReference> のスニペットを出力します。これらのマーカーを配置するまでは、コメントは存在していても表示されません。

依存関係

docx（npm、プリインストール済み — require('docx') が失敗した場合のみインストール） · pandoc · LibreOffice（soffice） · pdftoppm（Poppler）

コメント

Markdown 対応