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のスクリーンショットは無加工。