# Proposal Review

> 提案簡報結構審查。分析分頁邏輯、標題長度、內容分配，給出合併/拆分/精簡建議。當用戶說「review 這份提案」「簡報結構對不對」「幫我看一下分頁」時使用。

- Skill: `makidevelop/proposal-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add makidevelop/proposal-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/makidevelop/proposal-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: MakiDevelop (https://skillmd.com/u/makidevelop)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/makidevelop/proposal-review

---


# 提案簡報結構審查

## 目標

審查提案簡報的結構品質，針對分頁邏輯、標題精簡、內容分配給出具體建議。可接受 .docx、.pptx 或文字大綱作為輸入。

## 不適用場景

- 簡報已經定稿，不需要結構調整
- 純設計問題（配色、排版、動畫）→ 不在範圍內
- 內容事實性查核 → 用其他工具

## 輸入

從 `$ARGUMENTS` 或對話中取得：

| 欄位 | 必填 | 說明 |
|------|------|------|
| 簡報來源 | 是 | .docx / .pptx 路徑，或文字大綱 |
| 受眾 | 否 | 預設：客戶提案（非技術決策者） |
| 目標時長 | 否 | 預設：30 分鐘 |

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

## Decision Model

### Step 1: 提取結構

依檔案類型提取：
- .docx：用 python-docx 解析標題層級與段落
- .pptx：用 python-pptx 逐頁提取標題與內容摘要
- 文字：直接解析

產出：每頁的標題 + 內容長度 + 所屬章節。

### Step 2: 結構分析

分析以下面向：

1. **分頁邏輯**：有沒有需要合併或拆分的頁面
2. **標題精簡**：超過 15 字的標題，建議縮短版本
3. **內容分配**：單頁資訊量是否過多或過少
4. **節奏控制**：章節間的轉場是否流暢
5. **補充段落**：過長的附錄是否應拆入主體

### Step 3: 彙整建議

將分析整理為結構化建議，分為：
- **必改**：明顯的結構問題
- **建議改**：可以更好但不影響理解
- **可選**：風格偏好

## 輸出格式

```
## 簡報結構審查：{檔名}

### 基本統計
- 總頁數：{N}（建議：{M} 頁以內）
- 章節數：{N}
- 平均每頁字數：{N}

### 必改項目
1. {具體建議 + 原因}

### 建議改項目
1. {具體建議 + 原因}

### 標題精簡建議
| 原標題 | 建議標題 | 原因 |
|--------|---------|------|
| {太長的標題} | {精簡版} | {字數/焦點} |

### 分頁調整建議
| 動作 | 頁碼 | 說明 |
|------|------|------|
| 合併 | S12+S13 | {原因} |
| 拆分 | S30 | {原因} |
```

## Quality Gates

- [ ] 每個建議都有明確原因（不是「感覺不好」）
- [ ] 標題建議都在 15 字以內
- [ ] 考慮了受眾因素（客戶 vs 內部 vs 技術人員）
- [ ] 沒有改動內容本身（只改結構）

## Heuristics

- 客戶提案：每頁 1 個核心訊息，標題直接點出結論
- 內部報告：可以密一點，但每頁不超過 7 個 bullet
- 30 分鐘簡報 → 25-35 頁（含章節頁），每頁約 1 分鐘
- 章節頁讓觀眾知道「現在在哪」，不能省
- 數據頁標題應包含數字（如「會員人均 8,496 元」而非「會員分析」）