GitHub Copilot Chat — ใช้ Ask, Plan, Agent Mode ให้ถูกจุด ไม่เปลือง Token

คู่มือภาษาไทยสำหรับ Developer ที่ใช้ GitHub Copilot Chat ใน VS Code — ครอบคลุมตั้งแต่ Ask Mode, Plan Mode, Agent Mode ไปจนถึง Context Window Management และ Prompt Engineering (2026)

---

สารบัญ

1. ทำความเข้าใจ 3 Modes
2. Ask, Plan, Agent — ใช้ร่วมกันอย่าง Effective
3. Context Window — เข้าใจและจัดการ
4. Solutions เมื่อ Context Window เต็มแต่งานยังไม่เสร็จ
5. Prompt Engineering สำหรับ Agent Mode
6. Context Tools — #file, #codebase, @workspace
7. Custom Instructions — สอน Copilot ให้รู้จัก Project
8. Todo List & Task Tracking
9. Anti-Patterns — สิ่งที่ไม่ควรทำ
10. Workflow ตัวอย่างสำหรับงาน Real-World

---

GitHub Copilot Chat เป็นส่วนหนึ่งของ Vibe Coding workflow — แนวคิดที่ใช้ AI เป็น coding partner แทนที่จะเป็นแค่ autocomplete การเข้าใจว่าควรใช้ mode ไหนในแต่ละสถานการณ์คือหัวใจของการทำงานร่วมกับ AI Coding Assistant อย่างมีประสิทธิภาพ

1. ทำความเข้าใจ 3 Modes

ทำไมต้องแยก Mode ด้วย ใช้ Agent อย่างเดียวไม่ได้เหรอ?

ใช้ Agent อย่างเดียวได้ครับ แต่มีข้อเสียชัดเจน

Agent จะลงมือทำทันทีโดยไม่คิดก่อน ถ้า context ไม่ชัดพอ Agent จะ เดาเอง ซึ่งนำไปสู่:

• แก้ผิดจุด ต้อง revert แล้วทำใหม่
• แก้ถูกจุดแต่ผิด approach ต้อง refactor ทีหลัง
• กระทบไฟล์ที่ไม่ควรกระทบ โดยเฉพาะงาน risk สูง
• เสีย token ไปกับการทำงานที่ต้องทิ้งทั้งหมด

Ask และ Plan ไม่แก้ไฟล์ จึงปลอดภัยและถูก token มาก ใช้ถาม/คิด/วางแผนได้เต็มที่โดยไม่มี side effect ก่อนที่ Agent จะลงมือจริง

Agent อย่างเดียว  → เร็ว แต่ risk สูง ถ้า context ไม่ชัด
Ask → Plan → Agent → ช้ากว่านิดหน่อย แต่ผลลัพธ์แม่นกว่ามาก

แบบไหนดีกว่าขึ้นอยู่กับงาน — ถ้างานเล็ก risk ต่ำ รู้ solution ชัดแล้ว ใช้ Agent เลยก็ได้ แต่ถ้างานซับซ้อนหรือ risk สูง การ Ask/Plan ก่อนประหยัดเวลาและ token ในระยะยาวมากกว่า

Mode	ทำอะไร	ไม่ทำอะไร	ใช้เมื่อ
Ask	ตอบคำถาม, วิเคราะห์ปัญหา, หา solution, เลือก approach	แก้ไขไฟล์	สำรวจ codebase, debug, ตัดสินใจว่าจะทำอะไร
Plan	แตก solution เป็น task steps, ระบุ risk, เตรียม edge cases	แก้ไขไฟล์	รู้ approach แล้ว อยากวางแผนก่อนลงมือ
Agent	แก้ไขไฟล์, รัน terminal, multi-step tasks	—	รู้ทั้ง what และ how แล้ว พร้อมลงมือ

กฎพื้นฐาน: Ask/Plan ไม่แก้ไฟล์ = ปลอดภัย ทบทวนได้เสมอ

---

2. Ask, Plan, Agent — ใช้ร่วมกันอย่าง Effective

Workflow หลัก: Ask → Plan → Agent

Ask   →  หา Solution
         (วิเคราะห์ปัญหา, สำรวจ codebase, เลือก approach)

Plan  →  แตก Solution เป็น Task Steps
         (ลำดับขั้นตอน, ระบุ risk, เตรียม edge cases)

Agent →  ลงมือทำตาม Steps

