菜单
Markdown 文書から Word（.docx）を生成する。macOS Pages で開いても表の分断・巨大空白・見出しの孤立が起きない検証済みパターン（python-docx）と、Pages 自動書き出しによるレンダリング検証ループを提供。「mdをdocxにして」「Wordファイルを作って」「docxで納品したい」「チェックリストをWordにして」などのリクエストで起動。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/skanehira/dotfiles --skill utility-md-to-docx命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
実装ループ。/dev-spec が作成した GitHub issue (ゴール / 設計参照 / DoD / 非スコープ / 依存の thin 構成) を入力に、依存順に 1 件ずつ「implementer subagent → 統合レビュー → 修正 ≤2 ラウンド → PR → DoD ローカル実行 → merge → close」で自律実装するオーケストレーター。進捗は issue コメントに残し、詰まった issue は needs-human で駐車して次へ進む。人間の介入はエスカレーション時のみ。issue 作成後にユーザーが直接起動し、エスカレーション回答後の再開も本スキルの再実行で行う。「実装ループを開始」「issue を順に実装して」「残りタスクを自動で実装」などで起動。
設計ループ。ユーザーストーリー → UI スケッチ → ユースケース → 実現可能性検証 → PoC 検証 → 横断設計 (docs/design/DESIGN.md) → 機能設計 (docs/design/features/) → 設計チェック → issue ドラフトチェック → GitHub issue 生成 (親子構造) までを対話的に実行し、人間が issue を確認して実装ループへ引き渡す。 「設計フェーズを開始」「要件を整理したい」「計画を立てたい」「ユーザーストーリーを書きたい」 「技術的に実現できるか確認したい」「機能設計を書きたい」「issue に落としたい」などで起動。 docs/design/ の状態から途中再開・特定フェーズの部分実行も可能。 `cli` / `webapp` のプロダクトモード指定で CLI ツール開発時は UI スケッチ等を軽量化できる。 issue 作成後、/dev-impl がそれを 1 件ずつ実装する。
dev-spec を使わず議論しながら設計を固めるときの進行様式。議論中は決定台帳 (DESIGN_NOTES.md) だけを追記し、節目に dev-spec 互換の DESIGN.md (1 枚) + docs/design/features/ へゼロから落とし込む。「議論しながら設計したい」「設計の壁打ちを文書に残したい」「台帳に記録して」「設計書に落とし込んで」「一旦まとめて」などで起動。
基于 SOC 职业分类
正在显示 SKILL.md
| name | utility-md-to-docx |
| description | Markdown 文書から Word（.docx）を生成する。macOS Pages で開いても表の分断・巨大空白・見出しの孤立が起きない検証済みパターン（python-docx）と、Pages 自動書き出しによるレンダリング検証ループを提供。「mdをdocxにして」「Wordファイルを作って」「docxで納品したい」「チェックリストをWordにして」などのリクエストで起動。 |
| argument-hint | [入力.md] [出力.docx] |
Markdown を元に、レンダリング検証まで込みで Word（.docx）を作る。
単純な変換ツール（pandoc 等）を使わない理由: 生成した docx を macOS Pages で開くと、
keepNext や pageBreakBefore プロパティが「表が見出しから分離して次ページへ飛ぶ」
「ページの大半が空白になる」誤レイアウトを引き起こす（実測で確認済み）。本スキルは
この落とし穴を回避したビルダーを書き、実レンダリングで確認してから完了とする。
前提: python-docx（venv に pip install python-docx）。レンダリング検証は macOS + Pages。
対象の Markdown を Read し、docx で表現する要素を洗い出す:
assets/docx_helpers.py を作業ディレクトリにコピーし、それを import する
Python スクリプトとして文書ごとのビルダーを書く（汎用変換器は書かない。
文書の意図に合わせた列幅・改ページはコード化するのが確実）。
from docx import Document
from docx_helpers import (
setup_a4, add_heading, add_body, add_bullet, make_table,
add_page_break, finalize,
)
doc = Document()
content_width = setup_a4(doc) # A4 + マージン明示。戻り値はコンテンツ幅(cm)
add_heading(doc, "1. 目的")
add_body(doc, "本書は……")
make_table(
doc,
headers=["No", "項目", "確認観点", "チェック"],
col_widths_cm=[1.0, 4.0, 10.0, 2.0], # 合計 ≤ content_width
rows=[["1", "…", "…", ""]],
)
finalize(doc, "出力先.docx")
禁止事項（詳細と実測根拠 → references/pages-compat.md）:
| 禁止 | 代わりに使う |
|---|---|
paragraph_format.keep_with_next | 使わない。見出しの孤立は手順 4 のループで調整 |
paragraph_format.page_break_before | add_page_break()（改ページ文字 w:br の独立段落） |
w:trHeight の手動 append | set_row_height()（python-docx API のみ） |
| セル幅だけ設定して列幅未設定 | make_table()（tblGrid と tcW を一致させる） |
cell.vertical_alignment 後の w:shd append | set_cell_text(bg=...)（正しい要素順で処理） |
venv/bin/python builder.py
生成後、document-skills:docx プラグインの validate.py でスキーマ検証する
（パスは ~/.claude/plugins/cache/**/skills/docx/scripts/office/validate.py を find で解決。
defusedxml lxml が venv に必要）。PASSED になるまで次へ進まない。
スキーマ検証だけではページ割りの問題は検出できない。Pages で実際に書き出して確認する:
open -a Pages && sleep 3 で Pages を起動qpdf --show-npages でページ数を取得し、抜粋 PDF を Read で目視page_break_before=True を付けて 1→4 を再実行Pages の起動エラー（-609 / -1712）への対処も references/pages-compat.md に記載。
推測で直さない。疑わしい要素を 1 つずつ無効化したバリアント docx を作り、 それぞれ Pages で書き出してページ数の変化で犯人を機械判定する （references/pages-compat.md の「二分探索」節）。