minorun365/minorun-marp-skill/slide-story

Claude Code and agent skill by minorun365/minorun-marp-skill

Trust tier 3
  • community
Source check pending

Checking that the SKILL.md file is still in the repository.

人前で話す登壇・講義スライドのストーリーの組み方。つかみ、中扉、段階的な開示、見出しの文体、締め方、尺の見積り。「登壇スライドを作って」「LTの資料」「講義資料の構成を考えて」と言われたら、書き始める前に読む。

Install

npx vskill@latest install minorun365/minorun-marp-skill/slide-story

SKILL.md

登壇スライドのストーリーの型

登壇スライドは読ませる資料ではない。話し手が話しやすい紙芝居であり、聞き手が「いまどの話のどこにいるか」を見失わないための道具である。投影して口頭で補う前提なので、配布資料に必要な網羅性や注記は要らない。

この型は、作者(みのるん)が数年分の自作デッキを読み返して抽出したもの。AIエージェントにスライドを書かせると体裁は整うのに中身が薄くなりがちで、その原因の大半は下に挙げる規則のどれかを外していることにある。

着手の順序

  1. 主催者の告知ページで、正式なタイトル・概要・持ち時間を確かめる。応募時の原稿で代用しない。告知で約束した論点が資料に入っているかを、骨子の段階と完成時に照合する
  2. 話し手本人の過去のデッキを1本、実物で読む。型は文章の説明より実物から掴める
  3. 何を伝えたいか、聞き手は誰か、どの話で驚かせるかを、話し手と言葉で詰める
  4. 紙芝居の流れを骨子として合意する
  5. そのページでしか成立しない中身(図、具体例、実物のスクリーンショット、数字)を決める
  6. 体裁はそのあと

テンプレートの型へ内容を流し込む作り方はしない。「アイコン+太字の見出し+1行の説明」のカードを3枚並べた構成を全ページで繰り返すと、体裁は整うのに何も伝わらない資料になる。

やってはいけないこと
  • 申請書や審査資料のような「読ませる資料」の型(カード、対比図、フロー、ハブ図)を持ち込まない。1スライドに4ブロック詰まって、情報が並ぶ割に全部薄くなる
  • 主催者から受け取ったテンプレートや既存スライドの構成を真似ない。合わせるのは画面比率・ロゴ・書体までで、中身の作り方は話し手の型を通す
  • カリキュラム表やアジェンダの項目を、そのままスライドの章とスライド数にしない。要件の網羅は資料の役目ではない

骨格

つかみは聴衆の現在地から

概念の定義から始めない。作者の人気デッキ21本を調べたところ、定義から始まるものは1本もなかった。型は4つある。

  • 共感と困りごとの代弁(「最近、MCPってよく聞きますよね! …ざっと調べても、イマイチ分かりづらくないですか?」)
  • 挑発するクイズ(「AIエージェントとは何か、自分の言葉で説明できますか?」)
  • 時事のフック(「先日、新しいモデルがリリースされました!」)
  • 自分の近況

自己紹介の次は、聴衆への問いかけのスライド2つから入る。「使ってますか?」の次に「作ってますか?」のように、2つ目で手が減る問いを置くと、そこが本編の入口になる。海外のイベントや英語のデッキでも同じ。

セクションの接続は「聴衆の心の声」の中扉

技術カタログの章立てをしない。聞き手がいま抱いたはずの疑問を中扉に書き、次の技術が必然として登場する形にする。

  • 「え、じゃあAIエージェントって何なの…?」
  • 「よし、エージェント書けた! …どこにデプロイする?」
  • 「でも、作るの難しいんでしょ?」

中扉には守る条件がある。

  • 直後のスライドが、その問いの答えになっていること。答えていない中扉は消す。中扉を書いたら、次のスライドの見出しを1スライドずつ確かめる
  • 1行だけにする。小さい文字のサブ行、章ラベル、番号を足さない
  • 連続は2スライドまで。3スライド続くと不自然になる
  • 間隔は本文3〜6スライドごと。本文のスライドが10続くと単調になる
  • 2本のデッキをつないで1本にしたときは、話題が切り替わる継ぎ目に、同じ型の問いかけの中扉を対で置く(「◯◯って何?」と「△△って何?」)。理解を確かめる問いかけの中扉を継ぎ目に置いても、話題の切り替わりは伝わらない
