---
name: full-analysis-plan
description: >
  สร้างเอกสาร Full Analysis & Strategic Plan สำหรับไอเดีย/โปรเจกต์/ปัญหาที่ผู้ใช้ให้หัวข้อมา
  วิเคราะห์ลงลึกทุกมุมมอง ทุกมิติ จัดลำดับความสำคัญ แสดงวิธีแก้ปัญหาและผลลัพธ์ที่คาดหวังแบบชัดเจน
  Trigger เมื่อผู้ใช้ขอ: วิเคราะห์, plan, แผน, strategic plan, full analysis, วางแผน
---

# Full Analysis & Strategic Plan — Skill

> **หลักการแก่น:** ใช้ Design Thinking (Stanford d.school) เป็นโครงสร้างหลัก
> ทุกอย่างเริ่มจาก **ผู้ใช้/ลูกค้า** เป็นศูนย์กลาง (User-Centric)
> เป้าหมายคือ "เจ๊งในกระดาษ ดีกว่าเจ๊งของจริง"

## เมื่อไรจะใช้ Skill นี้
- ผู้ใช้ให้ **หัวข้อ / ไอเดีย / ปัญหา** แล้วต้องการ plan ที่ลงลึกครบทุกมิติ
- ผู้ใช้ขอ "วิเคราะห์", "ทำ plan", "วางแผน", "strategic plan", "full analysis"

---

## 🧠 แก่นของ Design Thinking ที่ต้องยึดถือตลอดทุก Phase

### User-Centric (ผู้ใช้เป็นศูนย์กลาง)
- การออกแบบทุกอย่างต้องเริ่มจาก "ผู้ใช้" หรือ "ลูกค้า" เป็นหลัก **ไม่ใช่เริ่มจากสิ่งที่ตัวเองอยากทำ**
- ลูกค้าไม่ได้ซื้อสินค้า/บริการ แต่เขา **"จ้าง" แบรนด์เราไปทำหน้าที่บางอย่าง** ให้ชีวิตเขาดีขึ้น (Job to be done)

### Time & Money Efficiency
- ใช้เวลาและเงินให้ **น้อยที่สุด** ในการทดสอบว่าไอเดียนั้นรอดหรือไม่ ก่อนลงทุนก้อนใหญ่

### Time to Market
- ของที่ใช่ อาจมาผิดเวลาก็ไม่ได้ — ต้องรู้จังหวะตลาด

### Action is Key
- "ลงมือทำ" แล้วแก้ปัญหาไปเรื่อยๆ ดีกว่า "คิดมากจนไม่ได้ลงมือทำ" (Overthinking)

### Non-linear Process
- กระบวนการไม่จำเป็นต้องเดินเป็นเส้นตรง — ถ้า Test แล้วไม่เวิร์ค ย้อนกลับไป Empathy หรือ Ideate ใหม่ได้ตลอด

---

## ขั้นตอนการทำงาน (5 Phases ตาม Design Thinking)

### Phase 1: 🫂 Empathy — เข้าอกเข้าใจผู้ใช้/ลูกค้า
> ไม่ใช่ "เราจะทำอะไร" แต่ **"เราจะช่วยแก้ปัญหาให้ใคร"**

**สิ่งที่ agent ต้องทำ:**

1. **ฟังผู้ใช้ให้จบก่อน** — อย่ารีบ plan ถามคำถาม clarify ถ้าจำเป็น
2. **แนะนำ `/grill-me`** ให้ผู้ใช้ — เพื่อเปิด interactive interview mode สัมภาษณ์เชิงลึก:
   - ลูกค้า/ผู้ใช้ปลายทางคือใคร? (Target Segment ให้ชัดเจน — ไม่สามารถขายให้ทุกคนได้)
   - Pain point ที่แท้จริงคืออะไร? (Insight มักไม่ได้มาจากสิ่งที่ลูกค้า "พูด" แต่มาจากพฤติกรรมจริง)
   - มีงบเท่าไหร่? มีเวลาแค่ไหน? มี constraints อะไร?
   - Success metric วัดยังไง?
   - มีคู่แข่ง/ทางเลือกอื่นที่รู้จักไหม?
   - เป้าหมายหลักคืออะไร? (revenue / user growth / ลดต้นทุน)
3. **รีเสิร์ชระบบ/โค้ดที่เกี่ยวข้อง** — ใช้ subagent research ถ้ามี codebase อ่านทุกไฟล์ที่เกี่ยวข้อง
4. **เข้าใจ context** — สถานะปัจจุบัน, สิ่งที่ทำเสร็จแล้ว, สิ่งที่ยังไม่มี, tech stack

