スライドを作る実務の手順（生成スクリプト・ページの枠組み・トーン＆マナー・構成メモ・gws での変換と確認）を Skill に取り込む

何をしたいか

スライド（発表資料・提案資料）を作る実務の手順を NDF の Skill に取り込む。手本は nyle-dx（/work/nyle-dx の edp/slides・mdx/security/slides・fde/presentation）の作り方で、次を持つ。

要素	nyle-dx での形
生成	pptxgenjs の生成スクリプト `slides/build-deck.js`。版面 10 × 5.625 インチ（16:9）
ページの枠組み	共通の関数 `page` / `box` / `note` / `tbl` / `section`（見出し・罫線・ロゴ・著作権表示・ページ番号の位置を固定）
トーン＆マナー	書体・色・文字サイズを定数で持ち、README に表で書く
構成メモ	ページごとの見出し・役割・根拠の表（`04-presentation-notes.md`）と、読み上げの台本。スピーカーノートへ入れる
変換と確認	`gws drive +upload` → `gws drive files copy`（mimeType を Google Slides に）で変換し、`gws slides presentations pages getThumbnail` でページごとに見る

NDF の今の Skill はスライドの原則（design/references/layout-slide.md・release/references/form-slide.md・layout-review）だけを持ち、上の実務の手順を持たない。

方針（利用者の決定 2026-10-17）

新しい Skill を作る前に、既存のスライドの規約（layout-slide.md・form-slide.md・layout-review・document-systems の system-gdrive.md）への統合を優先する
トーン＆マナーは会社色を持たない汎用のテンプレートを既定にし、プロジェクトごとに差し替えられるようにする
取り込んだ手順で、発表資料「独自プラグイン開発の薦め」（題名は 2026-10-18 に公式の語へ揃えた）（台本は第 7 稿 https://docs.google.com/document/d/13nNf3sLjMtrp7WZKHPFD_KW-sv-v5xv5kno2pICfP3U/edit ）を docs/presentations/ に作る
（2026-10-18 追加）Marp（Markdown を変換器でスライドにする経路）はこのプラグインから外す。変換後のスライドが編集できないのは致命的なため。外す範囲は規約とリポジトリの両方: form-slide.md 等のスライドの生成の経路から「変換器を使う」を外して生成スクリプトを既定にし、docs/presentations/ の README・build.sh・AGENTS.md の Marp の記述を生成スクリプトの方式へ書き換える。2026-08-06 の資料は発表日時点の記録として残す
（2026-10-18 追加）python-pptx も pptxgenjs に比べて利点が無いため外す。スライドの生成の経路は「生成スクリプトを書く（pptxgenjs）」の 1 つだけにし、「AI エージェントが組む」をスライドから外す（文書・表計算・ページの形の経路は変えない）。official-skills-autoloader は「スライドを新しく作る」依頼を release の form-slide.md へ回し、公式の pptx Skill は既存の .pptx を読む・直すときだけに使う

由来

2026-10-17 の会話で、python-pptx で独自に組んだ資料に利用者が「slide の作り方が違う。/work/nyle-dx を参考に。Skill 化した方が良いかも」と指摘した。

要求と受け入れ条件

依頼（原文）

slide の作り方が違う。/work/nyle-dx を参考に。Skill 化した方が良いかも

（書き手: 利用者、日付: 2026-10-17。python-pptx で組んだ試作への指摘。起票者が「由来」の節に写した文）

新しい Skill を作る前に既存のスライドの規約（plugins/ndf/skills/design/references/layout-slide.md・release/references/form-slide.md・layout-review・document-systems の system-gdrive.md）への統合を優先する。トーン＆マナーは会社色の無い汎用テンプレートを既定にし、版面と枠組みの関数（page/box/note/tbl/section）は nyle-dx を踏襲、プロジェクトごとに差し替えられるようにする