概念の導入は3点セット
  1. 「◯◯ is 何?」(1行の定義と語源の分解。エージェント=代理人 → 誰の? → あなた)
  2. 「何が嬉しいの?」(Before と After)
  3. 「つまり、すごく雑に言うと◯◯」(キメの一言。厳密さは脚注へ逃がす)

説明は抽象 → 具体 → 比喩の3段で進める。比喩は身近で大胆なものがよい(LLMを国民的アニメのロボットに、実行環境を「使い捨ての仮想PC」に喩える)。比喩を出したら、次のスライドではその比喩から製品を導く。比喩の直後に別の切り口の定義を置くと、つながりが切れる。

本編の運び
  1. いきなり具体例(「こんなものが作れます」を先に見せる)
  2. いまのやり方の限界(なぜ次の話が必要か)
  3. 仕組みの説明(図1枚)
  4. やってみる、どう作るか
  5. 詰まるポイント(候補と困りごとを表で並べる)
  6. 解決するもの
  7. 次の一歩

主張と実例は隣に置く。あいだに別の話題を挟むと、説得力の出る例までが遠くなる。雑務の例を主役にしない。中扉で「例えば」と明示し、本質のメッセージを上位に置く。

締め方
  • まとめスライドを作らない。締めは行動を促す中扉(「まずは◯◯から始めてみませんか?」)で着地させ、書影や告知の全面画像で終わる
  • 宣伝スライドを最後に置くなら、その手前に「ありがとうございました」のスライドを入れない。同じ役目のスライドが2つ続いて締まらなくなる
  • 行動喚起の倍率は大げさでよい(「理解の解像度が100倍上がりますよ」)。宣伝は隠さず、様式として堂々と置く

答えを先に出さない

情報を1つずつ足して認知負荷を下げるのが、この型の中心にある。結論や種明かしを先に置くと、その先の面白さが消える。

  • 「今日はこの3つを話します」という予告スライドを作らない。アジェンダ、要点の先出し、結論の宣言はどれも同じ違反
  • 問いを立てたら、答えはその後のスライドで順に開く。1スライドの中で問いと答えを閉じない
  • スライドを足す前に、そのスライドが後の展開の要約になっていないかを確かめる。要約になっていたら要らない
  • 冒頭に「全体像」「地図」「ループ図」を置くのも、同じ違反の別の形である。告知文の言葉が冒頭に出てこないことは欠陥ではない。その要素が自然に出てくる場面へ足す
  • 講演を貫く一本の論理を設計するのは正しい。ただしそれは設計図に置くもので、スライドに書くのは1歩ずつの発見だけにする。「〜の2つです」「あとで証明します」と書きたくなったら、宣言型になっている

この規則は、スライドを作るときだけでなく、レビューでスライドの追加を提案するときにも当てはまる。

演出

資料全体で、次のどれかを最低2〜3か所に入れる。ゼロだと優等生的で単調になる。

  • 段階ビルドアップ図解。仕組みの図は1スライドで完成させず、同じ図を3〜5スライドに割って要素を足していく
  • 偽のエンディングからのどんでん返し(「めでたしめでたし」→「…人生そんなに簡単じゃないんです」)。構成案の段階で、こちらから提案しない。笑いを取る演出は話し手の実話とネタの面白さで決まり、型だけ置くと寒く見える
  • 吹き出しの寸劇。プロトコルや社内調整を、登場人物の会話に翻訳する
  • 感情の絶叫(「多すぎる!!!」)
  • 誤解の先回り(「もしかして、これのこと思い浮かべてませんか…?」)
  • 想定反論と反駁の連打(「ハードル高いわ!」→「違います!」)
  • 名前の由来の豆知識
  • 正直な注意点を最低1スライド。売り込み一辺倒にしない
  • 実体験への独自のネーミング

章が3つ以上あるなら、対応表やステップバーを章の変わり目に再掲して現在地を示す。

型は品質の下限を上げるが、上限は作らない。骨格や演出をなぞっても、ネタの面白さと実話の重みは生成できない。体験談やあるある系の資料は、先に話し手の実話を集めてから組む。この型の正しい使い道は、話し手が中身を出した後の構成チェックと演出の提案である。

