deep-study

name	deep-study
description	ศึกษาอะไรก็ได้ (repo, concept, paper, framework, system) แล้วเขียนตำราเรียนให้เข้าใจจริง ใช้เมื่ออยากเข้าใจอะไรให้ลึก ไม่ใช่แค่หาคำตอบ

Deep Study Skill

"สอนให้เข้าใจ ทำเป็น และเอาไปใช้ต่อได้"

---

ปรัชญา

สกิลนี้มีไว้เปลี่ยน "ความอยากรู้" → "ความเข้าใจที่ใช้ได้จริง"

ไม่ว่าคุณอยากเข้าใจอะไร — GitHub repo, เทคโนโลยี, paper, framework, ระบบ หรือ concept — สกิลนี้จะพาคุณผ่านกระบวนการศึกษา วิเคราะห์ เรียงโครงสร้าง และเขียนเป็นตำรา

---

Input Types (5 แบบ)

Type	ตัวอย่าง	Research Pipeline
GitHub Repo	AutoGPT, LangChain	7 ขั้นอ่านโค้ด (README → config → entry → core → adapters → tests → docs)
Technology/Concept	Attention mechanism, Kafka	4 ขั้นศึกษา (overview → mechanism → ecosystem → practice)
Paper/Article	"Attention is All You Need"	5 ขั้นอ่าน (abstract → method → results → context → critique)
Framework/Library	FastAPI, React, Prisma	5 ขั้น (philosophy → core → API → ecosystem → tradeoff)
System/Idea	ระบบจอง, ERP design	4 ขั้น (requirement → design → decisions → tradeoffs)

---

Operating Rules (กฎ 12 ข้อ)

1. ห้ามเขียนก่อนศึกษา — ผ่าน Research Pipeline ก่อนเขียนบทแรก
2. แยกแหล่งที่มา — [✓] จาก source โดยตรง, [→] อนุมาน, [M] ความรู้ทั่วไป, [W] web
3. ถามก่อนสรุป — ถ้าข้อมูลไม่พอ → ถามผู้ใช้ หรือเขียน [!] ว่ายังไม่ยืนยัน
4. ใช้ภาษาไทย — ยกเว้นชื่อเทคนิค, code, URL
5. สอน อย่าบอก — ทุกบทต้องทำให้คนอ่านเข้าใจและทำตามได้
6. โครงสร้าง ≠ โครงสร้าง input — เรียงตามการเรียนรู้ ไม่ใช่ตามโฟลเดอร์/โครงสร้างเดิม
7. Depth > Coverage — รู้ลึกในสิ่งที่สำคัญ ดีกว่ารู้ผิวในทุกอย่าง
8. หยุดเมื่อพอดี — ดู Pass Levels อย่าเขียนเกินจำเป็น
9. ตรวจตัวเองก่อนส่ง — Self-score ≥ 85 ก่อนส่ง final
10. Transfer สำคัญ — ทุกหัวข้อต้องตอบได้ว่า "เอาไปใช้ยังไง"
11. ใช้ความรู้เดิม + ค้นคว้าเสริมได้ — แต่ claims ต้องมี source
12. ปรับ pipeline ตาม input type — อย่าใช้ 7 ขั้นอ่านโค้ดกับ paper

---

Research Pipelines (เลือกตาม Input Type)

สำหรับ GitHub Repo

Step 1: README → เป้าหมายโปรเจกต์
Step 2: package/config → stack, dependencies
Step 3: entrypoint → จุดเริ่มระบบ
Step 4: core modules → แกนหลัก
Step 5: adapters/integrations → การเชื่อมต่อ
Step 6: tests/examples → intended usage
Step 7: docs/issues/releases → บริบท

สำหรับ Technology/Concept

Step 1: Overview — มันคืออะไร? แก้ปัญหาอะไร?
Step 2: Mechanism — มันทำงานยังไง? (core logic)
Step 3: Ecosystem — มี alternatives อะไร? ต่างกันยังไง?
Step 4: Practice — เอาไปใช้จริงยังไง? เมื่อไหร่ควรใช้?

สำหรับ Paper/Article

Step 1: Abstract + Intro — ปัญหาคืออะไร? เขา claim อะไร?
Step 2: Method — เขาทำยังไง? ทำไมถึงคิดแบบนี้?
Step 3: Results — ได้ผลอะไร? convincing ไหม?
Step 4: Context — เกี่ยวข้องกับอะไรใน field?
Step 5: Critique — มีข้อจำกัดอะไร? ถ้าใช้จริงจะมีปัญหาอะไร?

สำหรับ Framework/Library

Step 1: Philosophy — framework นี้คิดแบบไหน? opinionated แค่ไหน?
Step 2: Core Concepts — main abstractions, lifecycle, hooks
Step 3: API Surface — entry points, configuration
Step 4: Ecosystem — plugins, community, integrations
Step 5: Tradeoffs — ดีกว่าตรงไหน? แย่กว่าตรงไหน? เมื่อไหร่ไม่ควรใช้?

สำหรับ System/Idea

Step 1: Requirements — ระบบนี้ต้องทำอะไร? constraint อะไร?
Step 2: Design Decisions — choices + tradeoffs
Step 3: Architecture — components + relationships
Step 4: Implementation Guide — ขั้นตอนสร้าง

---

Knowledge Density (5 ชั้น — ทุกหัวข้อต้องมี)

ยืม concept จาก opensource-textbook — เพราะใช้ได้กับทุกรูปแบบการศึกษา

ชั้น	ชื่อ	คำถามที่ตอบ
1	Concept	แนวคิดคืออะไร?
2	Mechanism	มันทำงานอย่างไร?
3	Source Evidence	หลักฐานจาก source จริง?
4	Design Reason	ทำไมถึงเลือกแบบนี้?
5	Transfer Skill	เอาไปใช้ยังไง?

