markdown-to-pdf

クイックサマリー

目標： 構文ハイライトとカスタム CSS に対応して、Markdown ファイルを PDF に変換します。

ワークフロー：

1. インストール -- 必要なツール（pandoc + wkhtmltopdf または weasyprint）が利用可能であることを確認します
2. 変換 -- 構文ハイライトと任意の CSS を適用して変換を実行します
3. 確認 -- PDF の書式と内容に漏れがないか確認します

主なルール：

• pandoc + PDF エンジン（wkhtmltopdf または weasyprint）が必要です
• コードブロックの構文ハイライトに対応しています
• スタイル設定にカスタム CSS を適用できます

懐疑的な姿勢で臨み、批判的思考と段階的な思考を適用してください。すべての主張には追跡可能な証拠と確信度をパーセンテージで示してください（アイデアの確信度は 80% を超える必要があります）。

markdown-to-pdf

コードの構文ハイライトとカスタム CSS に対応し、Markdown ファイルを高品質な PDF ドキュメントに変換します。

インストールが必要です

このスキルには npm の依存関係が必要です。 次のいずれかを実行してください：

# Option 1: Install via ClaudeKit CLI (recommended)
ck init  # Runs install.sh which handles all skills

# Option 2: Manual installation
cd .claude/skills/markdown-to-pdf
npm install

依存関係： md-to-pdf、gray-matter

注： 初回実行時に、システムの Chrome が検出されない場合は Chromium（約 150MB）がダウンロードされることがあります。

クイックスタート

# Basic conversion
node .claude/skills/markdown-to-pdf/scripts/convert.cjs --input ./README.md

# Specify output path
node .claude/skills/markdown-to-pdf/scripts/convert.cjs --input ./doc.md --output ./output.pdf

# With custom CSS
node .claude/skills/markdown-to-pdf/scripts/convert.cjs --input ./doc.md --css ./my-style.css

CLI オプション

オプション	短縮形	説明	デフォルト
--input	-i	入力 Markdown ファイルのパス	（必須）
--output	-o	出力 PDF ファイルのパス	{input}.pdf
--css	-c	カスタム CSS ファイルのパス	組み込み
--no-highlight		構文ハイライトを無効にする	false
--help	-h	ヘルプメッセージを表示する

機能

• 構文ハイライト： コードブロックを highlight.js で描画します
• カスタム CSS： 独自の CSS でデフォルトのスタイルを上書きできます
• 複数 OS 対応： Windows、macOS、Linux で動作します
• システムの Chrome： 利用可能な場合はインストール済みの Chrome/Chromium を使用します
• Frontmatter 対応： YAML frontmatter を抽出し、タイトルやメタデータに使用します

デフォルトのスタイル

デフォルトの PDF スタイルには、次の設定が含まれます：

• 本文にはセリフフォント（Georgia）
• コードには等幅フォント（Consolas/Monaco）
• 適切なページ余白（2cm）
• コードブロックの背景色による強調表示
• 表の罫線と交互の行色

出力

成功時には JSON を返します：

{
    "success": true,
    "input": "/path/to/input.md",
    "output": "/path/to/output.pdf",
    "pages": 3
}

トラブルシューティング

Chrome が見つからない場合： このスキルは Chromium を自動的にダウンロードします。これを防ぐには、PUPPETEER_SKIP_DOWNLOAD=1 を設定してください。

メモリの問題： 大きなドキュメントでは、より多くのメモリが必要になる場合があります。複数のファイルに分割することを検討してください。

フォントの問題： 一貫した描画のため、base64 でエンコードしたフォントを CSS の @font-face で埋め込んでください。

---

[IMPORTANT] 作業を開始する前に、各ファイルの読み取りタスクも含め、すべての作業を小さなタスクに分割するために TaskCreate を使用してください。これにより、長いファイルによるコンテキストの喪失を防げます。簡単な作業の場合、AI はスキップするかどうかを必ずユーザーに尋ねなければなりません。 AI のミス防止 — あらゆるタスクで避けるべき失敗パターン：

コンテキストが変わったらファイルを読み直してください。 コンテキストの圧縮や再開、長時間にわたる作業によって記憶が古くなることがあります。作業に取りかかる前に、現在のファイルを確認してください。 生成した内容をソースの根拠と照合してください。 AI は API、名前、主張、ドキュメントの事実を幻覚することがあります。記述または参照する前に、該当するソースを確認してください。 削除や名前変更の前に、後続の参照を確認してください。 成果物を削除すると、ドキュメント、生成されたミラー、設定、呼び出し元に古い参照が残る可能性があります。まず参照関係を洗い出してください。 編集後は影響の連鎖全体を追跡してください。 定義を変更しても、派生出力や利用側への影響を見落とすことがあります。完了を宣言する前に、影響を受ける連鎖をたどってください。 最初の出力だけでなく、影響を受けるすべての出力を検証してください。 チェックが 1 つ成功しても、すべてが成功したことにはなりません。変更が影響し得るすべての出力面を検証してください。 既存の値は意図的なものと考え、変更したり不具合として指摘したりする前に、その理由を確認してください。 定数、上限、フラグ、しきい値、文言、パターンを変更または報告する前に、周辺のコンテキストと履歴、呼び出し元の順序、および同じ規則を使う 2 つ以上の同種の呼び出し箇所を確認してください。理由を示さず WHAT だけを記したドキュメントは、根拠のないガードが存在しない証拠ではなく、根拠が欠けているということです。 行動する前に曖昧さを明らかにしてください。黙って解釈を決めないでください。 複数の妥当な解釈がある場合は、明確な質問をするか、リスクを添えて前提を明示してください。 インフラストラクチャーが管理する中間状態ではなく、システムが管理する結果を検証してください。 非同期処理を検証するときは、最終的なビジネス状態を確認してください。共有インフラストラクチャー内で並行実行中のあらゆるプロセスが書き込める、配信や再試行の記録を確認してはいけません。そのようなチェックは単独実行では通過しても、同じインフラストラクチャーをほかの処理が共有した途端に不安定になります。 共有ガイダンスは、それを受け取る役割に関係する内容にしてください。 普遍的なガイダンスは、それを受け取るすべてのスキルやエージェントに役立つものでなければなりません。コード固有の義務は、コード固有のプロトコルにのみ記載してください。