จุดสำคัญ: Ask คือการ “คิด + ตัดสินใจ” ว่าจะทำอะไร Plan คือการ “วางแผน” ว่าจะทำยังไง ทีละ step Agent คือ “ลงมือ” หลังรู้ทั้ง what และ how แล้วเท่านั้น

Use Case 1: งานใหม่ที่ไม่รู้จัก codebase

[Ask]
"อธิบาย structure ของ portal-core-api ให้หน่อย
 command flow ทำงานยังไง?"

[Ask]
"handler.spec.ts ใน gen-otp ทดสอบอะไรบ้าง
 มี special setup อะไรที่ต้องระวัง?"

[Plan]
"ฉันต้องการ merge test files 15 ไฟล์เป็น 1 ไฟล์
 ช่วย plan steps ให้หน่อย อะไรต้อง handle พิเศษ?"

[Agent]
"ทำตาม plan ที่เราคุยกัน
 merge command handler tests ตาม plan-domain7.md"

✅ ไม่เสียเวลา Agent ทำผิดเพราะยังไม่เข้าใจ context

Use Case 2: งานที่ซับซ้อน มี risk สูง

[Ask]
"ฉันจะ refactor import paths ทั้งหมดใน portal-core-api
 อะไรที่อาจ break ได้บ้าง?"

→ Copilot ตอบกลับ พร้อม risk list

[Ask]
"verify-otp ใช้ fake timers ยังไง
 ถ้าย้าย file แล้วจะกระทบอะไรบ้าง?"

[Plan]
"รู้ risk แล้ว ช่วย breakdown steps การ refactor
 เรียงจาก low risk → high risk"

[Agent]  ← ทำทีละส่วน
"แก้เฉพาะ verify-otp ก่อน แล้วรัน test ดูผล"

✅ วิเคราะห์ risk ให้ครบก่อน (Ask) แล้วค่อย breakdown steps (Plan) ไม่ให้ Agent ทำทุกอย่างรวดเดียว

Use Case 3: Debug ที่ไม่รู้สาเหตุ

[Ask]
"test นี้ fail ด้วย error นี้ [paste error]
 สาเหตุน่าจะมาจากอะไร?"

[Ask]
"มี 3 วิธีแก้ ควรเลือกแบบไหน trade-off คืออะไร?"

[Plan]
"เลือก approach ที่ 2 แล้ว ช่วย breakdown steps
 การแก้ไขและ verify แต่ละจุด"

[Agent]
"แก้ตาม approach ที่ 2 ที่เราเลือก"

✅ ไม่ให้ Agent เดาสาเหตุเองแล้วแก้ผิดจุด ต้อง evaluate options (Ask) ก่อน แล้วค่อย breakdown (Plan)

Use Case 4: Human รู้ขั้นตอนชัด ระบุใน Prompt ได้เลย

[Agent] ← Human รู้ pattern อยู่แล้ว บอกตรงๆ ในคำสั่งเลย
"merge test files ใน portal-core-api โดย:
 - group tests ตาม command name → 1 file ต่อ command
 - ปรับ import paths: '../dto' → '../{command-name}/dto'
 - wrap ทุก test ใน describe('{command-name}', () => { ... })
 - รัน test หลัง merge เพื่อยืนยัน"

✅ ถ้ารู้ pattern ชัดแล้ว ระบุตรงๆ ในคำสั่ง ไม่ต้อง Ask/Plan ทุกครั้ง

Use Case 5: งานเล็ก risk ต่ำ (Ask → Agent)

[Ask]
"function นี้มีปัญหาอะไร? [paste code]"

→ Copilot ชี้จุดที่ผิด พร้อมบอก solution ชัดเจน

[Agent]  ← ข้าม Plan เพราะ step น้อย risk ต่ำ
"แก้ตาม solution ที่วิเคราะห์ได้"

✅ ไม่ต้อง Plan ถ้างานเล็กและ solution ชัดอยู่แล้วหลังจาก Ask

Use Case 6: Human รู้ solution แล้ว แค่ Ask verify ก่อน (Ask → Agent)

[Ask]
"ฉันคิดจะแก้ด้วยการ [approach ที่คิดไว้]
 มีข้อควรระวังอะไรมั้ย?"

→ Copilot confirm หรือเพิ่ม edge case ที่ยังไม่ได้คิด

[Agent]  ← ข้าม Plan เพราะ Human วางแผนเองแล้ว
"ทำตาม approach นี้ [ระบุ details]"

