mcpField
S
shunk031-writing-technical-slides

shunk031-writing-technical-slides

github.com/shunk031Documents051 installsUpdated 3d ago
Repository

About shunk031-writing-technical-slides

A skill for structuring technical and paper-introduction slides in Markdown. It organizes an outline into a presentation flow and specifies slide content, source references, and whole-deck checks; visual design and file generation are out of scope.

Key features

  1. 01Organizes slide flow
  2. 02Structures slide titles and sections
  3. 03Specifies figures, tables, and sources
  4. 04Checks terminology and citations across slides
  5. 05Outputs Markdown drafts by default

Use cases

  1. 01Draft a technical paper presentation
  2. 02Turn a survey outline into slides

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/shunk031/skills --skill shunk031-writing-technical-slides

After installing, type/shunk031-writing-technical-slidesin Claude Code to confirm it loaded.

Bundled filesreferences/citations.mdreferences/markdown-format.md

Details

From the project README

Note

この SKILL.md を読んだら、📽️ 私は shunk031-writing-technical-slides を読みました。 と言う。

技術スライド

大原則

  • この skill は shunk031-writing-telegraph skill に依存するため、最初に同 skill を読み、骨子をテレグラフ文体にする
    • 同 skill は shunk031-writing-kosshi skill を読み、主張と根拠の階層を先に作る
    • この skill は、骨子を技術・論文紹介スライドに分け、各スライドの構成と引用形式を決める
  • この skill はスライドに載せる文章と構成を扱う
    • 原論文にある図・表・数式のうち、各スライドで参照する候補と出典情報は扱う
    • 配色、具体的な画面配置、図版の加工、アニメーション実装、PPTX や PDF の生成は対象外
  • スライド構成・本文を生成した後は、出力前の検査 を資料全体に対して行ってから出力する
    • 一部のスライドだけを修正した場合も、専門語の初出位置など資料全体に依存する項目は全体を再確認する

既定の出力形式

ユーザーがスライド草稿の形式を指定しない場合は Markdown を使う。ページ単位の形式、構成だけを求められた場合の粒度、枚数の決め方は references/markdown-format.md を参照する。

スライド全体の構成

  • スライド全体は、聞き手が内容を追う順に組み替える
    • 論文紹介では、表紙・自己紹介の後に 本論文の選定理由 を置き、発表者が何に注目したかを先に示してよい
    • 本編は、導入・関連研究・手法・実験設定・結果・議論と制限・今後の展望・まとめなどから、内容に必要な節だけを選ぶ
    • サーベイでは、全体像や分類軸を先に示し、分類ごとの説明、節ごとのまとめ、未解決課題、今後の方向性へ進める
    • 論文の章順を写すのではなく、選定理由で示した問いに答える流れを優先する
    • 複数の貢献を扱う場合は先に全体を示し、個別の説明と実験を経て、まとめで主要な結果を再び統合する
例: 選定理由からまとめまでを並べる

この例が示す規則:

  • 本論文の選定理由を置く: 一枚目で発表者がメモリ削減に注目したことを示す
  • 内容に必要な節だけを選ぶ: メモにない自己紹介、関連研究、今後の展望は加えず、手法、結果、制限、まとめを選ぶ
  • 選定理由で示した問いに答える流れを優先: メモリ削減への関心を起点に、二段階の手法、削減結果、未評価の条件へ進む
  • まとめで主要な結果を再び統合する: 最終スライドで精度維持とメモリ削減を一つの結論にまとめる

入力:

長文検索のメモリ使用量を減らす論文を紹介する。発表者はメモリ削減の仕組みに注目した。手法は候補圧縮と再ランキングの二段階で、ベースラインと同じ精度を保ちながらメモリ使用量を 24 GB から 14 GB に減らした。日本語データでは評価していない。

出力:

1. 本論文の選定理由 | 長文検索のメモリ削減に注目
2. 提案手法 1/2 | 候補圧縮
3. 提案手法 2/2 | 再ランキング
4. 実験結果 | 精度を維持・メモリ使用量 24 GB → 14 GB
5. 議論と制限 | 日本語データは未評価
6. まとめ | 二段階処理で精度とメモリ削減を両立

一枚の構成

  • 一枚では一つの内容を説明し、タイトルで全体のどの節にいるかと、そのスライドで扱う対象を示す
    • スライドタイトルは <節> | <そのスライドで扱う対象> を基本とし、短いラベルには : も使える
      • | は節名とそのスライドの題目の区切りに使う
      • 一つの対象を複数枚で見せる場合は <節> 1/N | <対象> や <節> | <対象> 1/N のように連番を付ける
    • 同じスライドを段階的に表示するときは、本文を保ったまま図や注釈だけを追加することがあるため、同じ本文を別の論点として数えない
    • 枚数が多い場合は、全体の分類や現在の節を繰り返し示し、節の切り替わりでまとめを置いてよい
  • 本論文の選定理由 では、後続スライドでまだ説明していない専門語・手法名・略語を先取りしすぎない
    • 発表者が何に注目したかを、まず平易な日本語で具体化する
    • 例: Adaptive Pruning (AP) の pruning policy に注目 より 重要度の低い計算をどう省いて推論を高速化するかに注目 を優先する
    • 手法名を選定理由で出す必要がなければ、Introduction または Methodology の初出まで待つ
  • 各スライドは、結論を一文だけ置く形式に固定せず、必要な項目を組み合わせる
    • タイトルの下に、主要な結果、結果の解釈、現状と課題、将来方向 など、そのスライドに必要な短い小見出しを置く
    • 各項目は、小見出しの下に主張・分類・手順を置き、その下に根拠・条件・詳しい説明を置き、必要なら定義や例をさらに加える
    • 箇条書き記号の種類は文体の要件にせず、インデントで階層を示す
    • 説明の結論を示す必要があるスライドだけ、➜、示唆、結果の解釈、本研究領域の要点 などで結論を示す
    • タイトル、小見出し、結論だけを拾っても、スライド全体の流れが追えるか確認する
    • 説明文では、普通の日本語で明確に書ける一般語を英語のまま混ぜない
      • 論文固有の手法名、モデル名、指標名、一般に英語表記が定着している固有名詞は原表記を保つ
      • 一般語は日本語に寄せ、英単語と日本語の助詞を不必要に混ぜた表現を避ける
      • 例: baseline → 比較手法、reward → 報酬、ground truth → 正解データ、latency → 推論時間
      • 例: memory footprint → メモリ使用量、error analysis → 誤り分析、training objective → 学習目的
      • accuracy を改善、memory を削減、robust な結果 のような混在表現は避け、精度を改善、メモリ使用量を削減、安定した結果 のように書く
      • 原論文の subsection 名など、英語表記自体に参照価値がある場合は、日本語で説明した後に括弧で正式名称を添えてよい
    • 専門語・略語は、資料全体で最初に登場する箇所で正式名称を示す
      • 日本語名が自然な場合は 日本語名(English Name; ABBR) を基本形とする
        • 例: 主成分分析(Principal Component Analysis; PCA)
      • 日本語名を通常使わない場合は English Name (ABBR) とする
        • 例: Knowledge Distillation (KD)
      • タイトルが初出でも例外にしない
        • タイトルで正式名称を書くと長すぎる場合は、同じスライド本文の最初の出現箇所で正式名称を示す
      • 論文本文で定義済みでも、発表資料では独立して初出表記を行う
      • 正式名称を示した後は、原則として略称を使用する
例: 一枚を複数の小見出しで組み立てる

この例が示す規則:

  • 一枚では一つの内容を説明: 候補圧縮と再ランキングからなる一つの提案手法だけを扱う
  • タイトルは <節> | <そのスライドで扱う対象>: 提案手法 | 候補圧縮と再ランキング で節と対象を分ける
  • 必要な短い小見出しを置く: 索引作成時 と 推論時 で二段階の処理を分ける
  • 小見出しの下に主張・分類・手順を置く: 各処理の内容を対応する小見出しの直下に置く
  • 必要なスライドだけ結論を示す: 最後の ➜ で二段階処理の目的を示す

入力:

提案手法は二段階で処理する。索引作成時に候補を 100 件から 20 件へ圧縮し、推論時に残った 20 件を再ランキングする。候補を先に減らす目的は、推論時の計算量を抑えることである。

出力:

## 提案手法 | 候補圧縮と再ランキング

索引作成時

- 候補数: 100 → 20

推論時

- 残った 20 件を再ランキング

➜ 候補を先に圧縮・推論時の計算量を抑制

出力前の検査

スライド本文を出力する前に、資料全体を先頭から確認する。

専門語・略語
  • 資料内で使用する専門語・略語を確認する
  • 各略語について、資料全体で最初に出現するスライドを特定する
  • 初出箇所で正式名称と略称が対応していることを確認する
  • 正式名称より前に略称だけが出現している場合は修正する
  • タイトル、小見出し、本文、図中注釈を含めて初出を判定する
  • 修正後に資料を先頭から再確認する

例:

  • RAG より前または同じ箇所に 検索拡張生成(Retrieval-Augmented Generation; RAG)
  • KD より前または同じ箇所に Knowledge Distillation (KD)
  • IoU より前または同じ箇所に Intersection over Union (IoU)
スライド全体
  • タイトル、小見出し、結論だけを順に読んで全体の流れが追えることを確認する
  • 論文が述べた事実と発表者の解釈が区別されていることを確認する
  • 一般語が不必要に英語で混在していないことを確認する
  • 本論文の選定理由 に、後でしか説明しない専門語・略語が先取りされていないことを確認する
  • 各スライドの Markdown 草稿に必要な 図・表 と 出典 が付いていることを確認する
  • 論文由来の主張・手法名・数値・図表に、本文中の短い引用が残っていることを確認する
  • **出典** を追加したことで本文中の引用が削除されていないことを確認する
  • 引用が引用対象の直後に置かれていることを確認する

事実と出典

論文の事実と発表者の解釈を分ける。短い近接引用とスライド末尾のリンク付き **出典** は併用し、どちらか一方に集約しない。引用形式と例は references/citations.md を参照する。

保守

この skill または依存先を変更するときは三つの skill を読み、骨子の規則は shunk031-writing-kosshi skill、テレグラフ文体の規則は shunk031-writing-telegraph skill、技術スライド固有の規則はこの skill に置き、重複や矛盾を同じ変更で解消する。

Comments

Markdown supported