批判的思考の姿勢 — 批判的思考と逐次的思考を適用してください。すべての主張には追跡可能な証拠が必要です。行動するには確信度が 80% を超えていなければなりません。 幻覚の防止： 推測を事実として示さないでください。すべての主張に出典を示し、不確実な点は率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合してください。自分自身の確信を疑ってください。証拠のない確信が、あらゆる幻覚の根本原因です。

必ず注意：批判的思考と逐次的思考を適用してください。すべての主張には適切な追跡可能な証拠が必要です（リポジトリやコードに関する主張には file:line、調査、製品、コンテンツ、ドキュメントに関する主張にはソース URL または成果物のセクション）。行動するには確信度が 80% を超えていなければなりません。60% 未満の場合は、推奨しないでください。幻覚を防止してください。推測を事実として示さず、不確実な点は率直に認め、独立した情報源と照合し、自分自身の確信を疑ってください。

必ず注意：AI のミス防止策を適用してください。生成した内容を根拠と照合し、削除や名前変更の前に後続の参照を追跡し、影響を受けるすべての出力を検証し、コンテキストを失った後はファイルを読み直し、行動する前に曖昧さを明らかにしてください。

プロジェクトプロトコルオーバーレイ — このスキルを実行する前に、適用されるプロジェクトオーバーレイルールを解決してください。プロジェクトのスキルプロトコルインデックス（デフォルトは docs/project-reference/skill-protocols-reference.md。docs/project-config.json の referenceDocs エントリでパスが上書きされる場合があります）の Target 列とこのスキルの名前を照合し、最も具体的に一致する階層のみを適用してください。優先順位は、完全一致 > グロブ > * です。この優先順位が定めるのはオーバーレイ同士の順序のみであり、このスキルとの優先順位ではありません。 一致した本文のみを読み込み、<protocols-dir>/<Name>.md として解決してください。行の Body リンクは表示テキストであり、読み込み先ではありません。一致した本文が存在しない、または形式が不正な場合は、その旨を報告してスキップしてください。インデックスの Description から再構成してはなりません。インデックスがない場合、または一致するものがない場合は、オーバーレイなしで黙って続行してください。契約の全文は .claude/skills/project-skill-protocol/references/registry.md にあります。

オーバーレイは追加のみです。このスキル独自のプロトコルにルールを追加するものであり、既存のルールを置き換えたり、上書き、無効化、再解釈したりしてはなりません。すべてのオーバーレイを取り除いたとき、このスキルの動作が文書化された内容と完全に一致する必要があります。オーバーレイは概要であり、権限を引き上げるものではありません。ワークフローのゲート、Git の規律、レビューゲート、ユーザー確認ゲートを免除することはできません。オーバーレイとスキルの間に実際の矛盾がある場合、または同じ具体性のオーバーレイ同士が直接矛盾する場合は、両方をユーザーに提示してください。黙って解決してはなりません。

必ず注意：実行前に、このスキルに適用されるプロジェクトプロトコルオーバーレイを解決してください。最も具体的に一致する階層のみを適用します（完全一致 > グロブ > *。これはオーバーレイ同士の優先順位であり、このスキルとの優先順位ではありません）。一致した本文のみを <protocols-dir>/<Name>.md から読み込みます。本文が存在しない、または形式が不正な場合は報告し、再構成してはなりません。オーバーレイは追加のみ（このスキル独自のルールを置き換えません）であり、概要であって、権限を引き上げるものではありません。同じ具体性で矛盾がある場合は、ユーザーに提示してください。

最後に確認すること

重要・必ず注意 — 適用されるプロトコル（このスキルに含まれる SYNC／共有ブロックの要約）：

• クリティカルシンキング： 主張ごとに file:line の根拠を追跡します。確信度が 80% を超えてから行動します。推測を事実として提示してはなりません。
• AI のミス防止： 生成した内容を根拠と照合し、後続の参照先を追跡し、影響を受けるすべての出力を検証します。コンテキストを失った後は読み直し、曖昧さがあれば明示します。

重要・必ず注意：作業を始める前に、TaskCreate を使って作業を小さな TODO タスクに分割してください。 重要・必ず注意：新しいコードを作成する前に、コードベース内で類似パターンを 3 つ以上検索してください。 重要・必ず注意：すべての主張について file:line の根拠を示してください（確信度が 80% を超えてから行動します）。 重要・必ず注意：作業の品質を検証するため、最後のレビュー用 TODO タスクを追加してください。

[TASK-PLANNING] 行動する前に、タスクの範囲を分析し、TaskCreate を使って体系的に小さな TODO タスクとサブタスクに分割してください。