agentleFS
MakiDevelopMakiDevelop/claude-skills/skills/demo-storytelling/SKILL.md

demo-storytelling

Skill3 starsChanged 8 months agoMITView on GitHub

把 PoC / prototype 包裝成有說服力的 demo 故事。輸入技術成果/受眾/數據,輸出 demo 腳本 + 一頁摘要 + FAQ。當用戶要展示成果、準備 demo、報告 PoC 時使用。

The file

Files
SKILL.md

Demo 故事包裝器

目標

把技術成果轉化為有說服力的 demo 故事。產出包含:完整 demo 腳本、一頁摘要、FAQ 預備。適用於週會報告、面試作品集、LinkedIn 展示、blog 文章。

不適用場景

  • 還沒做出東西(先去做,再來包裝)
  • 純理論研究(沒有可展示的成果)
  • 需要保密的內容(NDA / 公司機密的核心數據)

輸入

從 $ARGUMENTS 或對話中取得:

欄位必填說明
做了什麼是技術成果的簡述
給誰看否預設:技術主管 / 非技術老闆
量化數據否省了多少時間、自動化了什麼、前後對比
展示形式否預設:3-5 分鐘 live demo

若缺必填欄位,直接問用戶。

Decision Model

Step 1: 素材盤點(Pre-flight)

在動手寫腳本前,先盤點手上有什麼:

素材有/沒有沒有怎麼辦
可展示的畫面(截圖/GIF/live)必須有先錄一段或截圖,沒畫面沒 demo
量化數字(時間/成本/準確率)最好有用代理指標或定性描述,標記 TBD
前後對比最好有用情境對比代替數字對比
受眾背景資訊最好有預設用「非技術主管」設定

若關鍵素材(畫面)缺失,先提醒用戶補齊再繼續。

Step 2: 萃取故事核心

從技術描述中抽出三個要素:

要素問題範例
Pain之前怎麼做?多痛?「人工分類 500 張素材要 2 小時」
Solution你怎麼解決的?(一句話)「用 Claude Vision 自動分類 + 標籤」
Impact結果如何?(數字)「30 秒完成,準確率 95%」

關鍵原則:Pain → Solution → Impact 的順序不能變。先讓人感受到痛,才會覺得解法有價值。

Step 3: 受眾調適

根據受眾調整語調和重點:

受眾Hook 類型重點避免
非技術老闆業務數字ROI、效率提升、可擴展性技術名詞、架構圖
技術主管技術亮點架構選擇、為什麼這樣做入門級解釋
同事工程師踩坑經驗實作細節、學到什麼過度包裝
面試官個人貢獻你做了什麼決策、為什麼團隊功勞攬身上
社群 / LinkedIn反直覺洞見意外發現、違反常識的結果太 promotional

Step 4: 建構 Demo 腳本

格式分支

形式時長結構備註
Live demo3-5 分鐘完整五段式(下方)預設
短版 demo60-90 秒Hook + 1 步 demo + Impact週會插播 / Lightning talk
非同步影片2-3 分鐘同 live 但加字幕、可剪輯作品集 / 社群
文字版300-500 字Hook + Problem + 結果Blog 段落 / LinkedIn

結構(3-5 分鐘版)

1. Hook(15 秒)
   → 一句話製造好奇或驚訝
   → 模式:數字對比 / 反直覺 / 提問

2. Problem(30 秒)
   → 用情境描述痛點(不是功能列表)
   → 讓受眾產生「對,我也遇過」的共鳴

3. Live Demo(2-3 分鐘)
   → 按操作順序列出每一步
   → 每步標註:做什麼 + 說什麼 + 停頓點
   → 標記「wow moment」(觀眾會反應的點)

4. Impact(30 秒)
   → 前後對比(時間/成本/品質)
   → 數字 > 形容詞

5. Closing(15 秒)
   → 留下一個記憶點
   → 模式:下一步計畫 / 邀請試用 / 金句收尾

節奏控制

  • wow moment 放在 demo 的 60% 位置(不是開頭也不是結尾)
  • 每步之間有 transition sentence(不要跳躍)
  • 如果有 bug 風險的步驟,準備 fallback 說詞

Step 5: 產出附件

一頁摘要(Slack / Email 用)

[一句話 Hook]

做了什麼:[Solution 一句話]
解決什麼:[Pain 一句話]
成果:[Impact 數字]

想看 demo 的話 [行動呼籲]

FAQ 預備

預測 3 個最可能被問的問題,分兩類:

  • 技術問題:「這個能 scale 嗎?」「API 費用多少?」
  • 業務問題:「能用在其他場景嗎?」「多久能上線?」

每個問題準備:簡短回答(30 秒)+ 如果追問的延伸答案。

輸出格式

## Demo 故事:{標題}

### 受眾:{受眾}|時長:{X} 分鐘

---

### Demo 腳本

**1. Hook**(15 秒)
> "{Hook 台詞}"

**2. Problem**(30 秒)
> {情境描述}

**3. Live Demo**({X} 分鐘)
- Step 1:{操作} → 說:"{台詞}"
- Step 2:{操作} → 說:"{台詞}"
- ⭐ Step 3(wow moment):{操作} → 說:"{台詞}"
- Step 4:{操作} → 說:"{台詞}"

**4. Impact**(30 秒)
> 之前:{舊數據}
> 之後:{新數據}
> 提升:{百分比或倍數}

**5. Closing**(15 秒)
> "{收尾金句}"

---

### 一頁摘要

{Slack/Email 可直接貼的版本}

---

### FAQ 預備

**Q1:{問題}**
簡答:{30 秒回答}
延伸:{如果追問}

**Q2:{問題}**
簡答:{30 秒回答}
延伸:{如果追問}

**Q3:{問題}**
簡答:{30 秒回答}
延伸:{如果追問}

Quality Gates

  • Hook 在 15 秒內能說完,且能製造好奇
  • Pain 用情境描述,不是功能列表
  • Demo 有標記 wow moment
  • 每個 demo step 都有「說什麼」,不只有「做什麼」
  • Impact 數字可回查來源;無數字時使用真實定性結果或標記待補
  • 一頁摘要可以直接貼 Slack 不用修改
  • FAQ 涵蓋至少 1 個技術問題 + 1 個業務問題
  • 語調符合目標受眾(不會對老闆講 API schema)
  • 高風險 demo 步驟有備案(錄影截圖 / 備用敘事)
  • 沒有硬數字時用代理指標,且標記 TBD

Heuristics

成果、時間、準確率與成本必須有來源;下方範例僅為寫作示意,不可當作實際成果。不得把團隊成果改成個人貢獻。

成功案例模式

  • 「原本 2 小時 → 現在 30 秒」→ 數字對比 hook,最容易打動非技術人
  • 「大家都用 X,但我發現 Y 更好」→ 反直覺 hook,LinkedIn 擴散強
  • 「我以為最難的是 A,結果真正卡住的是 B」→ 踩坑故事,工程師共鳴

失敗案例模式

  • 「我用了 X 技術和 Y 框架和 Z 服務...」→ 技術堆疊不是故事
  • 「這個功能可以做 A、B、C、D...」→ 功能列表不是 demo
  • 「AI 是未來趨勢...」→ 空泛開頭,觀眾秒滑走

判斷捷徑

  • 有前後對比數字 → 優先用數字對比 hook
  • 給非技術人看 → 把所有技術名詞換成動作描述
  • 面試用 → 強調「你做了什麼決策」而不是「發生了什麼」
  • 沒有硬數字 → 用代理指標(「從 5 個步驟縮減到 1 個」)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.