✅ Ask ใช้เพื่อ verify ความคิดตัวเอง ไม่ใช่แค่ให้ Copilot คิดแทน

สรุป Decision Tree

รู้ solution แล้ว?
  └── No  → Ask → Plan → Agent
  └── Yes → มี risk สูง / หลายไฟล์?
               └── No  → Agent ได้เลย (หรือ Ask verify ก่อนถ้าไม่มั่นใจ)
               └── Yes → Plan → Agent

---

3. Context Window — เข้าใจและจัดการ

Context Window คืออะไร

ปริมาณ token ที่ model สามารถ “จำ” ได้ใน session หนึ่งๆ ประกอบด้วย:

• Conversation history (ทุก message ที่ผ่านมา)
• ไฟล์ที่ถูก read/attach
• Tool call results
• System instructions

Icon แสดง Context Usage

สี	ความหมาย	ควรทำ
⬜ ไม่แสดง	Context ว่าง (session ใหม่)	ปกติ
🟢 เขียว	ใช้ไปน้อย	ทำงานต่อได้
🟡 เหลือง	ใกล้เต็ม ~70-80%	เริ่มเตรียม checkpoint
🔴 แดง	ใกล้เต็มมาก	สร้าง checkpoint ทันที

ตั้ง Settings ให้แสดงตลอดเวลา

VS Code — เปิด Settings (Cmd+, / Ctrl+,) หรือเพิ่มใน settings.json:

{
  "chat.tokenBudget.showStatus": "always"
}

ค่า default คือ "whenAtRisk" (แสดงเฉพาะเมื่อใกล้เต็ม)

Copilot CLI — ไม่มี setting ให้ตั้ง CLI จัดการให้อัตโนมัติ:

• พิมพ์ /context เมื่อไหรก็ได้เพื่อดู token usage แบบ real-time
• เมื่อใกล้ถึง 95% CLI จะ auto-compact history ให้เองโดยอัตโนมัติ

Context เพิ่มขึ้นเร็วเมื่อไร

• Agent อ่านไฟล์หลายไฟล์ติดต่อกัน
• Tool calls หลายรอบ (terminal, file search)
• ไฟล์ใหญ่ถูก attach ทั้งไฟล์
• Conversation ยาวมากโดยไม่เริ่ม session ใหม่

Tips ลด Context Consumption

❌ "อ่านทุกไฟล์ใน src/ แล้วสรุปให้หน่อย"
✅ "อ่านเฉพาะ portal-core-api/command/gen-otp/handler.ts"

❌ paste code ทั้งไฟล์ใน chat
✅ ใช้ #file:path/to/file.ts แทน

❌ ถามในขอบเขตกว้างๆ
✅ ถามเจาะจงว่าต้องการอะไร

---

4. Solutions เมื่อ Context Window เต็มแต่งานยังไม่เสร็จ

ปัญหาหลักคือ “Context Loss”

เมื่อเริ่ม New Session — Copilot ไม่จำ อะไรจาก session เก่าเลย ต้องสร้าง shared understanding ใหม่

---

Solution 1: PROGRESS.md — Checkpoint File ⭐ แนะนำที่สุด

สร้างไฟล์ไว้ใน repo เพื่อ handoff context ข้าม session

---

📋 Template PROGRESS.md (ฉบับครบถ้วน)

# PROGRESS — [ชื่องาน]

> Updated: 2026-03-01 14:30

## Task
[อธิบายงานสั้นๆ 1-2 บรรทัด]
Plan file: [path/to/plan.md]

## Done ✅
- Step 1: [ชื่อ] → [output file] (X tests pass)
- Step 2: [ชื่อ] → [output file] (Y tests pass)

## In Progress 🔄
- Step 3: [ชื่อ]
  - [sub-task A] ✅
  - [sub-task B] ✅
  - [sub-task C] ← STOPPED HERE

## TODO ❌
- Step 4: [ชื่อ]
- Step 5: [ชื่อ]

## Last Test Result
[คำสั่ง test ที่ใช้]
→ X passed, 0 failed

## Deleted Original Files
- [path] → merged into [output] ✅

## Critical Context
- [rule หรือ gotcha ที่สำคัญ]
- [special pattern ที่ต้องระวัง]

## Blockers / Issues
- [ปัญหาที่ยังแก้ไม่ได้ ถ้ามี]

---

🚀 Scenario 1 — สร้าง PROGRESS.md ครั้งแรก (ก่อนเริ่มงาน)