（書き手: 利用者（2026-10-17 の決定）を AI の起動指示が引継ぎ文書 .ndf/handoff/issue-2065.md から写したもの、日付: 2026-10-17）

取り込んだ手順で発表資料「独自スキルプラグイン開発の薦め」（社外の勉強会・登壇向け、23 ページ、台本は第 7 稿 https://docs.google.com/document/d/13nNf3sLjMtrp7WZKHPFD_KW-sv-v5xv5kno2pICfP3U/edit ）を docs/presentations/ に作る（README・構成メモ・台本・slides/build-deck.js、Google Slides に変換してサムネイルで確かめる）。これも受け入れ条件に含める

（書き手: AI の起動指示（引継ぎ文書の利用者の決定「先に Skill 化し、それで発表資料を作る」「置き場は ai-plugins の docs/presentations/」「台本は第 7 稿で確定扱い（23 ページ）」を写したもの）、日付: 2026-10-17）

文言は直訳の和語を避け業界の語にする（枚→ページ・課題→Issue）。事例のプロジェクトは種類で呼び、名前（nyle-dx を含む社名・案件名）を Skill 本文と発表資料に出さない

python-pptx で独自に組む方式は利用者が却下した（pptxgenjs の生成スクリプト方式にする）

（書き手: AI の起動指示、日付: 2026-10-17。「事例のプロジェクトは種類で呼び名前を出さない」は台本第 7 稿の冒頭にもある利用者の方針、「Skill 本文にも名前を出さない」は起動指示が足した範囲）

起票者の推定

#	条件	推した出所	この要求での扱い
S1	構成メモに「根拠」の列を持たせ、台本をスピーカーノートへ入れる	課題の本文の表（手本 `mdx/security/04-presentation-notes.md` と `addNotes` から起票者が抜き出した）	受け入れ条件 6・7
S2	変換は `+upload` → `files copy`（mimeType 指定）、確認は `getThumbnail` の経路で行う	課題の本文の表（手本の README から）	受け入れ条件 8・9
S3	尺は 350 字/分で測る	起動指示の材料（手本 `fde/presentation/README.md`）	受け入れ条件 7
S4	Skill 本文にも事例のプロジェクト名・社名を出さない	起動指示（台本の方針は発表資料について言っている）	受け入れ条件 12

目的

AI がスライドを作るとき、毎回その場で作り方を組み立てず（python-pptx の自作など）、NDF の規約に従って、生成スクリプト・ページの枠組み・トーン＆マナー・構成メモ・台本・変換と確認の手順をそろえた形で作れるようにする
その手順を実際に通して、発表資料「独自プラグイン開発の薦め」を作り、手順が通ることを示す

前提

前提 1: 生成は pptxgenjs の生成スクリプト（Node.js）で行う。python-pptx で組む方式と、AI エージェントがその場で組む方式は採らない（方針の 2026-10-18 追加）。Marp の経路はこの課題で外す（方針の 2026-10-18 追加）
前提 2: 汎用テンプレートの版面（10 × 5.625 インチ）と枠組みの関数の座標は手本の値を踏襲する。書体・色・著作権表示の文言・ロゴは会社に由来しない値を既定にする（書体は配布先の環境と Google Slides で使える書体から設計で選ぶ）
前提 3: 台本の正本は第 7 稿の Google ドキュメントである。作成時はドキュメントから取得し、手元の写し（会話の作業ディレクトリの script-v7.md）と食い違えばドキュメントを採る。台本はページごとの見出しと読み上げを持つが、ページに載せる要素（図・表・箇条書き）は持たないため、ページの中身は作成時に台本から起こし、構成メモの「役割」「根拠」に書く
前提 4: Google Slides への変換は、利用者の Drive の非公開の場所（フォルダを指定しないアップロード、または利用者の既存の非公開フォルダ）に置く。共有・公開範囲の設定はこの課題で行わない
前提 5: gws は利用者のアカウントで認証済みである（引継ぎ文書）。認証が切れていれば google-workspace の手順で利用者に再認証を頼み、変換と確認の受け入れ条件はそれまで未達とする
前提 6: docs/presentations/ は main へ入ると GitHub Pages で公開される（docs/presentations/README.md）。発表資料は社外向けで、公開されてよい内容だけを置く
前提 7: 規約の文言のうち、この課題で追加・変更する行は「枚」を「ページ」にする。触らない行の言い換えはこの課題の範囲外とする