ユースケースと固有名詞
  • ユースケースは、その製品の売り(速さ、安さ、並列性など)が無いと成立しない場面だけを選ぶ。どの製品でも成り立つ例は差し戻される。公開されている実装と数字を、出典つきで載せる
  • 課題を定義するスライドは、聞き手が今日使った道具の場面で書く。道具の名前、頼んだ言葉、返ってほしい答えの形まで具体的にする
  • 固有名詞と数字は、話し手本人が説明できる形で置く。論文名には正体を、金額や点数には相場を同じスライドに添える。収まらないなら2スライドに割る
  • 聞き手にエンジニア以外が混ざるなら、コマンド名や製品名を、それが何をするものかの言葉で書く。「git rebase で履歴を整える」は「変更の記録を整理する」にする。名前を知らない人にとって、名前は情報にならない
  • 話し手の手元の設定の数(「ルールを20個入れています」)を載せない。聞き手の環境では意味がないので、どの環境でも通じる書き方にする
  • 専門用語は初出で日本語を補う(レイテンシー(応答の遅れ))。英字の略語には正式名も添える(CDN(Content Delivery Network))

1スライドの情報量

項目規則
1スライドの量見出し1つと本文3〜4行。これ以上載せない
見出し主張の一文。めくった瞬間に何の話か伝わること
本文箇条書き3〜4項目、各1〜2文。階層は1段。4行になったら2スライドに割るか、意味の切れ目で改行する
強調1スライドに1か所まで。デッキ全体では本文2〜3スライドに1か所
記号ダッシュ(――)と全角コロンの多用を避ける
図1スライドに1つだけ、大きく。同じ見出しで「図だけの1スライド」を作ってよい
表2〜3列の単純なもの
見出しの行数1行に収める。折り返すなら言い換える

図を主役にするスライドでは、テキストは見出しと導入の1行までにする。結論や応用は口頭で言えば済む。図の下に補足を2行足すと、図が縮んだうえ本文も詰まって、どちらも中途半端になる。文字を主役にするスライドでは、図は挿絵の大きさに留める。

見れば分かることを小さい文字で足さない。判定は「画面を見れば分かるか、今日の聴衆の判断が変わるか」の1つである。

  • 画像、ロゴ、スクリーンショットに、それが何かを説明する文字を添えない
  • バージョンや提供形態の但し書きは、聴衆の判断が変わるときだけ書く
  • 締めの色文字、グレーの補足行、表の下の小さい注記を足さない
  • 箇条書きは並べられるだけ並べない。4項目目を足す前に「これが無いと伝わらないか」を見る
新しく教える用語の初出は強調する

上の表の「強調は1スライドに1か所」とは別枠で、新しく教える用語や機能名は、地の文での初出1回を強調色の太字にする。

  • 見出し・表・吹き出しの中では塗らない。2回目以降も塗らない
  • 2つの用語を対比して導入するスライドでは、両方を塗る
  • 同じ種類の用語は全部同じ扱いにする。1つだけ塗り忘れると、その用語だけ軽く見える
  • 略語の後ろの括弧に添えた正式名は塗らない
  • 強調で示すので、かぎ括弧では囲まない。見出しの中の用語、話し言葉の引用、画面のボタン名の引用は括弧のままでよい

見出しの文体は混ぜる

全部を敬体に揃えても、全部を常体に揃えても、機械が書いた資料に見える。常体、敬体、体言止め、問いかけ、「!」、口語の独白が入り混じり、その落差がテンポを作る。

1スライドごとに、どの型で書くかを先に決めてから文字にする。素直に書いてからあとで直す、という順序は取らない。敬体で発想した文を常体へ付け替えることになり、それ自体が不自然さの原因になる。

そのページの役割見出しの型例
図、コード、スクリーンショットが主役体言止めの短いラベル(3〜6字でよい)こうなりがち/アーキテクチャ例
主張、気づき常体の言い切り令和のAIエージェントは3行で書ける
驚き、良いニュース、転換「!」で振り切るデフォルトでストリーミング対応!
聴衆の心の声口語の独白よし、エージェント書けた!
想定反論への切り返し、宣伝、締め敬体で落とす…人生そんなに簡単じゃないんです
次のスライドへつなぐ途中で切って引っ張る技術的な下地は十分整ったが…
用語の導入説明句と「用語」AIに記憶をもたせる「メモリー」
中扉の問いかけ「〜の?」何を用意すればいいの?
不自然に聞こえる語尾