สั่ง Agent สร้างไฟล์ก่อนลงมือทำจริง:

ก่อนเริ่มทำงาน สร้าง PROGRESS.md ไว้ที่ [path] โดย:
- สรุป task จาก plan-domain7.md
- list ทุก step พร้อม output file
- ระบุ critical context สำคัญ (jest.mock rules, import path rules)
- ยังไม่ต้องทำงานจริง แค่ setup checkpoint ก่อน

✅ ทำให้ทุก session ต่อไปเริ่มได้จาก PROGRESS.md เสมอ

---

🔁 Scenario 2 — สั่ง Auto-update ใน Initial Prompt (แนะนำ)

ระบุ instruction ตั้งแต่ต้น session ทุกครั้ง:

อ่าน PROGRESS.md และ plan-domain7.md ก่อน
แล้วดำเนินการต่อจากจุดที่ค้างไว้

Rules:
- อ่านไฟล์ source ก่อนสร้างทุกครั้ง
- รัน test หลังแต่ละ step และรายงานผล
- อัพเดท PROGRESS.md ทันทีหลัง step เสร็จ:
    - ย้าย step จาก TODO → Done ✅
    - บันทึก test result
    - บันทึก files ที่ลบแล้ว
- ลบ original files หลัง test pass เท่านั้น

✅ Agent จะอัพเดท PROGRESS.md อัตโนมัติโดยไม่ต้องสั่งซ้ำทุก step

---

⚙️ Scenario 3 — ผ่าน Custom Instructions (ทำครั้งเดียว ใช้ได้ตลอด)

เพิ่มใน .github/copilot-instructions.md:

## PROGRESS.md Protocol
- ถ้า PROGRESS.md มีอยู่แล้ว → อ่านก่อนเริ่มทำงานทุกครั้ง
- อัพเดท PROGRESS.md ทันทีหลัง step เสร็จ (ไม่รอให้ user สั่ง)
- Format: ย้าย step จาก TODO → Done, เพิ่ม test result
- ถ้าไม่มี PROGRESS.md → สร้างก่อนเริ่มงานใหญ่เสมอ

✅ ไม่ต้องพูดถึง PROGRESS.md ใน prompt เลย — Copilot จะทำให้อัตโนมัติ

---

⚠️ Scenario 4 — Task ค้างกลาง Step (ลืมสั่ง update)

เมื่อ session จบกะทันหัน และ PROGRESS.md ยังไม่ได้ update:

session ก่อนทำงานค้างไว้ PROGRESS.md อาจไม่ตรง
ช่วยตรวจสอบสถานะจริงจาก:
- ดูว่าไฟล์เหล่านี้ถูกสร้างแล้วหรือยัง: [list output files]
- รัน test เพื่อตรวจสอบ: pnpm jest --testPathPattern="..."
- แล้วอัพเดท PROGRESS.md ให้ตรงกับความเป็นจริงก่อน proceed

✅ อย่า trust PROGRESS.md 100% ถ้าไม่แน่ใจ — ให้ verify จริงก่อน

---

🔴 Scenario 5 — Test Fail ต้องหยุดกลาง Step

เมื่อ test fail และต้องหยุด record ไว้:

test fail ที่ step นี้ อัพเดท PROGRESS.md:
- ย้าย step ไป In Progress 🔄 (ไม่ใช่ Done)
- บันทึก error message
- บันทึก files ที่สร้างแล้ว (แต่ยังไม่ลบ original)
- อย่าลบ original files จนกว่า test จะผ่าน

แล้ว commit PROGRESS.md ก่อน เพื่อ save สถานะ

Template In Progress สำหรับ test fail:

## In Progress 🔄
- Step 3: get-lang-file.logic.test.ts
  - สร้างไฟล์แล้ว: libs/.../get-lang-file.logic.test.ts ✅
  - Test: ❌ FAIL
  - Error: Cannot find module '../get-lang-file/dto'
  - Original files: ยังไม่ลบ (รอแก้ test ก่อน)
  - TODO: แก้ import path แล้วรัน test ใหม่

---

▶️ Scenario 6 — Resume ใน New Session

Template prompt สำหรับเริ่ม new session จาก PROGRESS.md:

อ่าน PROGRESS.md ที่ [path] ก่อน

