1仕組みと動作原理

階層化設計：エンジンはすべて外部の minimax-skills:minimax-docx（サードパーティ製マーケットプレイスプラグイン）に委ねられ、本スキル自体はエンジンコードを持たず、「試行錯誤で得られた運用ノウハウ＋自作ジェネレーター」のみで構成されます。

daymade-docs/docx-creator/SKILL.md

Thin incremental layer over **`minimax-skills:minimax-docx`**. Not a document engine.

SKILL.md は、ホスト側のマーケットプレイスインストールパス（~/.claude/plugins/marketplaces/minimax-skills/skills/minimax-docx/）を参照してエンジンソースコードを読むよう直接指示しています。本リポジトリには当該エンジンは含まれず、その CLI の挙動を本ピン留めソースコード内で検証することはできません。

中国語の公的文書生成は同梱の C# ジェネレーターで実現：Program.cs（約260行の OpenXML + Markdig）が Markdown を AST にパースし、ECMA-376 に準拠して docx を構築します。

daymade-docs/docx-creator/scripts/Program.cs

var mdText = File.ReadAllText(args[0]); var pipeline = new MarkdownPipelineBuilder().UsePipeTables().Build(); var docAst = Markdown.Parse(mdText, pipeline);

使用法：`dotnet run -- <in.md> <out.docx>`。csproj では DocumentFormat.OpenXml 3.2.0 + Markdig 1.3.2（net10.0）が宣言されており、初回実行時に NuGet リストアが必要です。

機械的に判定可能な配置ルール：LineBreakInline を含む段落（甲/乙の情報ブロック、署名欄）は強制的に左揃えとし、その他の本文は両端揃えとします。これを目視ではなくインラインツリー構造で判定します。

daymade-docs/docx-creator/SKILL.md

The rule is machine-checkable, so do not eyeball it: if the markdown paragraph's inline tree contains a `LineBreakInline`, left-align that paragraph; otherwise justify it.

ISSUE-004 の背景：両端揃えを適用すると、複数行にわたる情報ブロックの各行（最終行を除く）で極端な文字間隔の広がりが発生し、中国語の公的文書組版において最も見落とされやすい不具合となっていました。

リスト番号の正確性は OpenXML のセマンティクスに依存：独立した各リストは個別の NumId + LevelOverride(StartOverrideNumberingValue=1) を取得します。同一の NumId を再利用すると、第3条のリストが4から継続して番号付けされてしまいます。

daymade-docs/docx-creator/SKILL.md

Each independent markdown list must get its **own** `NumId` plus a `LevelOverride` carrying `StartOverrideNumberingValue = 1`. Reuse one `NumId` across clauses and clause 3's list silently continues from 4.

ISSUE-005/006 は SDK の落とし穴（クラス名の誤り、要素順序の誤り）です。ISSUE-016 では、numId=0 で番号付けを無効化するという既存の Word のセマンティクスが補足されています。

CJK フォントはデュアルスロット（RunFonts の Ascii/HighAnsi/EastAsia）が必須であり、中国語の太字は黒体（HeiTi）に切り替えます（宋体（SimSun）には真の太字ウェイトがなく、合成太字では文字が潰れるため）。フォントサイズは OpenXML の半ポイント単位を使用します。

daymade-docs/docx-creator/SKILL.md

A run must set `RunFonts { Ascii, HighAnsi, EastAsia }`. Setting only the Latin slots leaves Chinese characters to Word's fallback

Program.cs のコメントでも同様に説明されています：「中国語太字は黒体へ切り替え：宋体には真の太字ウェイトが存在せず、レンダラーによるアルゴリズム合成しかできない」。これは Word の組版メカニズムをコード化したものです。

必須の視覚検証チェーン：生成 → XSD validate（minimax CLI） → LibreOffice ヘッドレスで PDF 変換 → pdftoppm で PNG 出力 → ページごとの Read。qlmanage によるサムネイル確認は明示的に禁止されています（ISSUE-008）。

daymade-docs/docx-creator/SKILL.md