対象範囲

含む:

既存のスライドの規約（design/references/layout-slide.md・release/references/form-slide.md・layout-review・document-systems/references/system-gdrive.md）へ、生成スクリプト・ページの枠組み・トーン＆マナー・構成メモ・台本・gws での変換とサムネイル確認の手順を足す
会社色を持たない汎用テンプレートの生成スクリプト（pptxgenjs）と、トーン＆マナーの値をプロジェクトごとに差し替える手段
台本の字数と尺（350 字/分）を数える手段
docs/presentations/ の発表資料「独自プラグイン開発の薦め」一式（README・構成メモ・台本・slides/build-deck.js）と、docs/presentations/README.md の資料一覧への追加
Google Slides への変換と、全ページのサムネイルによる体裁レビューの記録

含まない:

新しい Skill の新設（統合で足りないと設計が示した場合だけ、設計 PR で理由を添えて扱う）
python-pptx・LibreOffice による生成の経路の追加と、既存の Marp 資料（2026-08-06-ai-plugins-intro の md・html・pdf）の削除や書き換え
発表資料の共有設定・登壇先への提出・index.html（公開ページの入口）以外の公開操作
台本の内容の書き直し（第 7 稿を確定として使う。ページに収まらない場合の削り方は前提 3 の範囲で構成メモに書く）
規約の既存の行の「枚」の言い換え（前提 7）

ドメインイベント

#	イベント	引き金	失敗したとき	順序の前提
E1	体裁設計で版面・トーン＆マナー・ページの枠組みを決めた	スライドを作る依頼	プロジェクトに既存の資料が無い → 汎用テンプレートの既定値を使う	—
E2	汎用テンプレートから生成スクリプトを用意し、トーン＆マナーをプロジェクトの値へ差し替えた	E1 の決定	差し替える値が欠ける → 既定値のまま生成し、欠けた項目を README に書く	E1
E3	構成メモ（ページごとの見出し・役割・根拠）と台本を書き、尺を測った	内容の確定	尺が持ち時間を超える → 構成メモで削るページを決める	E1
E4	生成スクリプトで pptx を作った	E2・E3 の完了	Node.js か pptxgenjs が無い → 導入の手順を示して止める	E2・E3
E5	pptx を Drive へ上げ、Google Slides へ変換した（既存の URL のまま差し替える場合を含む）	E4 の完了	gws が未認証 → `google-workspace` の手順で利用者に認証を頼んで止める	E4
E6	ページごとのサムネイルを取り、体裁レビューの記録を残した	E5 の完了	文字あふれ・重なり → `layout-review` の差し戻し先（体裁設計・生成・執筆）へ戻す。サムネイルが取れない → 止めて人へ渡す	E5
E7	生成スクリプト・構成メモ・台本・README をリポジトリへコミットした	E6 の完了	—	E6

用語

用語	意味
トーン＆マナー	スライドの書体・色・文字サイズ・著作権表示・ロゴの値の組。プロジェクトごとに差し替える
ページの枠組み	見出し・罫線・ロゴ・著作権表示・ページ番号の位置を固定した、ページを作る共通の関数（`page` / `box` / `note` / `tbl` / `section`）
生成スクリプト	pptx を出力するスクリプト（pptxgenjs の `build-deck.js`）。スライドの正本になる
汎用テンプレート	会社色を持たないトーン＆マナーとページの枠組みを持つ、生成スクリプトの出発点
構成メモ	スライドのページごとの番号・見出し・役割・根拠の表と、構成の考え方を書いた文書
台本	ページごとの読み上げの原稿と配分秒数。スピーカーノートへ入れる