จากนั้น:
1. รัน test เพื่อ verify สถานะปัจจุบัน: [คำสั่ง test]
2. ถ้า test ผ่านและตรงกับ PROGRESS.md → ทำต่อจาก "In Progress" หรือ step แรกใน TODO
3. ถ้า test ไม่ตรงกับ PROGRESS.md → อัพเดท PROGRESS.md ให้ตรงก่อน แล้วค่อยทำต่อ

Rules เดิม (อย่า skip):
- อ่านไฟล์ source ก่อนสร้างทุกครั้ง
- อัพเดท PROGRESS.md ทุกครั้งที่ step เสร็จ
- ลบ original files หลัง test pass เท่านั้น

---

📁 Scenario 7 — งานหลาย Domain (หลาย Plan File)

เมื่อมีหลาย domain ทำพร้อมกัน ใช้ PROGRESS.md แยกหรือรวม:

แบบแยก (แนะนำ สำหรับงานใหญ่):

PROGRESS-domain7.md   ← portal-core-api
PROGRESS-domain3.md   ← system-mng-api
PROGRESS-domain5.md   ← user-mng-api

แบบรวม (สำหรับงานเล็ก):

## Domain 7 — portal-core-api
- Step 1: ✅ ... Step 6: ❌

## Domain 3 — system-mng-api
- Step 1: ✅ ... Step 4: ❌

Prompt สำหรับ multi-domain:

อ่าน PROGRESS-domain7.md
ทำเฉพาะ domain 7 ก่อน อย่าแตะ domain อื่น

---

🔄 Lifecycle ของ PROGRESS.md

สร้าง PROGRESS.md
      ↓
[Session N]  อ่าน → ทำงาน → อัพเดท → commit
      ↓
[Session N+1] อ่าน → verify → ทำงานต่อ → อัพเดท → commit
      ↓
งานเสร็จทุก step → ลบ PROGRESS.md (หรือ archive)
                  → git commit final

💡 Commit PROGRESS.md บ่อยๆ — ถ้าเครื่องพัง หรือ VS Code crash จะได้กู้คืนสถานะได้

---

Solution 2: Summary Prompt ก่อน Session จบ

เมื่อ context เหลือ ~20% ให้สั่ง:

ก่อนที่ context จะเต็ม สรุปให้ฉัน:
1. ทำอะไรไปแล้วบ้าง (เสร็จ/ไม่เสร็จ)
2. Step ต่อไปคืออะไร พร้อม detail
3. Critical context ที่ new session ต้องรู้
4. Files ที่แก้ไปแล้ว และ test status
5. ปัญหาที่เจอและวิธีแก้ที่ใช้

Format เป็น markdown ที่ copy ไป new session ได้เลย

→ Copy output → วางเป็น message แรก ใน new session

---

Solution 3: Structured Handoff Prompt

Template สำหรับเริ่ม New Session:

## Handoff Context

**Task**: [อธิบายงาน]
**Plan file**: [path to plan file]

**Already Done**:
- Step 1: [ชื่อ] ✅ (test: X passed)
- Step 2: [ชื่อ] ✅

**Resume From**: Step 3 — [ชื่อ]
- Source files: [list]
- Output: [path]
- Special rules: [สิ่งที่ต้องระวัง]

**Global Rules**:
- [rule 1]
- [rule 2]

อ่านไฟล์ source ก่อน แล้วดำเนินการ Step 3

---

Solution 4: Plan Mode สร้าง Detailed Plan ไว้ก่อน

[Plan mode]
"สร้าง step-by-step execution plan สำหรับ
 Step 3-6 ของ plan-domain7.md แบบ detailed
 ที่ Agent ใน new session อ่านแล้วทำได้เลย
 รวม edge cases และ special rules ทั้งหมด"

→ Save เป็น plan-domain7-detail.md → Agent ใน new session อ่านแล้วทำได้เลย

Open in Editor vs Agent สร้าง PLAN file

หลัง Plan mode generate plan เสร็จ จะมี 2 ปุ่ม:

• Start Implementation → ส่งต่อไป Agent mode ให้ลงมือทำเลย
• Open in Editor → save plan ออกมาเป็นไฟล์ .prompt.md เพื่อเก็บไว้ใช้ทีหลัง หรือ handoff ข้าม session

	Open in Editor	Agent สร้าง PLAN file
คนคิด plan	Copilot	Human
format	.prompt.md	.md ธรรมดา
เหมาะกับ	ให้ Copilot วิเคราะห์และ plan ให้	รู้ plan อยู่แล้ว แค่อยาก save ไว้

---

เปรียบเทียบ Solutions