**Banned: `qlmanage` thumbnails as visual proof.** macOS Quick Look renders with a different engine than Word and will happily show a clean-looking page for a document whose info blocks are stretched apart.

検証プロトコルには「すべての失敗パターン」（情報ブロックの引き伸ばしなし／リストが1から再開／表の罫線／署名欄の完全性／孤立した改ページの不在）が網羅されており、Word がインストールされている場合は実機の Word を開いて「互換モード」の有無を確認することも求められます（ISSUE-012：LibreOffice では正常に見えても実機 Word でレイアウトが崩れる事例）。

ドキュメントルーティングテーブルにより、Word/WPS 原稿→PDF、Markdown→PDF をそれぞれ word-to-pdf.md および pdf-creator へ誘導し、正本となる Word 原稿を Markdown 経由で往復（ラウンドトリップ）させることを明示的に禁止しています。

daymade-docs/docx-creator/SKILL.md

| Existing Word/WPS → repaired layout / selected excerpt → PDF | Keep the Word source; follow `references/word-to-pdf.md` and `references/verification_protocol.md` |

description の冒頭でも Word 原稿のルーティングが宣言されています。SKILL.md のルーティング表はさらに詳細です（minimax CLI create やパイプライン B/C の選択基準を含む）。

2コア機能

01markdown → 中国語契約書レベルの docx 生成（自作 OpenXML ジェネレーター、甲乙情報ブロック／署名欄／条項／表に対応）

02独立リストの自動 restart=1、および連番の継続保持（NumId/LevelOverride セマンティクス）

03CJK デュアルスロットフォント／太字時の黒体切り替え／先頭行インデント（10.5pt 時 420 twips）などの中国語組版規則

04A4 ページ設定＋フッターの PAGE フィールドによるページ番号＋ 6種罫線テーブル＋ tblGrid（厳格な ECMA-376 要素順序）

05minimax-docx CLI を介した XSD スキーマ検証（DOTNET_ROLL_FORWARD=Major、ISSUE-003）

06LibreOffice → PDF → PNG のエンドツーエンド視覚検証（失敗パターンリストおよび実機 Word による検証を含む）

07既存の Word/WPS 原稿 → PDF 組版修復・抜粋納品ワークフロー（word-to-pdf.md、Word ソースを保持し Markdown を経由させない）

3外部依存関係

Kind	Dependency / Endpoint
cli	dotnet SDK / dotnet run
package	DocumentFormat.OpenXml 3.2.0 + Markdig 1.3.2（NuGet）
cli	minimax-docx 引擎 CLI（第三方市场插件 minimax-skills，XSD 校验）
cli	LibreOffice soffice --headless（验证转 PDF）
cli	poppler pdftoppm（PDF→PNG）
cli	Microsoft Word.app（可选，macOS 兼容模式复核）

4推奨統制措置と判定根拠

安全運用のための推奨統制措置

Agent 向け

段階的・都度認可、サンドボックス推奨

管理者向け

承認フロー、ロールバック可能、全履歴監査

判定根拠（ファイルパスと抜粋）

scripts/: ローカルスクリプトまたはコマンドの実行: dotnet run（同梱の Program.cs をローカルでコンパイル・実行）
网络端点: 外部ネットワークアクセスの宣言: 初回 dotnet run 時に NuGet 経由で DocumentFormat.OpenXml/Markdig をリストア（SKILL/README に約20秒と明記）
本地工作目录: ファイルの読み書きと成果物の出力: ユーザー指定の out.docx の生成・上書き（SKILL では ~$ ロックファイルの事前確認を注意喚起）、ドキュメント近傍の _docxgen/ へのジェネレーターコピー、/tmp/docx への検証成果物の書き込み

監査ノート： 認証情報の読み取りや外部へのデータ送信はなく、ローカルツールチェーンが中心です。要警戒（Yellow）の理由：① 実行プロセスがサードパーティ製 minimax-skills マーケットプレイスプラグインに強く依存している点（その CLI の挙動は本ピン留めソースコード内で検証できず、サプライチェーン上の留意事項となる）、② 初回 dotnet run 時に公式パッケージを NuGet からリストアするためのネットワーク接続が必須である点、③ 納品対象ファイルを生成・上書きする点。いずれも想定された運用範囲内であり、任意のファイル削除や初期化操作は含まれていません。

5二重目の独立検証

[ok] 零引擎代码、能力在 minimax-docx — SKILL.md 自述 'This skill contains zero engine code'；本仓 grep minimax-docx 仅命中路径引用，引擎目录不在仓库内——外置关系属实。
[unlocatable] minimax-docx validate CLI 行为 — CLI 位于宿主 ~/.claude/plugins/marketplaces/minimax-skills/…，不在本 pin 源码内，其 XSD 校验具体行为无法在此核验；SKILL 自身亦承认依赖其安装。
[ok] 自研生成器 Program.cs — File.ReadAllText+Markdown.Parse+OpenXML 组装流程与 csproj 依赖（OpenXml 3.2.0/Markdig 1.3.2/net10.0）属实；对齐/NumId/字体双槽注释在源码中可定位。
[ok] qlmanage 禁令与 ISSUE-008 叙事 — SKILL.md Banned 段与 known_issues.md ISSUE-008 记录一致；verification_protocol.md 亦重申。
[ok] ISSUE-012 真 Word 兼容模式案例 — known_issues.md 含根因（元素顺序/缺 tblGrid 等）与 'LibreOffice 全绿、真 Word 兼容模式' 的复现记录；verification_protocol Step 3a 强制 Word 复核。
[ok] NuGet 首次还原需网络 — SKILL.md quick start 注明 '(first run restores DocumentFormat.OpenXml + Markdig, ~20s)'；scripts/README 依赖表 'NuGet reachable' 行一致。
[ok] 无凭证/无外发代码 — Program.cs/README/引用文件 token 扫描：无 env 密钥、无 requests/urllib、无 curl；网络仅 NuGet 还原。
[ok] 元数据 — GitHub API：MIT / 1385 stars / pushed 2026-09-09T12:33:29Z；本地 HEAD==pin d5c4678。

6結論

中国語公的文書における Word の組版メカニズム（情報ブロックの配置、宋体の太字化における黒体切り替え、デュアルスロットフォント、NumId の再開）を体系的にコード化し、各項目を ISSUE 記録に紐づけています。

検証チェーンは「レンダラーの忠実度の段階的引き上げ」に基づいて設計されています：qlmanage → LibreOffice → 実機 Word。ISSUE-012 は、忠実度の低い検証では重大な不具合を見落とすことを証明しています。

ECMA-376 の要素順序規律を生成ロジックに組み込むことで、Word の「互換モード」のような検知が極めて困難なレイアウト崩れを根本から防止します。

責務の明確な分離：エンジンの車輪の再発明を避け、minimax-docx を SDK として利用し、自前ではエンジンに不足しているジェネレーターと実運用の知見のみを補完しています。

最適な用途： 実務レベルの中国語契約書、公的文書、内定通知書（offer）などの docx（甲乙ブロック、条項番号、署名欄、捺印版）を必要とするチームおよび個人に適しています。ホスト環境に minimax-docx、.NET SDK、LibreOffice/poppler がインストールされており、全ページを Read して目視確認する検証チェーンを実行する運用が前提となります。

不向きな用途： オフライン環境や .NET 環境がない環境には不向きです。プレーンテキストのみの Word 文書で十分な場合（minimax CLI create を使用すべき）、Markdown → PDF の変換（pdf-creator の領分）、正本となる Word 原稿を Markdown に変換してから再生成するようなワークフロー（SKILL で往復変換が明文明確に禁止）には適していません。

Install Agent-Ready

① Verified Mirror 2026-09-09

Option A · Direct DownloadDownload docx-creator.tar.gz

sha256: 31fc8fead4571a90…

Option B · Copy Guide for Agent

install.json

Agent はこの JSON ガイドから自動的にダウンロードして検証します。

② Upstream GitHub

GitHub Repo ↗

Pinned to commit d5c4678cb5.