受け入れ条件

リリース後テスト（ndf v10.19.0、2026-10-19 JST）

記録: #2074 (comment)

合否: 不合格（受け入れ条件 17 件中 15 件合格、15・16 が不合格。どちらも plugins/ndf/skills/document-systems/references/system-repo.md の 5〜6 行目で、system-repo.md の記録の説明に Marp と比較の言い回しが残り、#2065 の受け入れ条件 15・16 が通らない #2078 で直す）
11 は合格（注記）: リリースしたノートは書き換え前の正本と一致する。正本は 2026-10-19 09:07 JST に表記を「スキル」へ揃える作業（PR Docs: 発表資料の表記を「スキル」へ揃える (#2065) #2076）で 7 か所が変わった
12: 27 ページの体裁レビューの記録を上のコメントで足した（PR 発表資料の文言をスライドの言葉遣いへ直し、章扉と公式リンクを入れ、呼び方を公式の語へ揃える（#2065） #2072 の記録は 29 ページの時点）
手動確認（プレゼンター表示でノートが読める）: 保留。API では 21 ページにノートがあり、空は章扉 6 つだけ。利用者が発表の準備で開いたときに確かめる

非機能の条件

大項目	条件
運用・保守性	トーン＆マナーの差し替えはプロジェクト側の値だけを書けば済み、汎用テンプレートの更新を取り込むときにプロジェクトの値が上書きされない
セキュリティ	生成スクリプト・規約・発表資料に、Drive のフォルダ ID・ファイル ID・トークンを書かない（例は `<フォルダID>` の形にする）。gws の認証情報はリポジトリに置かない（C1）
システム環境	生成は Node.js 22（CI が使う版）と pptxgenjs で動く。依存の宣言の置き方は設計が決める

影響

対象	影響
公開インタフェース	変わらない（Skill の追加・削除・名前の変更が無い。規約の参照先が増える）
データ	無し
既存の振る舞い	スライドを作るときに AI が読む規約に、生成スクリプトと変換・確認の手順が加わる。Marp（変換器）の経路はスライドの規約とリポジトリの手順から外れる

検証手段

項目	手段
起動	`node <汎用テンプレート> /tmp/t.pptx`、`node docs/presentations/<資料>/slides/build-deck.js /tmp/d.pptx`（パスは設計が決める）
テスト	`uv run --frozen --project . --all-extras pytest . -q -n 4`（生成した pptx のページ数・版面・書体と色の差し替えを確かめるテストを置くかは設計が決める）
静的解析・型検査	`python3 scripts/check-skill-frontmatter.py`・`python3 plugins/ndf/scripts/instructions-check.py --root .`・`python3 plugins/ndf/scripts/doc-lint.py`・`claude plugin validate .`
手動確認（マージ前）	実装者が Google Slides へ変換した発表資料の 23 ページのサムネイルを見て、体裁レビューの記録を PR に残す（受け入れ条件 12）。承認ゲート 2 で利用者がサムネイルか Google Slides を見る
手動確認	利用者が Google Slides のプレゼンター表示でスピーカーノートが読めることを確かめる（リリース後テスト）

前提とする取り決め

項目	参照先 / 決めたこと
プロジェクト構造	Skill の手順は `plugins/ndf/skills/` の既存の規約へ足す（`CLAUDE.md` の「NDF の Skill 構成」）。発表資料は `docs/presentations/`（`AGENTS.md` の「ドキュメント」の表）。汎用テンプレートを Skill の配下に置くか `docs/` に置くかは設計が決める
コーディング規約	Skill の frontmatter は `plugins/ndf/skills/AUTHORING.md`。文書は 1 語 1 意味（Value 8）と用語集。`.md` の文言を照合するテストは書かない（`AGENTS.md` の DON'T）
テスト戦略	生成スクリプトは実行して出力の pptx を検査する（振る舞いのテスト）。規約の文言は検査しない

境界

区分	内容
常に行う	規約に書くコマンドを書く前に実行して確かめる。生成した pptx を Google Slides で描画して見る。既存の検査をすべて通す
確認してから行う	依存パッケージ（pptxgenjs）の宣言の追加、新しい Skill の新設（いずれも承認ゲート 1 の設計で示す）
行わない	python-pptx での生成、台本の内容の書き直し、発表資料の共有設定、手本のリポジトリ（`/work/nyle-dx`）の変更、手本のロゴ・書体・色の複製

未決

項目	誰が決めるか	期限
汎用テンプレートの置き場（Skill の assets か docs か）と、配布物に含めるか	設計（承認ゲート 1 で利用者）	設計 PR
トーン＆マナーの差し替えの手段（設定ファイル・引数・プロジェクト側の定数のファイルなど）	設計（承認ゲート 1 で利用者）	設計 PR
既定の書体と色の値	設計	設計 PR
尺を数える手段をスクリプトにする場所（Value 4）	設計	設計 PR
CI で生成スクリプトを実行するか（Node.js と pptxgenjs の導入）	設計	設計 PR
発表資料のファイル名（`YYYY-MM-DD-<topic>` の日付。発表日が未定）	利用者（承認ゲート 1）	設計 PR

進行

モード: —

振り返り: #2065 (comment)

fix(design): I2 の書き換えの判定を写した元の版との比較にする (#2065)

fix(design): I2 の書き換えの判定を写した時点の lib/ のハッシュとの比較にする (#2065)

Merge pull request #2066 from devbasex/design/issue-2065

Merge pull request #2069 from devbasex/feat/issue-2065-s2065

fix(#2065): PR 2070 のレビュー指摘 4 件を直す

Update: 発表資料のスキルプラグインのページに Anthropic の公式ドキュメントへのリンクを足す (#2065)

Update: 発表資料の「スキルプラグイン」を公式の「スキル」と「プラグイン」へ揃える (#2065)

Update: 発表資料の似たページを 2 組まとめ、27 ページにする (#2065)

Update: 発表資料の「段」「段階」を業界の語へ直す (#2065)

Merge pull request #2072 from devbasex/fix/issue-2065-slide-wording

Merge pull request #2076 from devbasex/docs/issue-2065-skill-wording

Merge pull request #2081 from devbasex/docs/issue-2065-spec

振り返り（2026-10-19）

対象: issue #2065 / PR #2066（設計）・PR #2069・PR #2072・PR #2070（スプリント）・PR #2073（開発版）・PR #2074（ndf v10.19.0）・PR #2081（確定仕様）

スライドを作る手順を、既存の規約（form-slide.md・layout-slide.md・layout-review・system-gdrive.md）へ足した。中身は pptxgenjs の汎用テンプレート、theme.json によるトーン＆マナーの差し替え、構成メモと台本、gws での変換とサムネイルでの確認である。Marp と python-pptx の経路は外した。この手順で、発表資料「独自プラグイン開発の薦め」（27 ページ。台本 21・章扉 6）を docs/presentations/ に作った。

何が起きたか

観点	事実
受け入れ条件	実装中に 3 回変わった。Marp と python-pptx を外す（10-18、決定 12・13）、章扉 6 つを入れる（決定 14）、似たページを 2 組まとめて 23 → 21 ページ（章扉を入れて 27 ページ）にする（10-19）。題名は「独自スキルプラグイン開発の薦め」から「独自プラグイン開発の薦め」になった
手戻り（利用者）	制作物を見た利用者の差し戻しが 2 回あった。(1) ページの文言が台本の文を縮めたもので読みづらく、章扉も無い → 全ページを書き直し、規約に「ページの文言」「章立て」を足した（PR #2072）。(2) ページ 12 の再現率（0.21 / 0.49 / 0.91）が測り直すと再現しない。指標が自己採点だった → 数値を外し、指標の決め直しを #2071 にした
手戻り（語）	「スキルプラグイン」は公式に無い語だった。要求・設計・実装・レビューを通り、リリースの直前に利用者が見つけた（83453e45a）。表記の「Skill」と「スキル」の混在は、リリースの後に PR #2076 で揃えた → #2080
手戻り（レビュー）	PR #2070 の cross-review は 3 ラウンドで収束した（major 4 → 2 → 0）
工程	(1) gws の認証が切れていて、実装のステップが終了コード 1 で止まった。`gws-check.py` はトークンが無いのに認証済みと判定していた → #2067。(2) conductor が検査のプランを `supervise.py run` で流し直した。`run` は後続のプランの差し込みを置き換えない。そのため `7-release.json` の `{queue_pr:check}` で changelog が落ち、`{queue_state:check}` は黙って通った。承認資料の「検査の結果」は「無し」になった → #2079（#1918 にも由来を足した）。(3) `release-steps.py` の bump が版の文書の例を古いまま残した。即時修正の 4 条件の範囲で直した（7015fc4a2・14a64a2f7）
見落とし（リリース後テスト）	17 件中 15 件が合格した。15（doc-lint）と 16（Marp の残り）は、`system-repo.md` の 5〜6 行目の記録の説明で落ちた。この行は cross-review の修正（836d04bfe）で入り、doc-lint はリリースの範囲で打たれていなかった → #2078。確定仕様化で見つけた `distribution-forms.md` 19 行目の「正本の Markdown」も同じ原因で、#2078 に含めた
見落とし（記録）	体裁レビューの記録は PR #2072 に 29 ページの時点の分しか無く、27 ページにした後の記録が無かった。リリース後テストで 27 ページを見直して足した（PR #2074 のコメント）
範囲	範囲外として #2067（gws-check）と #2071（cross-review の指標）を起票した。どちらも由来の形（`issue #2065`）が無く、`issue-file.py by-origin` で拾えなかったため、由来の 1 行を本文に足した

context window の大きさ

この会話のセッション（conductor が仕上げを指示したセッション）の測定である。スプリントの前半は supervise.py が別のセッションで流したため、この表には入っていない。

層	フェーズ	モデル	件数	固定費の中央値	実作業の中央値	実作業 < 固定費	最大充填の最大	目印
conductor	-	claude-opus-5-5	1	45331	113450	0	158781
supervisor	検査	claude-opus-5-5	1	46002	40458	1	86460	束ねる候補
supervisor	仕上げ	claude-opus-5-5	2	46723	125360	0	180053
supervisor	その他	claude-opus-5-5	2	36723	74533	0	140893
worker	修正	claude-opus-5-5	1	46257	17040	1	63297
worker	検証	claude-opus-5-5	1	36728	61031	0	97759
worker	その他	claude-opus-5-5	1	38351	92464	0	130815

層	件数	固定費の合計	実作業の合計	総消費
conductor	1	45331	113450	158781
supervisor	5	212894	440245	653139
worker	3	121336	170535	291871
合計	9	379561	724230	1103791

フェーズ	supervisor	supervisor の実作業	worker の件数	supervisor と worker の固定費の合計	目印
検査	1	40458	1	92259	worker を使いすぎ
仕上げ	1	117152	2	122041	worker を使いすぎ

検査（束ねる候補・worker を使いすぎ）: そのままにする。worker 1 件は修正の 1 回だけで、実作業が固定費より小さいのは修正が小さかったためである
仕上げ（worker を使いすぎ）: そのままにする。worker 2 件は、27 ページの画像を 1 ページずつ見る作業と、確定仕様の執筆である。どちらも出力が大きく、supervisor の context に入れない方が軽い

用語集の変化

コンテキスト	足した語	廃止した語	意味を変えた語
ndf-slide	トーン＆マナー・ページの枠組み・生成スクリプト・汎用テンプレート・構成メモ・台本・トーン＆マナーのファイル・尺	—	—

承認ゲートの差し戻し

gate-rejections.py count（issue #2065 と PR #2066・#2069・#2070・#2072・#2073・#2074）の結果は、関門 1 が 0 件、関門 2 が 0 件だった。上の利用者の差し戻し 2 回は、承認ゲートの外（制作物の Google Slides を見た時点）で起きたため、この数には入らない。

MVV を見直すか

project-mvv.py signals の結果（版 2）は、覆し 0 件（閾値 3）・判定できない 0 件（閾値 5、続けて 0 回、閾値 3）・流出不具合 0 件（閾値 3）で、改訂の提案は無い。利用者の答え: 未回答（supervisor からは問えないため、conductor が問う）

次に変えること

変えること	落とし先	状態
置き換わらない差し込みが残ったプランを、ステップを動かす前に止める。`notes --check-state` は読めないパスを「無し」にせず失敗にする	`supervise.py`・`release-steps.py`（次の変更で試すこと）	#2079 として起票
社外向けの文書で、題と鍵になる語を公式ドキュメントの語と表記に揃える手順を足す	`form-slide.md` か `document-drafting` の手順	#2080 として起票
スライドの規約から Marp の頃の記述の残り（`system-repo.md` 5〜6 行目・`distribution-forms.md` 19 行目）を外す	`document-systems`・`release` の references	#2078 として起票
ページの文言は台本の文を縮めず、章扉で構成を見せる	`layout-slide.md`・`form-slide.md`・`layout-review` の手順	この変更で反映済み（PR #2072）

途中で起票した課題

番号	何を見つけたか	見つけた場面
#2067	`gws-check.py` がトークンの無い状態を認証済みと判定する	実装中
#2071	cross-review の価値を測る指標が自己採点になる	制作物の差し戻し
#2077	棚卸しの順位の表で、前倒しの却下が効かない	棚卸し
#2078	`system-repo.md` の記録の説明に Marp と比較の言い回しが残る（受け入れ条件 15・16）	リリース後テスト
#2079	置き換わらない差し込みが残ったプランのステップがそのまま動く	振り返り
#2080	題と鍵になる語が公式の語かを確かめる手順が無い	振り返り

Navigation Menu

Repository navigation

スライドを作る実務の手順（生成スクリプト・ページの枠組み・トーン＆マナー・構成メモ・gws での変換と確認）を Skill に取り込む #2065

何をしたいか

方針（利用者の決定 2026-10-17）

由来

要求と受け入れ条件

依頼（原文）

起票者の推定

目的

前提

対象範囲

ドメインイベント

用語

受け入れ条件

リリース後テスト（ndf v10.19.0、2026-10-19 JST）

非機能の条件

影響

検証手段

前提とする取り決め

境界

未決

進行

振り返り（2026-10-19）

何が起きたか

context window の大きさ

用語集の変化

承認ゲートの差し戻し

MVV を見直すか

次に変えること

途中で起票した課題

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

スライドを作る実務の手順（生成スクリプト・ページの枠組み・トーン＆マナー・構成メモ・gws での変換と確認）を Skill に取り込む #2065

Description

何をしたいか

方針（利用者の決定 2026-10-17）

由来

要求と受け入れ条件

依頼（原文）

起票者の推定

目的

前提

対象範囲

ドメインイベント

用語

受け入れ条件

リリース後テスト（ndf v10.19.0、2026-10-19 JST）

非機能の条件

影響

検証手段

前提とする取り決め

境界

未決

進行

Activity

takemi-ohama commented on Oct 19, 2026

振り返り（2026-10-19）

何が起きたか

context window の大きさ

用語集の変化

承認ゲートの差し戻し

MVV を見直すか

次に変えること

途中で起票した課題

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions