consulting-pptx-skill

# コンサル型スライド作成スキル 主軸は規約の正典 `references/slide-rules.md`。ただし最初に全文を読み込まない。**工程ごとに `scripts/rules.py --phase <工程>` で、その工程の要点（数千字。出力は切らずに全部読む）を読み、詳しい根拠が要る項だけ `--sec` で引く。** 部品は規約を満たすことを確かめた20種類（`new_deck.py --list`）から選び、検査で出た指摘は、指摘に書かれた節だけを引いて直す。 成果物は HTML（16:9・1 section = 1スライド）と、Chromium headless shell で印刷した PDF（`snapshot.py`。Chrome 本体と同じ出力）。 ## 読むもの・使うもの | 工程 | 読む・使う | 読まない | | --- | --- | --- | | 1. 定義 | `rules.py --phase plan`（§0・§2・§3・デッキの構造） | — | | 2. 調べる | Web などの一次情報。確かめた数字は `sources.md` に控える | 検索結果の抜粋だけで数字を拾わない | | 3. ストーリーライン | 1 の内容と `new_deck.py --list`（部品の番号・型名・使いどころ） | パーツ集の原本・型カタログ | | 4. 骨組み | `new_deck.py --parts ...`。部品の作りを確かめたいときだけ `new_deck.py --show b09` | パーツ集の原本、`scripts/` の中身 | | 5. 中身を書く | `rules.py --phase build`、ページの形に応じて `--phase chart` / `table` / `process` | — | | 6. 文章を仕上げる | `rules.py --phase text`、`references/ai-smell-lexicon.md` | — | | 7. 検査と直し | `check_all.py`（check_deck・check_layout・出典の照合）、指摘に出た節だけ `rules.py --sec 4.12 5.26`。指摘を消すために中身（数字・事例・行）を足さない | 規約の全文 | | 8. 最後の確認 | `rules.py --phase check`、`snapshot.py` で作る PDF と全ページの画像 | — | | 9. フレッシュアイ・レビュー | `references/content-review-prompt.md` | — | - `local/`（git 管理外）に利用者の組織の規約 `slide-rules.local.md`・禁止語 `forbid.txt`・レガシー色 `old-colors.txt`（check_deck が指定なしで読む。他社の書式で組むときは `--brand none`）があれば、工程1で読む。両方に当たる規則は local が優先。 - テーマが AI の活用・業務の自動化なら、工程1で `references/jinba-context.md` も読む。 - PPTX にするときは `rules.py --phase pptx`、登壇用のピッチは `--phase pitch` を工程1で足す。 - `sources.md` には、調べた数字に加えて、試算・計画値も「前提と算式」と一緒に書く（例: 「3億円 計画値: 基盤1.2億＋人件費…」）。デッキの数字が控えに無いと `check_all.py` が WARN を出す。 ## 手順 1. **定義する**: `python3 scripts/rules.py --phase plan` を読み、目的・成果物の定義・スコープ IN/OUT を3〜5行で決める。依頼の背景（誰に・どの会議で・何を判断してもらうか）が分からなければ聞く。聞けないときは前提を置き、報告に書く。 2. **調べる（必須）**: デッキに載せる数字・事例・固有名詞は、作る前に Web などで一次情報（公式発表・統計・調査の原典）を探して確かめる。確かめたものを `sources.md` に1行ずつ控える（数字・何の数字か・出典名・URL・時点）。`sources.md` と、手順8で書く `qa.md` は、デッキと同じフォルダに置く（スキルのフォルダの中に置かない）。検索結果の抜粋だけで数字を拾わない。見つからない数字は作らず、デッキには「要確認」と書く。テーマの知識ファイルや依頼者の資料があれば先に読む。 3. **ストーリーラインを書く（中身 → 形 → 部品の順）**: まず調べた材料から、1枚1行の主張（タイトル）の列を書く。部品の一覧はまだ見ない。次に、各行の形を、その行の材料の関係（比較・推移・内訳・因果・位置づけ・手順）から決める（§5.12）。最後に、決めた形に合う部品を `python3 scripts/new_deck.py --list` から選び、合う部品が無ければ規約の範囲で自由に組む。定番の並び（サマリー→課題→打ち手→ロードマップ→決裁）は使ってよいが、固定しない（§4.103）。部品を選ぶ前に、書いた列を見直す: 社名と数字を消しても別の会社の資料として通る列なら、型どおりになっている。そのときは、材料に固有の発見（その会社の事情・意外な数字・事例の具体）を主役にしたページを立てるか、中身の薄いページ（打ち手の表に入る程度のロードマップ、サマリーと同じことを言う決裁）をまとめる。タイトルは数でなく中身で書く（「3本柱で進める」でなく柱の名前を書く）。推移・構成比・分布・相関は必ず図。合う部品が無ければ `--list --all` を見るか、規約の範囲で自由に組む。材料が無いページは作らない。1枚の材料が目安（表なら4行以上、グラフなら1本＋読み取り2〜3点、箇条なら主文＋詳細で6行以上）に届かない行は、隣の行とまとめる。枚数の指定は材料で満たし、ページを薄く割って枚数を稼がない（薄いページは版面が空き、検査の FAIL と直しの往復になる）。 4. **骨組みを作る**: `python3 scripts/new_deck.py --parts b01,m01,b09:axb,m05,b10 --title "資料名" -o mydeck.html`（`--parts` には手順3で選んだ部品を並べる。これは書き方の例）。CSS の結合・見出しの様式・ページ番号はスクリプトが揃える。 5. **中身をまとめて書く**: `rules.py --phase build` と `--phase text`、使う形に応じて `--phase chart`・`table`・`process` を読んでから（文章の基準も書く前に読む。書いてから直すと検査の往復が増える）、骨組みの全ページの伏せ字（`Text N`・`ラベル N`・`パーツNN｜…`）を実物に置き換えた完成版を、**1回の Write で書く**。数字は `sources.md` に控えたものだけを使う。試算・計画値は、前提と算式をそのページの注か付録に書く（読み手は sources.md を見ない）。**試算は暗算せず `python3 -c` で計算し、式・入力・結果を sources.md に貼る。** デッキに書く数字と注の式は、貼った結果と一致させる（単位・年数・人数の掛け忘れが最も多い）。右上のラベルは、そのページの話題を日本語で書く。書く時点で次を守る（初稿の FAIL の大半はこの3つ）: 1つの箇条・セルに1文（§7.24）／タイトルは数でなく中身（§4.103）／中身の少ないページは、部品の既定の文字の大きさのままにせず一段大きくするか、前後のページとまとめる（版面の40%超が空くと FAIL。§5.13）。 6. **文章を仕上げる**: 手順5で読んだ `--phase text` の基準で、タイトルを上から通し読みし、文章を直す。直しは必要なページだけ Edit する。 7. **検査をまとめて回し、まとめて直す**: `python3 scripts/check_all.py mydeck.html --sources sources.md` を回す（check_deck・check_layout・出典の照合を1回で行い、指摘をページごとにまとめて出す。`PLAYWRIGHT_MODULE_DIR` が設定されていればそのまま動く。無いときだけ `npm run setup`）。出た FAIL・WARN は、メッセージにある節を `rules.py --sec` で引いてから、ページごとにまとめて直す。**指摘を消すために中身（数字・事例・行）を足さない。** 直しは形（大きさ・配置・分け方・統合）で行い、足すなら手順2に戻って調べたものだけにする。**空きを消すために、部品の CSS を上書きして高さや間隔を伸ばさない**（`height:100%`・`flex:1`・`justify-content:space-around`・`min-height` など。項目の間が空いて間延びし、check_layout が FAIL を出す）。タイトルの大きさ（22pt）も書き換えない。空くなら文字を一段大きくするか、前後のページとまとめる。空きの指摘には、本文の器に付ける zoom の試算（1.15倍まで。本文の大きさがほかのページと揃う範囲に限る）が付くので、その値をそのまま使う（目分量で大きくして、はみ出しと空きを往復しない）。「1.15倍でも収まらない」と出たページは、まとめるか形を変える。直したら両方をもう一度だけ回す。FAIL 0 で次へ。**WARN は直すのが既定。** 残すのは、規約に書かれた例外の条件に当たるときだけで、その条件（§番号）を qa.md に書く。「意図した差」「自然な差」のような理由では残さない。 8. **PDF で全ページを見る**: `rules.py --phase check` を読み、`python3 scripts/snapshot.py mydeck.html` で PDF と、4ページずつまとめた画像を作って、全部の画像を見る。§8 の「目視で確かめる基準」を1つずつ当て、怪しいページは `--page N` で大きく出して確かめる。崩れを見つけたら直して、`check_all.py` をもう一度回す。**見た結果は `qa.md` にページごとに書く**（各ページで当てた基準・見つけた崩れ・直したか）。崩れを1つも書かずに済ませない。見つからなかったページは「該当なし」と書く。 9. **フレッシュアイ・レビュー**（速度優先と言われたとき以外）: 下の「作業の作法」のとおり。 ## 作業の作法（進め方・確認の取り方・直し方・渡し方） 規約（slide-rules.md）は「できあがりが満たすべき基準」、ここは「作業の進め方」。 ### 着手するとき **標準フロー（①→②の順を飛ばして型から入らない）** 1. **ストーリー設計**：イシューツリーで問題を分解し、各スライドで伝えることを1行ずつ並べたストーリーライン（＝将来のタイトル列）を先に作って合意する。行は答えの主張だけでなく、前提の共有・事実の提示・問いの設定も含む。通し読みで1本のスピーチになる並びが基準。スライド枚数・型はこの後で決める 2. **型の適応**：各主張に合う見せ方を型カタログ（`references/archetype-catalog.md`）から選ぶ。合わなければ自由記述で組む 3. **ファクト＆フォーマットチェック**：数値・日付・固有名詞を一次ソースと照合（負の事実は本体を開いて裏取り。実測値には測定条件）。フォーマットは check_deck FAIL 0 ＋ PDF全ページ目視（重なり・はみ出し・泣き別れ・下端揃え） 4. **AI癖の補正**：`references/ai-smell-lexicon.md`（AI特有の語彙・構文・トーン）でセルフチェックし、check_deck の AI臭 WARN をつぶす 5. **フレッシュアイ・レビュー**：文脈を共有しない別エージェントにデッキのファイルを渡して日本語・論理・破綻を指摘させ、採否表を作って採用分を直す（§8。着手時に「速度優先」を選んだ場合だけ省いてよい） - テーマの知識ファイル・一次資料を先に読む。憶測で作らない。 - 目的・成果物定義・スコープIN/OUT を3〜5行で提示してから作る（自明な依頼は除く）。 - **依頼の背景・期待値を先に確認する。** 誰からのどういうリクエストか・下書きレベルか提出版かを明示してから共有する。 - **文言を先にテキストで合意してから作図する。** ストーリーライン（タイトル列）と各ページの「タイトル／結論／載せる内容／見せ方」の4項目を文章で出し、合意してから組む。骨子を台本（話す原稿）にしない。依頼者が先にページ構成やタイトルを渡したときは、次の項のとおり組み替えずに使う。 - **シリーズ物（定例・月次報告・同じ相手への続きの資料）は、前回の最終版を土台にし、変わったところだけ直す。** - 土台は相手に出した最終版に限る。下書き版を土台にしない（下書きの崩れが次回に複製される）。最終版が無い回は、最終版がある回まで遡る。どの回にも無ければ土台を決める前に依頼者に聞く。 - 体裁（型・配色・ページの並び方）は引き継ぐ。前回の文言・数字・アジェンダは引き継がない。進捗・数字は、その回の一次情報（議事録・チャット・メール・実データ）から取り直す。前回の文言をそのまま残してよいのは、本当に変化がない項目で、そのことを確認できたときだけ。 - アジェンダはその回に必要なものに変えてよい。型を揃えることと中身を揃えることは別。 - **量産の前に1枚だけ見せる。** 同じ型を5枚以上に展開するデッキは、代表の1枚を先に仕上げて確認をもらってから横に広げる。確認前に全ページへ広げると、同じ欠陥が全ページに複製される。 - **提案書・納品物・先方内で回る資料は、提出前に経験者のレビューを通す**（§8 チェックリストの最終行）。 - **背景が分からない資料はデッキにしない。** 誰に・どの会議で・何を判断してもらう資料かが確認できないうちは、**1枚の論点整理かテキスト**で出す。枚数を増やすほどAI臭と誤りの露出が増える。量産より1枚の精度が評価軸。 ### 検査・レビュー・直し・渡し方 **PPTX**: `python3 scripts/check_deck.py out.pptx` **HTML**: `python3 scripts/check_deck.py deck.html` **HTMLレイアウト検査**: `node scripts/check_layout.mjs deck.html`：フッターと本文の重なり・タイトル右端/下端のはみ出し・**版面の40%超の空き**（本文が占める縦の範囲の外側。上下に寄せた空きも数える）を実レンダリングで検出（overflow:hidden の黙殺を拾う）。並べた要素の幅・高さ・上端のずれ（§4.51）、片側だけの空き（§4.54）、2か所以上の塗りのハイライト（§4.57）は WARN。 **指摘は規約1行と機械チェックの両方にする。** レビューで受けた指摘は、この規約に1行足すだけでは次のセッションで再発する。測れる指摘（数・位置・語・空き）は check_deck／check_layout に判定を足し、`tests/test_checks.py` に「直していない版で FAIL が出る」「直した版で出ない」の2件を足して `python3 -m unittest discover -s tests` を通す。直していない版で発火しないチェックは、測れていないのと同じ。FAIL が0件のときほど、測れていない経路を疑う（例: 本文のプレースホルダーは以前タイトルしか検査しておらず、`Text 1` だらけのデッキが FAIL 0 で通っていた）。 その後の目視QA（PPTX: スライド分割＋`qlmanage`、HTML: `snapshot.py` でPDF化と画像化）で、孤立折返し・はみ出し・重なり・左右下端の不揃い・凡例の有無・**余白過多や要素の沈み（版面バランス）**を確認する（文字だけ確認して空白過多を見逃さない）。**レビュー指摘を受けたら、まず正本の最新版で再現するかを確認してから直す**（レビュアーが古い版を見ていることがある）。 **フレッシュアイ・レビュー（標準・品質優先では必須の最終工程。速度優先では省く）**。微妙な日本語の言い回しや論理展開は、コンテキストを共有していないエージェントに最後に確認させ、指摘点をリストアップし、どれを修正すべきか決めてから直す: 1. 機械チェック FAIL 0 のあと、`references/content-review-prompt.md` の指示文を**作り方・スキル・こだわりを一切伏せて**別エージェント（Agent ツールの新規エージェント、または新しいセッション）に渡し、**デッキのファイル（HTML／PDF／PPTX）をそのまま読ませる**（画像化は不要。版面まで見せたいときだけ補助でページ画像を添える）。 2. 返ってきた指摘（日本語の言い回し／論理展開／破綻／体裁）を**採否表**にする（プロンプト末尾の形式）。全部直すのではなく1件ずつ「採用／不採用／保留」を決め、意味が変わる言い換えや構成の組み替えは依頼者に採否を委ねる。 3. 採用分を直し、機械チェックを再実行する。不採用は理由を1行残し、採否表を納品報告に添える。 作った本人には見えない食い違いを拾う工程なので、自分で読み直すことの代わりにはならない。 可能なら、**別系統のモデル（例: Codex CLI）にも同じ指示文とファイルを渡して並行に回し、指摘を突き合わせる。** 両方が挙げた指摘を優先して直し、片方だけの指摘は採否表で個別に判断する。同じ系統のモデル同士より、見落としの重なりが小さい（呼び出し方は `content-review-prompt.md`）。 **レビューループの回数はユーザーに選ばせる**: - 「機械チェック → 目視QA → フレッシュアイ・レビュー → 採用分の修正 → 機械チェック再実行」を **1ラリー**と数える。**1ラリー終えたら止めて、成果物と採否表を見せたうえで「もう1ラリー回すか」を聞く。** 頼まれていないのに2ラリー目以降を自走しない。 - 着手時（§0 の前提整理）に、どこまで回すかを先に決めておく: **速度優先**＝機械チェック＋自分の目視のみ（フレッシュアイなし）／**標準**＝1ラリー／**品質優先**＝ユーザーが指定した回数まで（指摘ゼロになったら早く止める）。指定がなければ標準で1ラリー回して聞く。 - **例外：依頼者が回し方を既定として指定済みのとき**（例「フレッシュアイは毎回2〜3回回してから見せて」）は、毎ラリーで止めて聞かずに、その回数まで自走してよい。この場合も、(a) 採用件数が0のラリーが出たら回数が残っていても止める、(b) 意味が変わる言い換え・構成の組み替えは自走中に採用せず、最後にまとめて依頼者に委ねる、(c) 最後に全ラリーの件数を1行ずつ報告する。依頼者の指定が無い資料・初めての相手の資料は、既定（1ラリーで止めて聞く）に戻る。 - 各ラリーの終わりに「今回の指摘件数・採用件数・残っている懸念」を3行で報告する。ループを続ける判断材料になる。 **目視QAと報告の作法**: - 「QA済み」「差し込み済み」と報告するときは、実際に見たページの番号を書く（「全ページ」と書くのは全ページを見たときだけ）。サンプルのページだけ見て全体を保証しない。 - PPTX にしたときは、文字が図形の下に隠れていないか・枠からはみ出していないか・画像が引き伸ばされていないか・空のページや空の表が無いかを全ページで確かめる。機械で先に当てるなら `python3 scripts/check_deck_layout.py deck.pptx`（隠れた文字・スライド外へのはみ出し・文字のあふれの見積もり・画像の縦横比・中身の無い箱を WARN で出す。空のページ・空の表は検出しないので目視で見る）。PowerPoint が手元にある環境では、実物の PowerPoint で開いて修復の警告が出ないことも確かめる（表の XML の要素の並び順や行 ID の重複は、開くまで分からない修復の原因になる）。 - ページごとの文字の大きさのばらつきは、目視でなく PDF で実測する（例: `pdftotext -bbox` で各ページのタイトルの文字高を比べ、同じ値になることを確かめる）。 - 依頼者が手で直したページがあるときは、そのページを正として他のページを揃える。依頼者の直接の編集を、作り直しで元に戻さない。直す前に必ず最新のファイルを読み直す。 - 直すときは、指示された箇所だけを直す。指示されていない箇所、前の版の方が良かった箇所を、ついでに変えない。変えた方がよいと思ったら、変えずに提案として添える。 - 渡す形式（HTML／PPTX／PDF）は受け手で決める。受け手が中身を編集するなら編集できる形式（HTML か PPTX）、見るだけなら PDF。PDF だけを渡して「直してください」と頼まない。図や表を画像で貼らず、受け手が編集できる形で渡す（画像は §4.81 の実画面だけ）。 **直し方・渡し方の作法**: - 1件の指摘は、指摘されたページだけでなく、同じ作りの全ページ・元にした部品・次に作る資料まで当てはめる。 消す・直すよう頼まれた要素は、直して出し直したあとの出力物（PDF）で、全ページから消えていることを確かめてから報告する（直したつもりで残っているのが、繰り返し指摘される）。 - 検査の指摘を消すために、中身（数字・事例・行・ブレット）を足さない。直しは、指摘された箇所の形（大きさ・配置・分け方）で行う。中身を足すのは、材料（一次資料・調べた出典）があり、そのページの主張に要るときだけ。 - 説明を足す・書き換える改訂でも、判断に使う要素（判断の軸・優先順位・凡例）は消さない。優先度などがまだ確かめられていなければ、「仮説」と書いて残す。 - 社内用のページ（確認事項・社内向けの付録）は `section` に `internal` クラスを付けて、1つの HTML で管理する。社外に出すときは、PDF なら `body` に `external` クラスを付けて印刷し（パーツ集の CSS で `section.internal` が外れる）、PPTX なら `html_to_pptx.py deck.html out.pptx --external` で書き出す。毎回手でページを抜かない。 - 渡すファイルの名前は NFC（濁点を1文字にした形）に揃える。macOS は濁点を分けた形で保存することがあり、Windows では文字化けして見える。new_deck.py と html_to_pptx.py は出力名を NFC に揃える。迷うときは英数字の名前にする。 - 編集画面で並べ替え・貼り直しをしたあとは、文字化けが入りやすい。check_deck は置換文字（U+FFFD）・私用領域・制御文字を FAIL にする。 - 送る前に確認を終える。送ってから確認しない。HTML と PDF の両方を渡すなら、見た目が一致しているかを確かめる。 - 内容を直して渡すたびに版の番号を上げ、同じ名前で上書きしない（受け手がどれが最新か分からなくなる）。作業中の細かい手直しを同じ版で上書きするのは可。 作業中は同じ HTML を上書きして回し、PPTX にするのは渡す直前の1回だけにする（手直しのたびに PPTX を作り直すと、どれが最新か分からなくなる）。 - 依頼者が「最近の自分の資料と違う」と言ったら、その案は作り直す。依頼者が直近で承認した実物を2つ以上ページ単位で比べ、違いを次の作業の指示に書き出す。テンプレートより、承認済みの実物を正とする。 - ヒアリングを根拠にした資料は、主張を議事録の本文や業務の一次資料（業務の手順書・Excel）と照らして確かめる。読み手の実際の手順や使っている道具を、一般的な工程名で塗りつぶさない。 ## PowerPoint（.pptx）が要るとき **資料は HTML で仕上げる。PPTX にするのは、ユーザーが「PPTX で」「パワポにして」と明示したときだけ。** 修正・レビューの往復はすべて HTML 上で回し、変換は最後に1回だけにする。HTML のほうが直すのも機械チェックも速く、PPTX で直すと HTML と中身がずれる。PPTX を渡した後に修正が来たら、HTML を直して変換し直す。明示が無ければ PDF で渡す。 1. HTML で手順6〜9（機械チェック FAIL 0・フレッシュアイ・レビュー・PDF 目視）まで済ませる 2. 変換: `python3 scripts/html_to_pptx.py mydeck.html` → 同じフォルダに mydeck.pptx（Node 22+・headless shell（`npm run setup`）・`pip3 install python-pptx` が必要。動画を埋め込むなら ffmpeg） 3. `python3 scripts/check_deck.py mydeck.pptx` を FAIL 0 に。PowerPoint で開いて（または PDF に書き出して）文字の折り返しと重なりを目視する 4. 社外に送るなら、ファイルのプロパティ（作成者・会社名など）を消す。社内用のページ（`section.internal`）は `--external` を付けて書き出すと外れる 変換の中身と限界（詳細は slide-rules.md §8.6）: - 編集できる形で再現: 文字（書体・大きさ・色・行間・折り返し幅・箇条書き書式）、塗りと枠（角丸・clip-path の多角形・CSS の三角形）、罫線、表（結合セル・セルの塗り・罫線・余白・縦書き） - 画像になる（中の文字や数値は編集できない）: SVG のチャート・図、img、背景画像 - CSS の zoom で縮めた部品（追加パーツ集の `.slide` は 0.8 倍）は、文字・行間・罫線・余白にも同じ倍率を掛けて、Chrome で見た大きさのまま書き出す（掛けないと文字だけが 1.25 倍になり、縮んだ箱からはみ出す） - 動画（`<video>`）: 元の mp4 が手元にあれば動画として埋め込む（再生前の静止画は描画された1コマ）。10MB を超えたら WARN - 書体は和文ゴシック＝Yu Gothic、明朝＝Yu Mincho に置き換える。字幅の差で行末が1字ずれることがあるので目視は省かない - 再現しない: 回転・変形（CSS の transform）、`::before`/`::after` で描いた装飾（背景付きの丸数字など。行頭記号の文字は箇条書き書式として再現する）。これらはパーツ側で使わないか、変換後に PowerPoint で直す PPTX を一から手で組むときの見本として `assets/SuperTemplate_62type.pptx`（62型・全スライド編集可能。b28〜b30 は未収録）も置いてある。 ### 既存の資料へ差し込むページ 入れる先の PowerPoint 資料（社内の標準デッキ・作りかけの提案書）を渡されたときは、変換せずに **その資料のマスターの上で直接組む**。変換した PPTX は書体と版面が自前なので、差し込むと浮く（slide-rules §8.7）。文章・表の軸・1枚1メッセージの規約はそのまま。 1. 測る: `python3 scripts/measure_deck.py house.pptx` → `house.skin.json`（書式が .potx で配られたときもそのまま渡せる）。要約を読み、資料を目で見て値を直す 2. 組む: `examples/house_deck_example.py` を手本に `scripts/deck_pptx.py` で組む。書体・地色・ページ番号をスライドに書かない／タイトルはプレースホルダー／表はテキストボックス＋罫線（`table()`）／色は資料のテーマ色 3. `python3 scripts/check_deck.py pages.pptx --house house.skin.json` → FAIL 0。**PowerPoint で開く前に必ず通す**（不正なファイルを開かせると、ユーザーの PowerPoint に修復のダイアログが残る） 4. 全ページを目視する（手段は slide-rules §8 の目視QAと同じ） 5. 渡すのは差し込むページだけのファイル。資料へ入れるのはユーザー（「貼り付け先のテーマを使用」） ## 本スキル使用の注釈 「本資料は consulting-pptx-skill（github.com/carnot-tech/consulting-pptx-skill）で作成」の一文は裏表紙（b10）の左下の出典行に既定で入っている。置けるのは**最終ページの出典行だけ**。他のページにツール名が出ていると `check_deck.py` が FAIL にする（クライアントに出せる体裁）。裏表紙を使わないデッキでは最終ページの出典行に足す。 ## スキルを育てる（更新・自分の規約・PR） このスキルは規約と機械チェックを使った人の指摘で良くなる。次の 3 つを作業の一部として行う。 1. **最新を取り込む。** セッションの最初に、スキルのフォルダが git clone なら `git fetch` して `origin/main` より遅れていれば「スキルの最新版を取り込みますか」と一度だけ聞く（目安は週 1 回）。`git pull` で取り込む。利用者の変更は `local/` に置くので衝突しない。本体のファイルを直接直している場合は、その差分を先に `local/` か PR に逃がす 2. **自分の規約は `local/` に置く。** 利用者から「当社ではこうする」という指摘を受けたら、本体の `references/slide-rules.md` を書き換えず `local/slide-rules.local.md` に 1 行足す。顧客名・案件コードは `local/forbid.txt` に入れて `--forbid` で検査する。自前のパーツ集・差し込み先の資料・`skin.json` は `local/templates/` 3. **汎用化できる指摘は PR にする。** 作業中に、本体の規約の誤検知・見逃し・どの組織でも効く新しい指摘に当たったら、納品後に「この修正を本体に PR で出しませんか」と一度だけ提案する。出し方は `CONTRIBUTING.md`（規約 1 行＋`check_deck` の判定＋修正前に FAIL・修正後に通るテスト）。**PR を作る前に `CONTRIBUTING.md` の「PR に入れないもの」を読む**: 顧客名・案件コード・金額・担当者名・実案件のファイル・`skin.json` は差分にもコミットメッセージにも PR 説明にも入れない（会話に出た案件の文脈が混ざりやすいので push 前に差分と説明を見直す）。1 社の好みや理由の書けない規則は本体でなく `local/` へ。既定を変える規則は条件付きで書く。利用者が承諾したら `gh pr create` まで行う。断られたら次のセッションまで再提案しない ## 色と書体 両パーツ集の既定は同じ暖色系（生成りの地・濃茶の文字・茶のアクセント。本文ゴシック・見出し明朝）。トークンは各ファイルの `<style>` 冒頭 `:root`。片方を変えたらもう片方も揃える。ネイビー系の値はコメントで同梱。意味を持つ色（✕の赤など）は変えない。2系列の区別はメインカラー×グレーの2色に抑える。製品UIのスクリーンショットは無加工。