常体の言い切り全般が悪いわけではない。引っかかるのは次の2系統だけ。

敬体で発想した文の語尾だけを常体へ付け替えたもの。「割に合いません」を「割に合わない」へ、「育ちました」を「こうして育った」へ切り替えた文がこれに当たる。常体にしたくなったら語尾を切らず、体言止め、勧誘形(〜しよう)、「!」のどれかへ作り直す。

口語の砕けた語尾。「〜てる」(い抜き)、「〜ばいい」、「〜んです」は、機械が親しみやすさを演出するときの定番である。体言止め、「〜しよう」、「OK」へ置き換える。

bash
rg -n '^# .*(てる|ばいい|んです)$' deck.md # 0件が正
書き終えたら、全見出しを並べて数える

不自然さは語彙ではなく均一さとして出る。1スライドずつ見ると自然な日本語なので、通しで並べるまで気づけない。rg -n '^# ' deck.md で一覧にして実測する。作者の手作りデッキ2本(各57〜58スライド)の値は次のとおり。

指標手作りの実測外しているときの値
「!」を含むスライド7〜20%1%
「?」を含むスライド10〜15%7%
敬体のスライド10〜12%1%
最短の見出し3〜6字全スライドが15〜24字に揃う

型の反復も同時に数える。読点でタメて短く落とす二部構成(「覚える言葉は、この3つだけ」)、接続詞で頭を揃える見出し(しかも/実は/ちなみに)、コロン見出しの連発(「品質:」「量:」)は、3スライド以上続くと整理癖の署名になる。

ドキュメントの見出しルールをそのまま持ち込まない。READMEでは見出しを機能名の名詞に揃え、効能の売り文句を消すのが正しい。スライドでは逆で、聞き手を乗せるのが仕事なので「簡単」「〜するだけ!」は正当な要素になる。READMEの見出しは機能を探すための名札で、スライドの見出しは聞き手を次の話へ連れていく一言である。

本文も同じ目で数える

型の反復は本文にも出る。出やすいのは「Xすると、Yになります」「Xなら、Y」「Xしたら、Y」という条件+読点+帰結の形で、1文ずつは自然なので書いている最中には気づけない。1スライドに3つ並んだら、言い切り・体言止め・問いかけを混ぜる。箇条書き3行が全部「〜、〜」の同じ拍になっているときも同じ。

tools/check-ai-smell.py が、この型の反復と、決め台詞・過大な効能・地の文の終助詞などの定番の型を数える。既定では git の HEAD 版と比べて変わったスライドだけを見るので、既存のスライドを巻き込まず、新しく書いた文にだけ当たる。

bash
python3 tools/check-ai-smell.py deck.md # HEAD から変わったスライドだけ
python3 tools/check-ai-smell.py deck.md --all # 新しいデッキは全スライド

引用枠と吹き出し

  • 話し手の発言や実際のプロンプトとして載せる文は、実物のログからしか引かない。それらしい文を作文して「実際に言った」体で置くのは捏造になる。実物が無ければ、「実際に」という前提ごとスライドを書き換える
  • 実物は原文のまま載せる。見栄えのために語尾を整えない。出典の注記(「実際のログより」)もスライドには書かない
  • 色付きの引用枠へ、対句の格言のような「気の利いた一言」を入れない。入れてよいのは、具体的な工程・数字・実例と、実在するプロンプトだけ
  • 吹き出しにスライドの結論を言い直させない。「大正解でした!」のような感嘆の要約ではなく、箇条書きに無い本音の具体を置く
  • 話している人がいない説明文に、吹き出しのしっぽを付けない。しっぽが人物やロボットを指すと、その文はその人の発言に見える。説明文は角丸の箱にし、しっぽは実際のセリフ・依頼文にだけ付ける。流用した画像のページでも同じで、しっぽだけ消して箱にする
  • 枠は役割で塗り分ける。引用や話しかけ例は淡い地と枠線、結論のパンチラインはテーマ色のベタ塗りと白抜き。全部を同じ塗りにすると単調になる
結論の箱は繰り返さず、置くならページの最後