Solution	เหมาะกับ	ข้อดี	ข้อเสีย
PROGRESS.md	งานยาว หลาย session	Persistent ใน repo	ต้อง maintain
Summary Prompt	รู้ล่วงหน้าว่าจะเต็ม	ไม่ต้องเตรียมล่วงหน้า	ต้อง copy-paste
Handoff Prompt	ทุกกรณี	Flexible	ต้องรู้ว่าหยุดตรงไหน
Plan Mode	งานซับซ้อน	Agent อ่านแล้วทำได้เลย	ใช้เวลาสร้าง

---

5. Prompt Engineering สำหรับ Agent Mode

หลักการเขียน Prompt ที่ดี

❌ "แก้ test files ให้หน่อย"

✅ "อ่าน src/portal-core-api/command/gen-otp/__test__/handler.spec.ts
   แล้ว merge เข้า command/__tests__/command.handler.test.ts
   โดย:
   - ปรับ import paths: from '../dto' → from '../gen-otp/dto'
   - wrap ใน describe('gen-otp', () => { ... })
   - เพิ่ม afterEach(() => { delete process.env.SMS_8X8_SENDER_NAME })
   อ่านไฟล์ destination ก่อนเพื่อ append ต่อท้าย"

Prompt Patterns ที่ใช้บ่อย

Pattern 1: อ่านก่อนสร้างเสมอ

"อ่าน [source files] ก่อน แล้วสร้าง [output file]
 โดยรักษา logic เดิมทุกอย่าง เปลี่ยนแค่ [สิ่งที่ต้องเปลี่ยน]"

Pattern 2: Constraint ชัดเจน

"ห้ามใช้ type any
 ห้ามเปลี่ยน test logic
 ลบ original files หลัง test pass เท่านั้น"

Pattern 3: Verify ก่อน proceed

"หลังสร้างไฟล์แล้ว รัน test แล้วรายงาน pass/fail
 ถ้า fail ให้แก้ก่อน ה้ามไปทำ step ต่อไป"

Pattern 4: Incremental

"ทำทีละ 1 command เท่านั้น
 เริ่มจาก check-account-exist ก่อน
 รอให้ confirm แล้วค่อยทำต่อ"

ระดับ Specificity

Level 1 (ต่ำ):    "merge test files"
Level 2 (กลาง):   "merge handler tests ใน portal-core-api ตาม plan"
Level 3 (สูง):    "อ่าน [file A] + [file B] แล้ว merge เป็น [file C]
                   ตาม structure: describe('X') > describe('Y') > tests
                   ปรับ imports ตาม table นี้: [table]"

✅ งานซับซ้อน → ใช้ Level 3 ✅ งาน pattern ชัดเจน → Level 2 พอ

---

6. Context Tools — #file, #codebase, @workspace

เครื่องมือเพิ่ม Context ให้ Copilot

Tool	ใช้ยังไง	เหมาะกับ
#file:path	#file:src/handler.ts	แนบไฟล์เฉพาะเจาะจง
#codebase	#codebase อธิบาย architecture	ค้นหาทั่ว project
@workspace	@workspace หา test files ทั้งหมด	search ใน workspace
#selection	select code แล้วถาม	อธิบาย/แก้ code ที่เลือก
#terminalLastCommand	ใช้ใน chat	ถาม error จาก terminal ล่าสุด

ตัวอย่างการใช้

"อ่าน #file:plan-domain7.md
 แล้วดำเนินการ Step 3 ตาม plan"

"#codebase มีไฟล์ไหนบ้างที่ใช้ jest.useFakeTimers()"

"terminal ล่าสุดพัง ดู #terminalLastCommand แล้วช่วยแก้"

ข้อควรระวัง

❌ #codebase กับ project ใหญ่มาก → context เพิ่มเร็วมาก
✅ ใช้ #file เจาะจงไฟล์ที่ต้องการจริงๆ

---

7. Custom Instructions — สอน Copilot ให้รู้จัก Project

สร้าง .github/copilot-instructions.md

# Project Instructions for GitHub Copilot

## Stack
- TypeScript (strict mode)
- Jest for testing
- pnpm workspace monorepo

## Coding Rules
- ห้ามใช้ `type any`
- ห้ามใช้ `enum` (ใช้ const object แทน)
- ห้ามใช้ `function` keyword (ใช้ arrow function)
- jest.mock() ต้องอยู่ก่อน import เสมอ