> ⚠️ ถ้าผู้ใช้ให้ข้อมูลมาครบแล้ว หรือบอกว่าไม่ต้อง grill → ข้าม `/grill-me` ได้
> 💡 เทคนิค OIC: Observe (สังเกต) → Interact (พูดคุย) → Co-create (ร่วมสร้าง)

---

### Phase 2: 🎯 Define — ระบุโจทย์ปัญหาให้ชัด
> นำข้อมูลจาก Phase 1 มาขมวดปมเป็น **"โจทย์เดียว"** ที่ชัดเจน

**สิ่งที่ agent ต้องทำ:**

สำหรับแต่ละประเด็นที่ผู้ใช้ต้องการ ต้องตอบ 3 อย่างให้ได้:

| องค์ประกอบ | คำถาม | ตัวอย่าง |
|---|---|---|
| **User** | ลูกค้าคือใคร? | SME ไทย 5-30 คน ที่ใช้ LINE อยู่แล้ว |
| **Need** | เขาต้องการอะไร? | ระบบลางานที่ง่าย ไม่ต้อง install app เพิ่ม |
| **Insight** | ปัญหาลึกๆ ที่เขาเจอคืออะไร? | ลาผ่านแชท → ลืม/สับสน ไม่มีหลักฐาน หัวหน้าไม่เห็นภาพรวม |

**เงื่อนไขสำคัญ — Business Viable:**
- ปัญหาที่เลือกมาแก้ ต้องเป็น **"ปัญหาที่คุ้มค่าทางธุรกิจ"**
- มีขนาดตลาดใหญ่พอ หรือ ถ้าตลาดเล็ก ลูกค้าต้องยอมจ่ายแพงหรือซื้อซ้ำได้
- วิเคราะห์จากทุกมิติ: มุมผู้ใช้, มุมธุรกิจ, มุมเทคนิค, มุมการตลาด

---

### Phase 3: 💡 Ideate — ระดมไอเดียสร้าง Solution
> หาทางออกให้กับโจทย์ปัญหาใน Phase 2 — **เน้น "ปริมาณ" มากกว่า "คุณภาพ" ในช่วงแรก**

**สิ่งที่ agent ต้องทำ:**

1. **ระดมไอเดีย (Brainstorm)** ให้มากที่สุดเท่าที่จะมากได้:
   - กฎ **"Yes, and..."** — ห้ามตีตกไอเดีย ให้ต่อยอดกันไปเรื่อยๆ
   - **Quantity over Quality** — ไอเดียที่ดี มักจะมาจากไอเดียที่เยอะ
   - **The Power of Exhaustion** — ช่วงแรกจะคิดไอเดียซ้ำซาก แต่เมื่อคิดจน "ล้า" สมองจะถูกบังคับให้คิดนอกกรอบ ได้ไอเดียที่มีโอกาสสร้างนวัตกรรมจริง
   - **อย่าฆ่าไอเดียทิ้ง** — ไอเดียที่ไม่เวิร์ควันนี้ อาจไปเวิร์คอีกช่วงเวลาหนึ่งของตลาด

2. **จัดลำดับความสำคัญ** แต่ละไอเดียเป็น task:
   - 🔴 **P0** — ต้องทำก่อน (ผลกระทบสูงสุด)
   - 🟡 **P1** — สำคัญ (ทำหลัง P0)
   - 🟢 **P2** — Nice to Have

3. **สร้างเอกสาร Plan** ในไฟล์ markdown ด้วยโครงสร้างมาตรฐาน (ดูหัวข้อ "โครงสร้างเอกสาร" ด้านล่าง)

---

### Phase 4: 🧪 Prototype — ออกแบบต้นแบบ / MVP
> ทำของขึ้นมาเพื่อทดสอบสมมติฐาน — **"ยังไม่ต้องทำให้เสร็จสมบูรณ์"**

**สิ่งที่ agent ต้องทำ:**

1. **ระบุ MVP (Minimum Viable Product)** สำหรับแต่ละ task:
   - ต้นแบบที่มี **ต้นทุนต่ำสุด + ใช้เวลาน้อยสุด** เพื่อทดสอบว่าไอเดียเดินต่อได้ไหม
   - **ทดสอบที่ Core Value** — เช่น ถ้าจะเปิดร้านกาแฟ ทดสอบ "รสชาติ" ก่อน ไม่ใช่ไปทุ่มแต่งร้าน

2. **ระบุ MMP (Minimum Marketable Product)** — เมื่อทดสอบ MVP ผ่าน จึงค่อยระบุว่าต้องพัฒนาอะไรเพิ่มเพื่อพร้อมทำตลาดจริง