結論やまとめを入れる箱は、続けて使うほど目立たなくなる。

  • 連続する5ページのうち、箱を置くのは2ページまで
  • 本文の途中に置かない。箱の下に地の文が続くと、結論が結論に見えなくなる
  • 箱を置きたくなったら、先に図にできないか、地の文で足りないかを考える。工程や分岐は箱より図が合う

補足のコラムのような色付きの箱も、デッキ全体で数か所に絞る。補足を見つけるたびに箱へ入れると、どのページも同じ見た目になる。吹き出しの直下と表の直下には置かない。形の似た濃い図形が縦に並んで重く見える。

過去のデッキがあるなら、そこから組む

同じテーマのパートが過去のデッキにあるなら、新しい資料はその組み合わせで作る。部品はたいてい既に存在していて、正しく組めばすぐ終わる仕事を、勝手な創作が何巡ものレビューに変える。

  • 内容、順番、言い回しは原文のまま移植する。対で意味を成すもの(「理想はA → だめでもB」のような連鎖)を分解しない
  • 手を入れてよいのは3つ。古くなった事実の更新、会場に合わせた最小限のつなぎ、尺のためのスライド単位の取捨
  • 取捨に迷ったら勝手に落とさず、候補を並べて話し手に選ばせる。そのとき候補のスライドだけを見せない。前後2〜3スライドを含むブロックで、画像として並べる。ページ番号と要約の文章だけでは判断材料にならない
  • 話し手が組み直しで外した枚を、肉付けの候補として戻しに行かない。過去のデッキを棚卸しするときは、構成メモで「入れて外した枚」を先に除いてから候補を出す
  • スライドを足したくなったら、まず過去のデッキに実物が無いか探す。見出しで当たりを付け、PDFを焼いて目で確かめる。画像1枚だけのスライドは本文検索に出ない
  • 見つけた実物は構造ごと写す。箇条書きを増やす、枠で締める、といった補強はすべて盛りすぎになる
  • 定番のスライドを別のデッキへ移すときは、その図を含む全デッキを列挙し、いちばん後に直された版をコピー元にする。直っていない版は別のデッキに残り続ける
  • 節をまるごと派生のデッキから持ってくるときも、コピー元は正本にする。構成メモに派生版から持ってくると書いてあっても、正本の同じ節と並べ、派生が尺の都合で落とした枚(節の入口の図など)が無いかを見てから持ってくる。派生の節をそのまま写すと、入口の図が抜けたまま届く
  • デモをするスライドに専用の中扉を作らない。紹介スライドをそのまま映して実演する
  • 導入用に作ったスライドを、別の文脈の中盤へ流用しない

再演の案件では、直前の回の構成メモを読むまで構成を提案しない。却下された案とその理由は、たいてい次の回にもそのまま効く。再演の依頼は「評判の良かったものをもう一度」なので、枠組みの作り替えは依頼の意図に反する。差を作るのは構成ではなく、事実の鮮度とスライド単位の入れ替えである。地方での開催は、聴衆の大半が初めて聞く前提で組む。

同じ元ネタから2会場ぶんのデッキが並行して育つと、項目ごとに新旧が逆転する。日付が後のほうが新しい、とは決めない。数字、図、言い回し、構成の1つずつを両方で突き合わせる。

派生のデッキで直したことを正本へ戻すときは、文面だけでなく構成(外した枚・動かした枚)も戻す。話し手の判断で外した枚と、章を寄せ直した並びは正本へ戻し、会場の尺で外しただけの枚は戻さない。文面だけ戻して構成を残すと、次の派生が古い並びから作られ、削ったはずの枚が復活する。尺に合わせて枚を削る抜粋版を作る前に、正本と直近の厳選版を見比べ、構成のずれが残っていないかを確かめる。

短尺版は、いちばん新しい正本1本を削って作る

複数のデッキから使えそうな枚を集めて繋ぐと、脈絡のない継ぎはぎになる。土台を1本に決め、そこから落とす方向だけで組む。

  • 土台は、直近で本番を通した版にする。古いデッキの枚は磨き込みが足りず、表が詰まっていて図も古い。同じ見出しの枚が両方にあるなら、新しい側から取る
  • 聞き手に合わせた差分は、汎用の短尺版を先に仕上げてから派生させる。数枚だけ直す形にすると、どこを変えたかがそのまま報告になる
  • 枚数は尺から決める。削り切れずに他のデッキから足したくなったら、土台の選び方を間違えている