## Testing Rules
- อ่านไฟล์ source ก่อนสร้าง test ทุกครั้ง
- รัน test หลังแก้ไขทุกครั้ง
- ลบ original files หลัง test pass เท่านั้น

## Commit Convention
- format: type(scope): message
- examples: test(portal-core-api): merge command handler tests

## Project Structure
- libs/shared-webapi/shared-api/service/src/ → domain logic
- command/{name}/__test__/ → command tests
- query/{name}/__test__/ → query tests

→ Copilot จะ อ่าน instructions นี้ทุก session อัตโนมัติ ไม่ต้องบอกซ้ำ

---

8. Todo List & Task Tracking

Agent Mode มี Built-in Todo List

เมื่อ Agent ทำงาน multi-step มันจะสร้าง todo list ให้อัตโนมัติ แสดงใน chat sidebar

ใช้ Todo ใน Prompt เพื่อ structured execution

ทำงานตาม checklist นี้ทีละข้อ:
- [ ] อ่าน source files ทั้งหมด
- [ ] สร้าง merged file
- [ ] รัน test verify
- [ ] ลบ original files
- [ ] update PROGRESS.md
- [ ] git commit

อัพเดท checklist ทุกครั้งที่ทำเสร็จแต่ละข้อ

ข้อควรระวัง

❌ สั่งงานหลายอย่างพร้อมกันใน prompt เดียว
   "merge files + แก้ lint + รัน test + commit ให้เลย"

✅ ทำทีละ step แล้ว confirm
   "merge files ก่อน รอดูผล test แล้วค่อย commit"

---

9. Anti-Patterns — สิ่งที่ไม่ควรทำ

❌ 1. ส่ง Agent โดยไม่มี Context

❌ "แก้ test files ทั้งหมดในโปรเจค"
   → Agent ไม่รู้ว่า "ทั้งหมด" คืออะไร จะเดาเอง

✅ ระบุ scope ชัดเจน + link to plan file

❌ 2. ใช้ Session เดียวทำงานทุกอย่าง

❌ ใช้ session เดียวตลอดทั้งวัน
   → context เต็ม → คุณภาพ response ลด

✅ เริ่ม session ใหม่ทุก task ใหม่ หรือทุก 1-2 ชั่วโมง

❌ 3. ไม่ Verify ก่อน Delete

❌ "merge files แล้วลบ originals เลย"
   → ถ้า merge ผิด original หายไปแล้ว

✅ "merge → test pass → ยืนยัน → ลบ"

❌ 4. Trust Agent 100% โดยไม่ Review

❌ "สร้างไฟล์ทั้งหมดแล้ว commit เลย"

✅ review output ก่อน commit ทุกครั้ง
   โดยเฉพาะเมื่อมี import path changes

❌ 5. Prompt กว้างเกินไป

❌ "ช่วย optimize codebase หน่อย"
   → ไม่รู้จะทำอะไร

✅ "ลด jest startup time โดย merge test files
   ตาม pattern ใน PROGRESS.md"

❌ 6. ไม่ใช้ Plan Mode สำหรับงาน Risky

❌ ส่ง Agent แก้ shared utilities โดยตรง
   → อาจ break หลายที่พร้อมกัน

✅ Plan ก่อน → review impact → Agent ทำทีละส่วน

---

10. Workflow ตัวอย่างสำหรับงาน Real-World

Workflow: Merge Test Files (งานใหญ่ หลาย Session)

SESSION 1
─────────
[Ask]  "อธิบาย test structure ของ portal-core-api"
[Plan] "วางแผน merge 32 files → 6 files
        อะไร risk สูง? จัดลำดับ priority"
[Agent] "ทำ Step 1: merge command handlers
         อัพเดท PROGRESS.md หลังเสร็จ"
→ context เต็ม → สรุป checkpoint

SESSION 2
─────────
[Agent] "อ่าน PROGRESS.md แล้วทำต่อ Step 2"
        (ระบุ rules สำคัญใน prompt)

SESSION 3
─────────
[Agent] "อ่าน PROGRESS.md แล้วทำ Step 3-4
         test pass แต่ละ step ก่อน proceed"

Workflow: Bug Fix ที่ไม่รู้สาเหตุ

[Ask]  paste error + #file ที่เกี่ยวข้อง + "สาเหตุน่าจะมาจากอะไร?"
[Ask]  "มีกี่วิธีแก้ แต่ละวิธี trade-off คืออะไร?"
[Plan] "เลือก approach นี้แล้ว ช่วย breakdown steps การแก้ไข"
[Agent] "แก้ตาม approach ที่เราเลือก แล้วรัน test"
[Ask]  "review การแก้ไขว่าถูกต้องมั้ย"