3. **ตรวจสอบคุณภาพ** ก่อนส่งมอบ:
   - [ ] ทุก task มี **ปัญหา + วิธีแก้ + ผลลัพธ์** ครบ
   - [ ] จัดลำดับ **P0 / P1 / P2** ทุก task
   - [ ] มี **ตารางสรุป** ทุกประเด็น
   - [ ] มี **Priority Matrix ภาพรวม** รวมทุกประเด็น
   - [ ] มี **คำแนะนำการเริ่มต้น** ที่ actionable
   - [ ] วิธีแก้มี **ตัวอย่างเป็นรูปธรรม** (mock output, UI sketch, data format)
   - [ ] ระบุ **ความยาก** และ **ข้อกำหนดเบื้องต้น** ของแต่ละ task
   - [ ] ระบุ **MVP** ของแต่ละ task (ทำอะไรน้อยที่สุดเพื่อทดสอบ)

---

### Phase 5: 🧪 Test — ทดสอบกับตลาดจริง / Execute
> นำต้นแบบไปวางให้กลุ่มเป้าหมายลองใช้ เพื่อดูปฏิกิริยาและนำ feedback กลับมาแก้ไข

**สิ่งที่ agent ต้องทำ:**

1. **แนะนำ `/goal`** ให้ผู้ใช้ — เมื่อ plan ถูก approve แล้วพร้อม implement:
   - `/goal` เปิด goal mode ที่ agent จะทำงานแบบ **thorough ไม่หยุดจนกว่าจะจบ**
   - ส่ง plan ที่ approve แล้วเป็น goal instruction → agent execute ทีละ task ตามลำดับ P0 → P1 → P2
   - เหมาะกับ: งานใหญ่ที่ต้องทำหลาย task ต่อเนื่อง, งาน overnight, งานที่ไม่อยากให้หยุดกลางทาง

2. **ระบุแผนการทดสอบ (Test Plan)** ในเอกสาร:
   - ชิมลางธุรกิจอย่างไร? (pre-order, poll, booth เล็กๆ, beta test)
   - วัดผลอย่างไร? (KPI, metric, user feedback)

3. **Pivot vs Persevere:**
   - เมื่อได้ผลลัพธ์จากการทดสอบ ต้องตัดสินใจ:
   - **Pivot** — เปลี่ยนทิศทาง/รื้อทำใหม่ (ถ้าไม่เวิร์คเลย)
   - **Persevere** — ลุยต่อ/ปรับแก้เล็กน้อย (ถ้ามาถูกทางแล้ว)
   - ย้อนกลับไป Phase 1 (Empathy) หรือ Phase 3 (Ideate) ใหม่ได้ตลอด

> ⚠️ Phase นี้เป็นแค่ "คำแนะนำ" — อย่า execute เองโดยไม่ได้รับอนุมัติ

---

## 📈 Business Milestones ที่ต้องระบุในเอกสาร

### 1. Problem-Solution Fit
> "ไอเดียของเราแก้ปัญหาให้ลูกค้าได้จริง และมีที่ยืนในตลาด"

- จุดนี้คือจุดที่ทำ Design Thinking 5 สเต็ปจนจบแล้วยืนยันว่า solution ตอบโจทย์
- ถ้าเกี่ยวข้อง ให้ระบุในเอกสารว่า task ไหนช่วยพิสูจน์ Problem-Solution Fit

### 2. Product-Market Fit
> "ลูกค้าขาดเราไม่ได้"

- สเต็ปถัดมาเมื่อลงสู่สนามจริง — แบรนด์แข็งแกร่งเมื่อลูกค้า "ไม่ยอมสวิตช์ไปหาคู่แข่ง"
- **วิธีทดสอบ (One Single Question):** "หากแบรนด์ของเราหายไปจากตลาด คุณจะรู้สึกเดือดร้อนมากแค่ไหน?"
- ถ้าเกี่ยวข้อง ให้ระบุในเอกสารว่า task ไหนช่วยพิสูจน์ Product-Market Fit

---

## 📄 โครงสร้างเอกสาร Plan มาตรฐาน

สร้างไฟล์ markdown ใน folder ที่ผู้ใช้กำหนด (หรือสร้าง folder `session-plans-YYYYMMDD/`) ด้วยโครงสร้างนี้:

```markdown
# 📋 [ชื่อโปรเจกต์/ไอเดีย] — Full Analysis & Strategic Plan
> **Session:** [วันที่] | **สถานะ:** Planning only

---

## 📌 บันทึกจากการคุย
- สรุปสิ่งที่ผู้ใช้เล่ามา
- ปัญหา/เป้าหมายที่ต้องการแก้

## 🫂 Empathy — เข้าใจผู้ใช้
- Target Segment: [กลุ่มเป้าหมายที่ชัดเจน]
- Pain Points: [ปัญหาที่เขาเจอ]
- Insight: [ข้อมูลเชิงลึกที่ค้นพบ]
- Constraints: [ข้อจำกัด เวลา/เงิน/คน/tech]

## 🎯 Define — โจทย์ปัญหา
| User | Need | Insight |
|---|---|---|
| [ลูกค้าคือใคร] | [ต้องการอะไร] | [ปัญหาลึกๆ] |

Business Viable: [คุ้มค่าทางธุรกิจอย่างไร]

---

## สถานะปัจจุบัน
- สิ่งที่ทำเสร็จแล้ว (ตาราง)
- สิ่งที่ยังไม่มี
- Tech stack / ข้อจำกัด

---

# ประเด็นที่ N: [ชื่อประเด็น]

## วิเคราะห์สถานการณ์ปัจจุบัน
- ปัญหาหลัก
- จุดแข็งที่มี
- กลุ่มเป้าหมาย (ถ้ามี)

## Tasks — จัดลำดับความสำคัญ (Ideate)

### 🔴 P0 — ต้องทำก่อน
(สำหรับแต่ละ Task)
#### Task [รหัส]: [ชื่อ Task]
> **ลำดับ: #N**
>
> **ปัญหา:** [อธิบายปัญหาที่ task นี้แก้]
>
> **วิธีแก้:** [อธิบายวิธีแก้อย่างละเอียด พร้อมตัวอย่าง]
>
> **MVP:** [ทำอะไรน้อยที่สุดเพื่อทดสอบไอเดียนี้]
>
> **ผลลัพธ์ที่คาดหวัง:** [ผลลัพธ์ที่จะได้เมื่อทำเสร็จ]
>
> **Milestone:** [ช่วยพิสูจน์ Problem-Solution Fit / Product-Market Fit อย่างไร]

### 🟡 P1 — สำคัญ (ทำหลัง P0)
(รูปแบบเดียวกัน)

### 🟢 P2 — Nice to Have
(รูปแบบเดียวกัน)

## สรุปลำดับ Tasks
| ลำดับ | Task | Priority | ผลกระทบ | ความยาก | MVP | หมายเหตุ |
|---|---|---|---|---|---|---|

---

# 🗺️ ภาพรวม: Priority Matrix ทุกประเด็น

## 🔴 P0 — ทำก่อน
| # | Task | ประเด็น | เหตุผลที่ P0 |
|---|---|---|---|

## 🟡 P1 — สำคัญ
(ตาราง)

## 🟢 P2 — Nice to Have
(ตาราง)

---

## 🧪 Test Plan — แผนการทดสอบ
- วิธีชิมลาง: [pre-order / poll / beta test / booth]
- KPI วัดผล: [metric ที่ใช้วัด]
- เกณฑ์ Pivot vs Persevere: [เมื่อไรจะเปลี่ยนทิศ / เมื่อไรจะลุยต่อ]

## 📈 Business Milestones
- Problem-Solution Fit: [task ไหนพิสูจน์]
- Product-Market Fit: [task ไหนพิสูจน์]

---

## 💡 คำแนะนำการเริ่มต้น
- เรียงลำดับ 3-5 สิ่งแรกที่ควรทำ พร้อมเหตุผล
- แนะนำใช้ `/goal` เมื่อพร้อม execute plan ที่ approve แล้ว
```

---

## กฎสำคัญ
1. **ฟังก่อน ถามถ้าไม่ชัด** — อย่าสร้าง plan จากสมมติฐาน
2. **ลงลึกจริงๆ** — ไม่ใช่แค่ list หัวข้อ ต้องมีรายละเอียดที่ implement ได้
3. **ตัวอย่างเป็นรูปธรรม** — แสดง mock output, ข้อความตัวอย่าง, data format
4. **คิดจาก Job to be done** — ลูกค้า "จ้าง" เราไปทำหน้าที่อะไร?
5. **สื่อสารภาษาไทย** — เอกสาร plan เป็นภาษาไทยทั้งหมด
6. **ไม่แก้โค้ดจนกว่าจะได้รับอนุมัติ** — session plan = read-only
7. **แนะนำ `/grill-me` ตอนเริ่ม** — ถ้าหัวข้อยังกว้าง/ไม่ชัด ใช้ interactive interview ก่อน
8. **แนะนำ `/goal` ตอนจบ** — เมื่อ plan ถูก approve ให้แนะนำ `/goal` เพื่อ execute แบบ thorough
9. **ระบุ MVP ทุก task** — ทำอะไรน้อยที่สุดเพื่อทดสอบ core value
10. **ระบุ Business Milestone** — task ไหนช่วยพิสูจน์ Problem-Solution Fit / Product-Market Fit