別の聞き手へ流用するときは、聞き手の手元の道具で1枚ずつ判定する

同じテーマでも、聞き手がすでに持っている道具と導入状況で、要る枚は変わる。導入前の組織に向けた枚(導入の手続き、製品の選び方、準備の手順)は、導入済みの組織には要らない。逆に導入済みの組織には、すでに使っている道具との使い分けを足す。

構成案を出す前に、全スライドを「その時点の聞き手が、手元の道具でできる話か」で判定した表を作る。

  • 列は、枚番号・見出し・前提にしている道具・その道具はそこまでに登場済みか
  • 概念の話も、例や効能が特定の道具でしか実現できないなら、その道具の前提に数える
  • 前提の合わない枚は削らず、その道具を紹介した後ろへ移す
  • 1枚足したら、その枚と役割の重なる枚を同じ作業のうちに外す
既存のデッキへ足したら、通しで数える

足したスライドは、1ページずつ見れば自然でも、通しで見ると浮く。既存のスライドが持っている癖(強調の入れ方、具体例の置き方、話題の担当範囲)が抜けるためである。足し終えたら、足した分と既存の分で次の3つを比べる。

  • 強調の比率。既存には数ページに1回ずつ強調があるのに、足した分には1つも無い、という偏りが出やすい。上限だけでなく下限も見る
  • 同じ具体例が2か所に出ていないか。足したスライドの例は、既存のスライドが担当していた話題と重なりやすい。固有名詞で rg -n して数える
  • 尺。節を1つ足したら、スライド数の増減が小さくても着地時間を出し直す

既存の文を「元からある」と判断する前に、誰が書いたかを履歴で確かめる。デッキの中には、話し手が書いた文と、過去にエージェントが書いた文が混ざっていて、見ただけでは区別できない。

bash
git log --format='%h %ad %s' --date=short -S'<その文の一部>' -- deck.md | tail -3

エージェントが書いた文だと分かったら、派生元のデッキも同じように直す。直さないと、次の登壇へそのまま乗り続ける。

直すとき

前後の枚と並べて見る

1枚を直す前に、前後2〜3枚を並べた画像で見る。1枚ずつなら問題なくても、並びで崩れることが多い。

  • 同じ形式を3枚続けない。表が3枚続く、同じ位置に同じ色の箱が続く、は単調に見える。1枚を図や挿絵にする、表を後ろへ移す、箱の塗りを変える、左右を入れ替える、のどれかで崩す
  • 1枚だけ際立たせるために、その枚だけ部品のデザインを変えない。そこだけ違和感が出る。共通の部品のまま、列の数と並べ方で差を出す
  • 2つを対比させたい表に、3つ目の列(提供元など)を同じ並びで置かない。三並列に見えて対比が消える。対比の軸以外は行ラベルか本文へ逃がす。表を2つに割るのも見栄えが悪い。表をやめるなら、何を軸に並べたかが見出しと配置で分かる形にする
  • 列が4つ並ぶ表は、大分類2つと小分類に階層化する(「手作り/AI任せ(下書きだけ・仕上げまで)」)
  • 詰まったスライドを、文字を小さくして直さない。結論の箱は大事なことを言っているので、本文と同じ大きさに保つ。直す順は、①重複を削る(説明と引用で同じことを2回言わない)②レイアウトで空きを作る(挿絵を上へ移し、下のブロックを横に広げる)③それでも溢れたら前後の枚へ分ける
  • 短くするときに意味を変えない。端折った結果、意味が通らなくなったり別の主張になったりしたら、要約ではなく改変である。直した文を元の文と並べ、同じことを言っているか確かめてから出す
  • 文字を削っただけで「詰まりを直した」としない。削ると版面の下半分が空き、余白が多いのに文字は詰まって見える絵になる。空いた版面は、そのスライドの役割から使い直す。定義のスライドなら定義を1行で大きく置いて図を添え、コードのスライドならコードを大きくする
  • 図の詰まりを直すときに、全部を箱と矢印へ均さない。消すのは細かい文字で、年表・グラフ・枝分かれ・挿絵のような図の個性は残す(slide-figures「削りすぎない」)
文言は直して見せ、構成とデザインは案を先に見せる

変更の種類で進め方を分ける。混ぜると、決まっていない構成の変更が原本へ入って差し戻される。

変更の種類進め方
文言の直し(語句・言い回し・誤字・見出しの文体)推奨案を1つに決めて原本へ反映し、Before/After で見せる
構成とデザイン(ページの追加・作り直し・削除・順序変更、レイアウト・配色・図・挿絵の入れ替え)原本を触らず、前後の枚と並べた案を見せる。決まってから原本を編集する
  • 構成・デザインの案は、そのページがデッキの流れで担う役割を1行で書いてから組む。役割が書けない案は埋め草になる
  • 案は方向の違うものを2〜3つまで。推奨を1つ決めて先頭に置く
  • 案の画像は原本ではなく、作業用の複製から書き出す
  • 「このページを直して」と言われ、どちらか迷ったら構成・デザインの側として扱う
指摘を受けたら
  • 見出しへの指摘は、指摘された語だけを差し替えて済ませない。そのスライドが何を言うためにあるのかに戻って作り直す。読点を外しただけの見出しは、たいてい意味が伝わらなくなる
  • 「浮いている」「流れがおかしい」と言われたスライドを黙って外さない。正本の流れでそのスライドが本来どこにあったかを探して移す。外すなら、外す候補として先に聞く
  • 採否が決まったら、構成メモに記録して終わりにせず、同じ作業のうちにデッキへ反映し、書き出しと検査まで進める。反映するのは採用と言われたものだけにして、まだ採否を聞いていない案は報告で「未反映(未承認)」と分ける
  • 直したら、全ページの一覧に加えて、直したスライドの Before/After を前後の枚ごと見せる。一覧だけでは、どこが変わったかを話し手が探すことになる。新しく足した枚には「新規」と印を付ける。印が無いと、いつからあった枚なのか分からない
1枚を消す・統合するとき
  • 消す前に、その枚の中身(本文・箱・注意書き・吹き出し・脚注)を1行ずつ列挙し、別の枚へ移すものと一緒に捨てるものを示してから消す。頼まれたのが手順の削除でも、同じ枚に載っている補足(仕様変更の告知、プランの注意など)はたいてい残したいものである
  • 消したあと、差分の削除行を見て、列挙に無い行が消えていないかを確かめる
  • 2枚を1枚に統合するとき、消す側の文言を図の箱へ詰め込まない。箱に入れるのは短いラベル1行にして、消す側の説明は本文の1行か口頭へ回す。ラベルと説明の2行を箱に積むと、情報が詰まって機械が作った図に見える

講義・ハンズオンのデッキ

聞き手が手を動かす講義やハンズオンは、登壇のデッキより説明の責任が重い。画面が1つ違うだけで、参加者はその先へ進めなくなる。

手順

This is the start of the file. Read the full SKILL.md on GitHub.

Security

  • Security scanPassed, 95 of 100Pattern checks on the skill's files.
  • Model reviewPassed

Quality evaluation

  • Task evaluationNot runNo evaluation yet. Run one in Skill Studio.

Source

Popularity

Repository stars
383
Repository forks
13
7-day trend score
30

Stars and forks are for the whole GitHub repository, not this skill alone. Not refreshed yet.

Works with

Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.

  • Claude Code
  • Cursor
  • GitHub Copilot
  • Windsurf
  • Codex
  • Gemini CLI
  • Cline
  • Amp
  • Roo Code
  • Goose
  • Continue
  • Kilo Code
  • Junie
  • Trae
  • OpenHands
  • Qwen Code
  • AI Agent
  • Tabnine Chat
  • Sourcegraph Cody
  • Amazon Q
  • Firebase Genkit
  • Sweep
  • Devin
  • Phind
  • Mentat
  • Claude Desktop
  • Aider
  • GPT Pilot
  • Plandex
  • bolt.new
  • v0
  • Replit Agent
  • Anse
  • TypingMind
  • BetterChatGPT
  • LibreChat
  • Warp AI
  • Pieces
  • Fig AI
Embed badge
vskill VERIFIED badge
[![vskill VERIFIED](https://verified-skill.com/api/v1/skills/minorun365/minorun-marp-skill/slide-story/badge)](https://verified-skill.com/skills/minorun365/minorun-marp-skill/slide-story)

Something wrong with this skill or its page? Tell us.