Workflow: Feature ใหม่

[Ask]  "codebase นี้มี pattern อะไรสำหรับ feature แบบนี้?"
[Plan] "ออกแบบ feature X โดย follow existing patterns
        list files ที่ต้องสร้าง/แก้"
[Agent] "สร้าง files ตาม plan ทีละไฟล์
         รัน test หลังแต่ละไฟล์"

---

FAQ — คำถามที่พบบ่อยเกี่ยวกับ GitHub Copilot Chat

Q: Ask, Plan, Agent Mode ต่างจาก Vibe Coding อย่างไร?

Vibe Coding คือแนวคิดการทำงานร่วมกับ AI แบบ iterative — บอก intent แล้วให้ AI ช่วยทำ Ask/Plan/Agent Mode คือ tools ที่ใช้ implement Vibe Coding workflow นั้นในทางปฏิบัติ Ask ใช้หา solution, Plan ใช้ breakdown steps, Agent ใช้ลงมือทำจริง

---

Q: ควรใช้ Agent Mode เมื่อไหร่ และควรหลีกเลี่ยงเมื่อไหร่?

ใช้ Agent Mode เมื่อรู้ทั้ง “จะทำอะไร” และ “จะทำยังไง” แล้ว เหมาะกับงานที่ scope ชัดเจน risk ต่ำ หรือเป็น pattern ที่เคยทำมาแล้ว ควรหลีกเลี่ยงเมื่องานซับซ้อน มีหลายไฟล์ หรือยังไม่แน่ใจ approach เพราะ Agent จะเดาเองและอาจทำผิดทิศทางทั้งหมด

---

Q: Plan Mode ทำงานอย่างไร และต่างจากการสั่ง Agent ให้สร้าง plan file ยังไง?

Plan Mode คือ Copilot วิเคราะห์ codebase และ breakdown steps ให้เอง ผลลัพธ์คือไฟล์ .prompt.md ที่ feed กลับเข้า Agent ได้โดยตรง ส่วนการสั่ง Agent สร้าง plan file คือ Human เป็นคนคิด plan แล้วให้ Agent เขียนตามที่สั่ง เหมาะเมื่อรู้ plan อยู่แล้วแค่อยาก save ไว้ใช้ทีหลัง

---

Q: Context Window เต็มแล้วทำยังไง ไม่ให้งานหาย?

สร้าง PROGRESS.md ไว้ใน repo ก่อนเริ่มงานใหญ่ทุกครั้ง บันทึก Done / In Progress / TODO และ critical context ไว้ เมื่อเริ่ม session ใหม่ให้ Agent อ่าน PROGRESS.md ก่อนเสมอ วิธีนี้ทำให้ทำงานข้าม session ได้โดยไม่สูญเสีย context

---

Q: ข้อผิดพลาดที่พบบ่อยที่สุดเมื่อใช้ GitHub Copilot Chat คืออะไร?

ข้อผิดพลาดหลักคือส่ง Agent ทำงานโดยไม่มี context ที่ชัดเจน เช่น prompt กว้างเกินไป ไม่ระบุ input/output files หรือไม่ระบุ constraints Agent จะเดาเองและทำงานผิดทิศทาง ทางแก้คือใช้ Ask หา solution ก่อน แล้วค่อยส่ง Agent พร้อม prompt ที่ระบุ scope ชัดเจน

---

Mode Selection

ไม่รู้ว่าจะทำอะไร        → Ask
รู้ว่าจะทำ แต่ไม่รู้ยังไง → Plan
รู้ทั้งหมดแล้ว           → Agent

Context Management

Context < 50%  → ทำงานปกติ
Context ~ 70%  → เตรียม checkpoint
Context ~ 80%  → สร้าง PROGRESS.md / summary
Context > 90%  → เริ่ม new session

Prompt Quality Checklist

✅ ระบุ input files ที่ต้องอ่าน
✅ ระบุ output file ที่ต้องสร้าง
✅ ระบุ constraints (ห้ามทำอะไร)
✅ ระบุ verify step (รัน test, lint)
✅ ระบุ scope (อย่าทำเกินนี้)

---

อัพเดทล่าสุด: March 2026 | VS Code + GitHub Copilot Chat Extension