Validation

สำหรับแต่ละหัวข้อ H ในบท:
  random 3 ข้อ → ตรวจว่ามีครบ 5 ชั้น
  ถ้าไม่ครบ → เพิ่มชั้นที่ขาด หรือทำเครื่องหมาย [→] ว่ายังไม่มีหลักฐาน

---

Evidence & Citation System

Source Markers

Mark	ระดับ	ความหมาย
[✓]	Direct	ยืนยันจาก source โดยตรง
[→]	Inferred	อนุมานจากหลักฐาน
[M]	Model Knowledge	ความรู้ทั่วไปของ LLM
[W]	Web Evidence	จากการค้นเว็บ
[!]	Unverified	ยังไม่มีหลักฐาน

หลักการใช้

Architecture / code → [✓] จาก repo เท่านั้น
Concept / context → [M] ใช้ความรู้โมเดลได้
ข้อมูลเสริม → [W] ค้นเน็ตได้

Citation Format

ตามชนิดของ input:

Input Type	Citation Format
GitHub Repo	path/to/file.ts#L10-L45
Technology	"ตาม docs [ชื่อ source] + accessed date"
Paper	section X.X + author
Framework	API ref หรือ docs URL
System/Idea	"จากการวิเคราะห์ requirements"

---

Study Plan (ต้องทำก่อนเริ่มเขียน)

study-plan.md
├── input_type              # Repo / Tech / Paper / Framework / System
├── target_reader           # Reader Persona
├── prerequisite_map        # ต้องรู้อะไรก่อน
├── chapter_order           # ลำดับการเรียนรู้
├── concept_dependency      # อะไรต้องรู้ก่อนอะไร
├── repeated_terms          # คำศัพท์ → glossary candidates
├── final_outcome           # อ่านจบแล้วทำอะไรได้
└── output_files            # ไฟล์ที่จะสร้าง

Study Worthiness (คุ้มไหมที่จะทำตำรา)

ก่อนเริ่ม study-plan ให้ประเมิน:

Worthiness /100
- Depth of content: 30 — มี depth ให้ศึกษา
- Learning value: 25 — สอนอะไรที่มีประโยชน์
- Source availability: 20 — หาข้อมูลได้แค่ไหน
- Practical transfer: 15 — เอาไปใช้กับอย่างอื่นได้
- Relevance to you: 10 — ตรงกับสิ่งที่คุณต้องการไหม

≥ 70 → Full Textbook
≥ 50 → Standard Lesson  
≥ 30 → Quick Note
< 30 → Skip

---

Pass Levels

Level	ขนาด	ใช้เมื่อ
Quick Note	1-3 หน้า	concept เล็ก, preview, ทำความเข้าใจเร็ว
Standard Lesson	5-10 หน้า	concept/module เดียว
Full Textbook	15+ หน้า	เรื่องใหญ่, foundation, ต้องรู้ลึก

Output Files ต่อ Pass Level

Quick Note:

□ quick-note.md     ← required

Standard Lesson:

□ study-plan.md     ← required (mini)
□ chapter-*.md      ← 1-5 บท
□ glossary.md        ← recommended

Full Textbook:

□ study-plan.md     ← required
□ chapter-*.md      ← required
□ glossary.md        ← recommended
□ patterns.md        ← recommended (ถ้ามี)
□ cheatsheet.md      ← optional
□ source-map.md      ← recommended
□ index.md           ← required

---

Reader Persona

Persona	ระดับ	น้ำหนัก
Beginner	ไม่มีความรู้มาก่อน	เน้น concept + mechanism
Junior	พอรู้บ้าง ไม่รู้ architecture	เน้น mechanism + design reason
Intermediate	รู้ architecture พื้นฐาน	เน้น design reason + tradeoff
System Designer	ออกแบบระบบเป็น	เน้น transfer + boundary
Practitioner	เอาไปใช้จริง	เน้น practice + code + pitfalls

Rule: 1 บท = 1 Persona

---

Chapter Types

Type	ใช้เมื่อ
🧠 Concept	สอนแนวคิดหลัก
🏗️ Architecture	สอนภาพรวมระบบ
🔬 Deep Dive	พาเจาะลึก mechanism / code
🔨 Implementation	สร้าง mini version / tutorial
⚖️ Comparison	เทียบ design choice / alternatives
❓ Exercise	ทดสอบความเข้าใจ
📖 Case Study	ตัวอย่างจากของจริง

---

Self-Score Rubric (ตรวจตัวเองก่อนส่ง)

คะแนน < 85 → revise ก่อนส่ง final

หมวด	คะแนน	ตรวจอะไร
Accuracy	25	ข้อมูลถูกต้อง [✓], ไม่มี hallucination
Evidence Traceability	20	claims มี source ครบ
Teaching Flow	15	อ่านแล้วเข้าใจ ไม่ใช่ข้อมูลกอง
Knowledge Density	15	5 ชั้นครบทุกหัวข้อหลัก
Practical Transfer	10	เอาไปใช้กับของตัวเองยังไง
Exercise Quality	10	3-5 ข้อ มีเฉลย ระดับต่างกัน
Thai Readability	5	ภาษาไทยธรรมชาติ ไม่ใช่แปลตรงตัว

---

Report Structure (สรุปหลังจบ)

1. What was studied — input type, sources
2. Selected pass level — Quick / Standard / Full + why
3. Study plan — target reader, chapter count
4. Chapters created — list + chapter type + score
5. Evidence summary — source count
6. Unknowns — สิ่งที่ยังไม่รู้ / inspection limitations
7. Transfer — เอาไปใช้ยังไงต่อ
8. Recommended next — เรียนอะไรต่อ