GitHub Copilot ตอบไม่ตรงงาน? ตั้งค่า 5 จุดก่อนใช้กับ Monorepo

36 min read

GitHub Copilot ทำงานไม่ได้ดั่งใจ? ปัญหาอาจไม่ใช่ที่ AI แต่อยู่ที่การตั้งค่าของคุณ

Custom Instructions, Custom Prompts, Skills, MCP, และ Custom Agents

บทความนี้เป็นส่วนหนึ่งของ AI-assisted Development workflow — การ customize GitHub Copilot อย่างถูกต้องคือการวาง context architecture ให้ AI ทำงานในขอบเขตที่ถูกต้อง ไม่ใช่แค่การเพิ่ม prompt

สารบัญ

  1. ภาพรวมและความสัมพันธ์ระหว่าง 5 components
  2. Custom Instructions
  3. Custom Prompts (/command)
  4. Skills
  5. MCP (Model Context Protocol)
  6. Custom Agents
  7. การใช้งานร่วมกันใน Monorepo
  8. Decision Framework — เลือกใช้อะไรเมื่อไร

1. ภาพรวม

ความสัมพันธ์ระหว่าง 5 components

Custom Instructions  →  บอก Copilot ว่า "โปรเจกต์นี้คืออะไร และมี rule อะไร"
Custom Prompts       →  ให้ User มี shortcut /command สำหรับ task ที่ทำบ่อย
Skills               →  บอก Copilot ว่า "ทำงานนี้อย่างไร (step-by-step)"
MCP                  →  ให้ Copilot มี tools สำเร็จรูปสำหรับ execute กับ external system
Custom Agents        →  บอก Copilot ว่า "ฉันคือใคร มี scope อะไร ใช้ tool อะไร"
Componentคำถามที่ตอบใครตัดสินใจใช้Load เมื่อไร
Custom Instructionsโปรเจกต์นี้คืออะไร / rule คืออะไรอัตโนมัติตรง glob pattern
Custom Promptsฉันต้องการทำ task นี้บ่อยUserUser พิมพ์ /command
Skillsทำสิ่งนี้อย่างไรCopilot หรือ Agentเมื่อ task ตรง
MCPexecute กับ external system อย่างไรCopilot หรือ Agentเมื่อต้องการ tool
Custom Agentsฉันคือ persona ไหนUser หรือ main agentเมื่อ user เลือก หรือ delegate

2. Custom Instructions

Custom Instructions มี 2 แบบ:

แบบที่ 1 — Repository-wide

ไฟล์: .github/copilot-instructions.md

Apply กับทุก interaction ใน repo นั้นตลอดเวลา ใช้สำหรับ context พื้นฐานที่ทุก agent และทุก session ควรรู้

# .github/copilot-instructions.md

This is a monorepo using Turborepo with pnpm workspaces.

## Stack
- Language: TypeScript strict mode throughout
- Package manager: pnpm workspaces
- Shared types: packages/shared (@myapp/shared)

## Project structure
- backend-libs/api-core     → interfaces & abstract classes only
- backend-libs/api-data     → repositories & ORM (Drizzle)
- backend-libs/api-service  → business logic
- backend-libs/api-client   → HTTP clients & external APIs
- backend-app               → entry points & DI container

## Dependency direction (MUST follow)
backend-app → api-service → api-core ← api-data
api-client → api-core

แบบที่ 2 — Path-specific (File-specific)

ไฟล์: .github/instructions/NAME.instructions.md

Apply เฉพาะเมื่อ Copilot ทำงานกับไฟล์ที่ตรงกับ glob pattern ใน applyTo

---
applyTo: "backend-libs/api-service/**"
---

## Responsibility
Business logic layer — implement use cases and domain rules only.

## Scope
- Implement use cases and business rules
- Validate input with zod schemas
- Transform domain objects through mappers
- Define domain-specific error types

## Must NOT contain
- Direct database queries → use repository interfaces from api-core
- HTTP handler logic → belongs in backend-app
- External API calls → belongs in api-client

## Dependencies
- CAN import from: @myapp/api-core
- CANNOT import from: @myapp/api-data, @myapp/api-client directly

## Coding Patterns
- Use Result<T, E> for all return types, never throw
- Constructor injection only, no service locator
- Method naming: verb + noun (getUserById, createOrder)
- All public methods must have JSDoc

## File Structure
src/
├── services/     ← business logic classes
├── validators/   ← zod input schemas
├── mappers/      ← domain object transformations
└── errors/       ← domain-specific error types

## Testing
- Unit tests only, mock all repositories with vitest
- Test location: same folder as source, *.spec.ts
- Required cases: happy path, not found, validation error

2.1 Frontmatter Properties

---
applyTo: "apps/web/**/*.tsx,apps/web/**/*.ts"   ← glob patterns คั่นด้วย comma
excludeAgent: "code-review"                      ← ยกเว้น agent นี้
---
Propertyความหมายค่าที่ใช้ได้
applyToไฟล์ที่ instruction นี้ applyglob pattern, comma-separated
excludeAgentagent ที่ไม่ให้โหลด instruction นี้"code-review", "code-agent"

2.2 Glob Pattern Examples

apps/web/**/*.tsx          → ทุก .tsx ใน apps/web ทุก subfolder
backend-libs/api-data/**   → ทุกไฟล์ใน api-data
**/*.test.ts               → ทุก test file ทั้ง repo
apps/web/**/*.tsx,apps/web/**/*.ts  → หลาย pattern ในไฟล์เดียว

⚠️ หมายเหตุ: Multiple patterns อาจมี bug ในบางเวอร์ชัน VS Code Extension ให้ตรวจสอบ References section ใน Copilot Chat ว่า instruction ถูก apply จริง

2.3 Content ที่ควรมีใน Instruction แต่ละ Project Type

---
applyTo: "backend-libs/api-data/**"
---

## Responsibility
Data access layer — repositories and DB operations only.

## Scope
- Implement repository interfaces defined in api-core
- Define Drizzle ORM models and schema
- Manage DB migrations

## Must NOT contain
- Business rules or validations
- HTTP responses or error formatting

## Dependencies
- CAN import from: @myapp/api-core
- CANNOT import from: @myapp/api-service

## Coding Patterns
- Use Drizzle ORM, never raw SQL
- Always wrap mutations in transactions
- Every query must handle pagination (limit/offset)
- Return domain types defined in api-core

## File Structure
src/
├── repositories/   ← implements interfaces from api-core
├── models/         ← Drizzle schema definitions
└── migrations/     ← database migrations only

## Testing
- Integration tests only using test database
- Test file: same folder as source, *.spec.ts
- Always test: create, read, update, delete, not-found case

Responsibility vs Role:

  • Responsibility — บอกว่า package นี้คืออะไรในระบบ ทำหน้าที่อะไร → ใส่ใน .instructions.md
  • Role / Persona — บอก Copilot ว่า “เป็น AI Agent แบบไหน” ใช้ภาษา “You are…” → ใส่ใน .agent.md เท่านั้น

2.4 ทำไม Role ไม่ควรอยู่ใน .instructions.md

.instructions.md apply กับ ทุก agent ที่เปิดไฟล์ตรง path — ไม่รู้ว่า agent ที่มาเรียกคือใคร ดังนั้นถ้าใส่ Role ไว้และมี custom agent ที่ ref instruction นั้น จะเกิด persona conflict:

Context ที่ model เห็นพร้อมกัน:
──────────────────────────────────────────────────────
[จาก instruction file]
Role: You are a backend developer working in
      business logic layer. Never touch DB directly.

[จาก agent file body]
You are a senior backend architect coordinating
across all layers. You delegate, never code yourself.
──────────────────────────────────────────────────────
model ต้องเลือกว่าจะเชื่ออันไหน หรืออาจ blend ทั้งสอง
→ พฤติกรรมไม่แน่นอน ไม่มี priority rule ตายตัว

หน้าที่ที่ถูกต้องของแต่ละไฟล์:

สิ่งที่เขียนใส่ที่ไหนเหตุผล
Responsibility — one-liner บอก package คืออะไร.instructions.mdcontext คร่าวๆ ให้ทุก agent รู้
Scope — รายการสิ่งที่ทำได้ (positive).instructions.mdบอก detail ว่า package นี้ handle อะไรบ้าง
Must NOT contain — สิ่งที่ห้ามทำ (negative).instructions.mdenforce boundary ชัดเจน
Role / Persona — You are….agent.md body เท่านั้นspecific กับ agent นั้น ไม่ conflict
Coding Patterns.instructions.mdambient context ตลอดเวลา
Routing / delegation logic.agent.md bodyเฉพาะ agent นั้น

2.5 สิ่งที่ไม่ควรใส่ใน Instruction

ห้ามใส่เหตุผล
Role / Persona (“You are…“)conflict กับ persona ใน agent file — ใส่ใน .agent.md เท่านั้น
Rule ที่ linter/formatter จัดการได้redundant
Rule ที่ใช้ทุก project เหมือนกันย้ายไป global แทน
Routing rules หรือ delegation logicใส่ใน agent แทน
Step-by-step workflowใช้ Skill แทน
Business domain อธิบายละเอียดมากCopilot ไม่ได้ใช้ตรงนี้

2.6 Environment Support

FeatureVS CodeCopilot CLIGitHub.com
copilot-instructions.md (global)✅✅✅
.instructions.md + applyTo✅✅✅ (coding agent & code review เท่านั้น)
.vscode/settings.json instructions✅❌❌

3. Custom Prompts (/command)

3.1 Custom Prompt คืออะไร

Custom Prompt คือ template ที่ user เรียกใช้เองผ่าน /command เหมือน macro ที่กด trigger แล้ว Copilot รันตาม prompt นั้น ต่างจาก skill ที่ Copilot เลือกใช้เอง

Skill          →  Copilot ตัดสินใจเรียกใช้เอง
Custom Prompt  →  User เป็นคนเรียกใช้เอง

3.2 โครงสร้างไฟล์

.github/prompts/
└── create-service.prompt.md
# .github/prompts/create-service.prompt.md
---
name: create-service
description: Scaffold a new service class in api-service
---

Create a new service class named #input:serviceName in this monorepo.

Follow the patterns in:
#file:.github/instructions/api-service.instructions.md

Steps to complete:
1. Define I{serviceName}Service interface in api-core
2. Implement {serviceName}Service in api-service
3. Write unit tests covering happy path and error cases
4. Register in DI container
5. Export from index.ts

User พิมพ์ /create-service → Copilot ถาม serviceName → รัน steps

3.3 เมื่อไรควรใช้ Custom Prompt

ใช้ Custom Prompt เมื่อไม่ควรใช้เมื่อ
User ต้องการ control เองว่าจะรันเมื่อไรอยากให้ Copilot เลือกเองอัตโนมัติ → ใช้ Skill แทน
ต้องการ shortcut สำหรับ task ที่ทำซ้ำบ่อยTask ทำแค่ครั้งเดียว ไม่คุ้มสร้าง command
ทีมต้องการ shared template ที่ทุกคนใช้ได้เป็น rule ที่ต้องบังคับเสมอ → ใช้ Instruction แทน

Custom Prompt ไม่จำเป็นต้องมี input variable ก็ได้ — task แบบ “review ไฟล์นี้” หรือ “เขียน test ให้ไฟล์นี้” ไม่มี variable แต่ก็เหมาะกับ Custom Prompt มากเพราะ user ต้องการ trigger เอง

3.4 การใช้งาน Input Variable หลายตัว

ถ้า prompt มี variable หลายตัว Copilot จะถามทีละตัวตามลำดับที่ปรากฏใน prompt หรือ user ใส่ค่าไปพร้อมกันตอน invoke ได้เลย

# .github/prompts/create-service.prompt.md
---
name: create-service
description: Scaffold a new service with interface and tests
---

Create a new service named {serviceName} in module {moduleName}.
Steps to complete:
1. Define I{serviceName}Service interface in api-core
2. Implement {serviceName}Service in api-service/{moduleName}/
3. Write unit tests covering happy path and error cases
4. Register in DI container
5. Export from index.ts
# วิธีที่ 1 — พิมพ์ command แล้วให้ Copilot ถามทีละตัว
/create-service
→ Copilot: "What is serviceName?"   → ตอบ: Payment
→ Copilot: "What is moduleName?"    → ตอบ: billing

# วิธีที่ 2 — ใส่ค่าไปพร้อมกันเลยใน command
/create-service serviceName=Payment moduleName=billing

3.5 ตัวอย่าง Use Case ที่เหมาะกับ Custom Prompt

# .github/prompts/code-review.prompt.md
---
name: code-review
description: Review current file against team standards
---

Review #file:#activefile against our coding standards:
1. Check Result<T,E> pattern is used, no throws
2. Verify constructor injection only
3. Confirm all public methods have JSDoc
4. Check no forbidden imports
5. Suggest improvements with examples
# .github/prompts/write-tests.prompt.md
---
name: write-tests
description: Generate unit tests for current file
---

Write unit tests for #file:#activefile following:
- Vitest + arrange/act/assert pattern
- Mock all external dependencies
- Cover: happy path, not found, validation error cases
- File location: same folder as source, *.spec.ts

4. Skills

4.1 Skill คืออะไร

Skill คือ step-by-step workflow ที่ Copilot ใช้ทำงาน เฉพาะ task โดย load เฉพาะเมื่อจำเป็น ต่างจาก instruction ที่เป็น ambient context อยู่ตลอด

Instruction  →  Copilot ต้องรู้สิ่งนี้ตลอดเวลาขณะเขียน code
Skill        →  Copilot ต้องทำตามขั้นตอนนี้เมื่อทำ task บางอย่าง

4.2 โครงสร้างไฟล์

.github/skills/
└── create-api-service/
    └── SKILL.md
# .github/skills/create-api-service/SKILL.md

---
name: create-api-service
description: Scaffold a new service class in api-service project
---

## Steps to create a new service

1. **Define interface in api-core**
   - Create `I{Name}Service.ts` in `backend-libs/api-core/src/interfaces/`
   - Define all public methods with JSDoc

2. **Implement in api-service**
   - Create `{Name}Service.ts` in `backend-libs/api-service/src/services/`
   - Implement the interface from api-core
   - Use Result<T, E> pattern for all methods

3. **Create unit test**
   - Create `{Name}Service.spec.ts` in same folder
   - Mock all repository interfaces
   - Test: happy path, not found, validation error

4. **Register in DI container**
   - Add to `backend-libs/api-service/src/container.ts`

5. **Export**
   - Add export to `backend-libs/api-service/src/index.ts`

4.3 เมื่อไรควรใช้ Skill แทน Instruction

ใช้ Instruction เมื่อใช้ Skill เมื่อ
Copilot ต้องรู้ตลอดเวลาขณะเขียน codeมี step-by-step ที่ทำเฉพาะตอน task บางอย่าง
เป็น rule ที่ถ้าไม่มีจะเขียน code ผิด patternเป็น workflow สำหรับสร้างหรือ scaffold ของใหม่
Folder structure เพื่อบอก Copilot ว่า project มีโครงสร้างอะไรบ้าง (reference map สำหรับเขียน code ทุกบรรทัด)Folder structure เพื่อบอก Copilot ว่าเมื่อจะสร้างไฟล์ใหม่ต้องวางที่ไหน ชื่ออะไร ตาม step ไหน (ใช้เฉพาะตอน scaffold)

4.4 Instruction → Skill Pattern (Deterministic)

โดยปกติ Copilot ตัดสินใจเองว่าจะใช้ skill หรือเปล่า ซึ่งไม่แน่นอน 100%

แต่เราสามารถ ระบุใน instruction ให้ agent ใช้ skill ที่กำหนดเสมอ เมื่อเจอ condition นั้น:

# api-service-agent.agent.md
---
name: api-service-agent
tools: ['editFiles', 'search', 'read']
---

## When to use skills

When user asks to CREATE a new service class:
→ MUST use skill: create-api-service
→ Do NOT improvise the steps yourself

When user asks to CREATE a new repository class:
→ MUST use skill: create-api-repository

วิธีนี้เปลี่ยน skill จาก “Copilot อาจเลือกใช้” เป็น “Copilot ต้องใช้เสมอเมื่อเจอ condition นี้”

4.5 เปรียบเทียบ 3 วิธีสำหรับ step-by-step workflow

Skill (ปกติ)Instruction → Skill/command
ใครตัดสินใจCopilot เอง (probabilistic)Copilot ตาม rule (deterministic)User
TriggerCopilot เห็นว่า task ตรงCondition ใน instruction matchUser พิมพ์ /
User ต้องรู้ว่ามีอยู่ไม่ต้องไม่ต้องต้องรู้
ความแน่นอนไม่แน่นอน 100%แน่นอนกว่าแน่นอน 100%
รับ input จาก userไม่ได้โดยตรงไม่ได้โดยตรงได้ผ่าน template

Use case ที่ต่างกันชัดเจน:

Skill ปกติ
→ workflow ชัดเจนในตัวเอง Copilot รู้เองได้
→ ความเสี่ยง: Copilot อาจไม่เลือกใช้ถ้า task เขียนมาคลุมเครือ

Instruction → Skill (deterministic)
→ enforce team convention อย่างเข้มงวด
→ ห้าม agent สร้างนอก pattern ที่กำหนดเด็ดขาด

/command
→ user ต้องการ control เอง หรือ task ต้องการ input ก่อนรัน
→ flexible, รับ input ได้, user รู้ว่ากำลังทำอะไร

แนะนำสำหรับ monorepo ที่ต้องการ consistency สูง: ใช้ Instruction → Skill เพราะทีมไม่ต้องจำ command และ agent จะไม่ improvise นอก pattern ที่กำหนด

5. MCP (Model Context Protocol)

5.1 MCP คืออะไร

MCP (Model Context Protocol) คือ open standard ที่กำหนดวิธีเชื่อมต่อ AI agent กับ external tools และ data sources โดย MCP Server expose tools สำเร็จรูปให้ Copilot เรียกใช้ได้เลย โดยไม่ต้องเขียน API call เอง

MCP Server expose 3 primitives:

  • Tools — actions ที่ Copilot เรียกได้โดยตรง เช่น create_pull_request, query_database
  • Resources — data ที่ดึงมา load ใน context
  • Prompts — reusable templates ที่ server กำหนดไว้ให้ host application เรียกใช้

Copilot รองรับ MCP ไม่ครบทั้ง 3 primitives:

MCP PrimitiveCopilot รองรับ?ใช้อะไรแทน
Tools✅ใช้ได้เลย
Resources❌ใช้ #file แนบไฟล์เข้า context แทน
Prompts❌ใช้ Custom Prompts (.github/prompts/) แทน

⚠️ อย่าสับสน: MCP Prompts ≠ Copilot Custom Prompts

MCP Prompts — template ที่ MCP server เขียนมาให้ เพื่อบอก host application ว่าควร prompt แบบไหน ใครใช้คือ host application หรือ LLM ไม่ใช่ user โดยตรง Copilot ไม่รองรับ

Copilot Custom Prompts — template ที่ คุณเขียนเอง ใน .github/prompts/*.prompt.md user เรียกผ่าน /command Copilot รองรับเต็มที่

ในทางปฏิบัติสำหรับ Copilot: ไม่ต้องสนใจ MCP Prompts ใช้ Custom Prompts แทนได้ทุกกรณี

5.2 MCP Resources คืออะไร และต่างจาก Tool อย่างไร

Resource คือ ข้อมูลที่ MCP server expose ให้ LLM อ่านเพื่อรู้บริบทก่อนทำงาน — ต่างจาก Tool ที่เป็น action

Tool      →  LLM ทำ action แล้วได้ผลลัพธ์กลับมา  (verb)
Resource  →  LLM อ่านข้อมูลเข้า context           (noun)

ข้อมูลที่ MCP server มักจะ expose เป็น Resource

Resources ไม่ใช่ instruction — เป็น ข้อมูลจริงจาก external system ใน 4 กลุ่มหลัก:

Live Data:       database schema, config, feature flags
Documents:       ไฟล์ใน repo, wiki, spec, runbook
System State:    infrastructure state, IAM policy, cluster config
Realtime State:  log, metric, tickets ที่ active อยู่ขณะนี้

URI ของ Resource — ไม่มีมาตรฐานตายตัว

แต่ละ MCP server กำหนด URI scheme ของตัวเองเอง ไม่มีกฎว่าต้องขึ้นต้นด้วยอะไร host application รู้ว่ามี resource อะไรโดยการเรียก resources/list ถาม server ก่อน:

// host application ถาม server ว่า "มี resource อะไรบ้าง?"
// GitHub MCP server ตอบ:
{
  "resources": [
    {
      "uri": "github://repos/myorg/payment-service/contents/README.md",
      "name": "README.md",
      "mimeType": "text/markdown"
    }
  ]
}

// Database MCP server ตอบ:
{
  "resources": [
    {
      "uri": "postgres://localhost/mydb/schema",
      "name": "Database Schema",
      "mimeType": "application/json"
    }
  ]
}

Resource มี 2 แบบ:

Static Resource   →  URI ตายตัว เช่น github://repos/myorg/repo/README.md
                     path ไม่เปลี่ยน แต่เนื้อหาอัปเดตได้

Dynamic Resource  →  URI template + parameter
(Resource Template)  เช่น github://repos/{owner}/{repo}/issues/{issue_number}
                     host application ใส่ค่าก่อนดึง

Resource โหลดเมื่อไร — อัตโนมัติทุก session หรือ LLM ตัดสินใจเอง?

ไม่ได้โหลดทุกตัวอัตโนมัติครับ มี 2 แบบขึ้นกับ host application:

Application-controlled:
  host application เลือก load resource เข้า context ก่อนส่ง prompt ให้ LLM
  เหมือน "เตรียม background reading" ให้ LLM ก่อนเริ่ม

Model-controlled (Claude Desktop ใช้แบบนี้):
  LLM อ่าน resource list แล้วเลือกเองว่าต้องการ resource ไหน
  เรียกผ่าน resources/read เมื่อต้องการ
  เหมือน "LLM เปิด document เองเมื่อจำเป็น"

Resource vs Tool ที่อ่านข้อมูลเหมือนกัน — ต่างกันอย่างไร?

สมมติ MCP server มีทั้ง Resource และ Tool สำหรับ schema:

สถานการณ์: user ถาม "เขียน query หา user ที่ยังไม่ verify"

ถ้าใช้ Resource (db://schema):
  LLM load schema ทั้งหมดเข้า context ครั้งเดียว
  เห็นทุก table ทุก column พร้อมกัน
  เขียน query ได้เลย ใช้ได้หลาย query ใน session เดียวกัน

ถ้าใช้ Tool (get_schema):
  LLM: [tool: get_schema, table: "users"]
  ได้ schema เฉพาะ users table กลับมา
  เขียน query ได้เลยเช่นกัน

ผลลัพธ์อาจเหมือนกัน แต่ intent ต่างกัน:

ResourceTool (read)
เหมาะกับbackground context ที่ใช้ทั้ง sessionข้อมูลเฉพาะส่วน เรียกเมื่อต้องการ
Filter ได้❌ ได้ทั้งก้อน✅ ส่ง parameter ได้
ข้อมูลเปลี่ยนบ่อยไม่เหมาะเหมาะ (fresh ทุกครั้งที่เรียก)
side effect❌ ไม่มีเสมออาจมี ขึ้นกับ tool
อุปมาหนังสือที่วางบนโต๊ะ รอให้หยิบอ่านโทรถามผู้เชี่ยวชาญ รอคำตอบ

สำหรับ Copilot: Resources ยังไม่รองรับ ถ้าต้องการให้ Copilot รู้ข้อมูลจาก external system ให้ใช้ MCP Tool แทน เช่น get_schema, fetch_config หรือแนบไฟล์ด้วย #file

5.3 ทำไมถึงต้องมี MCP — ถ้าใช้ Skill + bash ก็ทำได้เหมือนกันไหม?

คำถามนี้สำคัญมาก เพราะถ้ามี bash/curl tools Skill ก็สามารถเรียก REST API ได้จริง แต่ MCP ชนะในกรณีที่ Skill + bash ทำได้ยาก:

1. ไม่ต้องเขียน API calls เอง — MCP เขียนไว้ให้แล้ว

GitHub MCP Server มี 50+ tools สำเร็จรูป เช่น create_pull_request, list_collaborators, add_labels — คุณไม่ต้องรู้ endpoint, body format, หรือ error handling ของแต่ละ API เลย

2. Auth ซับซ้อน — OAuth, Token Rotation, SSO

# Skill + bash: token อยู่ใน command
curl -H "Authorization: Bearer ghp_xxxx..." ...
# ปัญหา: token โผล่ใน bash history, process list, terminal log

# MCP: token อยู่ใน server เท่านั้น Copilot ไม่เห็น token เลย

3. ระบบที่ไม่ใช่ REST — Database, gRPC, WebSocket

# Skill + bash ทำไม่ได้ดี:
psql -c "SELECT * FROM users"   # ต้อง install, config connection
grpc_cli call server:443 ...    # ซับซ้อนมาก

4. Discover resource แบบ dynamic — ไม่รู้ชื่อล่วงหน้า

Skill + bash ต้องรู้ข้อมูลล่วงหน้าก่อนเขียน เช่น ชื่อ repo, ชื่อ branch, label ที่มีอยู่ — ถ้าไม่รู้ก็เขียน Skill ไม่ได้ หรือ hardcode ผิดแล้ว error

MCP ให้ Copilot ถาม server ก่อนว่ามีอะไรอยู่บ้าง แล้วเลือกจากข้อมูลจริง:

user: "สร้าง issue ใน repo ที่เกี่ยวกับ payment"

Skill + bash:
  ❌ ไม่รู้ว่า repo payment ชื่ออะไร
     ต้องให้ user บอกชื่อ repo เต็มๆ ก่อน เช่น "myorg/payment-service"
     ถ้า hardcode ผิด repo → error

MCP:
  ✅ [tool: list_repositories]
     → เห็นว่ามี: payment-service, payment-gateway, payment-sdk
     Copilot เลือก payment-service เพราะชื่อตรงที่สุด
     [tool: create_issue ใน payment-service]
     → สำเร็จ โดยไม่ต้องให้ user บอกชื่อ repo
user: "ติด label ที่เหมาะสมให้ PR นี้"

Skill + bash:
  ❌ Copilot เดา label เอาว่า "bugfix"
     แต่ถ้า repo นี้ไม่มี label "bugfix" → label ไม่ติด หรือ error

MCP:
  ✅ [tool: list_labels]
     → เห็นว่า repo นี้มี: "bug", "enhancement", "needs-review", "blocked"
     Copilot เลือก "bug" ซึ่งมีอยู่จริง ไม่ใช่ "bugfix" ที่ไม่มี
     [tool: add_labels]
     → ติด label สำเร็จ ไม่ error
Skill + bash  →  รู้แค่ที่เขียนไว้ล่วงหน้า  (ข้อมูล static)
MCP           →  ถามก่อน เลือกจากของจริง  (ข้อมูล dynamic)

5.4 เปรียบเทียบ: Skill ทำเอง vs Skill + MCP

Use case: “สร้าง PR พร้อม reviewer และ label”

🟡 Skill ทำเอง (เขียน API calls ทุก step เอง)

# .github/skills/create-pr/SKILL.md
---
description: สร้าง PR พร้อม reviewer และ label
---

## Steps

1. รัน bash เพื่อสร้าง PR:
   curl -X POST https://api.github.com/repos/{owner}/{repo}/pulls \
     -H "Authorization: Bearer $GITHUB_TOKEN" \
     -d '{"title":"{title}","head":"{branch}","base":"main"}'
   → เก็บค่า `number` จาก response ไว้เป็น pr_number

2. รัน bash เพื่อดึงรายชื่อ collaborators:
   curl https://api.github.com/repos/{owner}/{repo}/collaborators \
     -H "Authorization: Bearer $GITHUB_TOKEN"
   → เลือก reviewer ที่เหมาะสมจาก response

3. รัน bash เพื่อ assign reviewer:
   curl -X POST .../pulls/{pr_number}/requested_reviewers \
     -H "Authorization: Bearer $GITHUB_TOKEN" \
     -d '{"reviewers":["{reviewer}"]}'

4. รัน bash เพื่อดึง labels ที่มีอยู่:
   curl https://api.github.com/repos/{owner}/{repo}/labels \
     -H "Authorization: Bearer $GITHUB_TOKEN"

5. รัน bash เพื่อติด label:
   curl -X POST .../issues/{pr_number}/labels \
     -H "Authorization: Bearer $GITHUB_TOKEN" \
     -d '{"labels":["{label}"]}'

คุณต้องเขียน 5 curl commands รู้ endpoint ทุกตัว จัดการ token เอง และถ้า GitHub เปลี่ยน API ต้องมาอัปเดต Skill เอง

🟢 Skill + MCP (เขียนแค่ convention ของทีม)

# .github/skills/create-pr/SKILL.md
---
description: สร้าง PR พร้อม reviewer และ label ตาม convention ของทีม
---

## Convention ของทีม (นี่คือสิ่งที่ Skill บอก)

- PR ทุกอันต้องมี reviewer อย่างน้อย 2 คน
- label ให้เลือกจาก: `feature`, `bugfix`, `hotfix`, `chore` เท่านั้น
- base branch คือ `main` เสมอ
- title format: `[TYPE] description` เช่น `[FEAT] add payment flow`

## Steps

1. ใช้ tool `create_pull_request` สร้าง PR ตาม convention ข้างบน
2. ใช้ tool `list_collaborators` แล้วเลือก reviewer 2 คนที่เหมาะสม
3. ใช้ tool `request_reviewers` assign reviewer ที่เลือก
4. ใช้ tool `add_labels` ติด label ที่ตรงกับประเภทของงาน

คุณเขียนแค่ convention ของทีม — ส่วน API calls ทั้งหมด MCP จัดการให้

ผลลัพธ์เมื่อ Copilot รัน:

Copilot: [เรียก tool: create_pull_request]        ✅ PR #45 สร้างแล้ว
         [เรียก tool: list_collaborators]          ✅ เห็นรายชื่อในทีม
         [เรียก tool: request_reviewers (PR #45)]  ✅ assign 2 คนแล้ว
         [เรียก tool: list_labels]                 ✅ เห็น labels ที่มี
         [เรียก tool: add_labels (PR #45)]         ✅ ติด label แล้ว

"เสร็จแล้วครับ PR #45 พร้อม reviewer 2 คนและ label feature"

สรุปความต่าง

Skill ทำเองSkill + MCP
สิ่งที่เขียนใน Skillcurl commands ทุก stepconvention ของทีม
ต้องรู้ GitHub API✅ ต้องรู้ทุก endpoint❌ ไม่ต้องรู้
GitHub เปลี่ยน API✅ อัปเดต Skill เอง❌ MCP server อัปเดตให้
Token security⚠️ โผล่ใน bash history✅ อยู่ใน MCP server
เขียน + maintainมากน้อย (แค่ convention)

หน้าที่ของ Skill เมื่อใช้ร่วมกับ MCP: บอก “ทำอะไร ตาม rule ของทีมอย่างไร” ส่วน MCP บอก “ทำได้ยังไง” — เหมือนคู่มือทีม (Skill) กับ access card + สิทธิ์เข้าระบบ (MCP)

5.5 โครงสร้างและการตั้งค่า

Config file: .mcp.json ที่ root ของ repo

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "${DATABASE_URL}"]
    }
  }
}

MCP Server ที่ Copilot configure ให้อัตโนมัติ:

  • GitHub MCP Server — access issues, PRs, repo data (read-only by default)
  • Playwright MCP Server — browse web, screenshot, interact with localhost

วิธีเพิ่ม MCP ใน Custom Agent (.github/agents/*.agent.md):

---
name: pr-agent
tools:
  - mcp:github/create_pull_request
  - mcp:github/list_collaborators
  - mcp:github/request_reviewers
  - mcp:github/add_labels
  - read_file
mcpServers:
  - name: github
    command: npx
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_TOKEN: "${GITHUB_TOKEN}"
---

5.6 เมื่อไรควรใช้อะไร

ต้องเขียน API calls หลายตัวเป็นลำดับขั้นตอน
และมี MCP server สำเร็จรูปอยู่แล้ว?
  ↓ YES → ใช้ MCP ประหยัดเวลากว่ามาก

Auth ซับซ้อน (OAuth, token rotation)?
  ↓ YES → ใช้ MCP

ระบบที่ไม่ใช่ REST (Database, gRPC)?
  ↓ YES → ใช้ MCP

REST API ธรรมดา + token ไม่ซับซ้อน + ไม่มี MCP server สำเร็จรูป?
  ↓ → Skill + bash ก็เพียงพอ ไม่ต้องสร้าง MCP เอง
Use Caseแนะนำ
Scaffold file ใหม่ตาม pattern ของ repoSkill เท่านั้น
สร้าง PR / assign reviewer / ติด labelSkill (convention) + MCP (GitHub)
Query live database schemaMCP เท่านั้น
Deploy ตาม convention ทีม + execute จริงSkill (convention) + MCP (Azure/AWS)
Code review ตาม checklist + comment ใน GitHubSkill (checklist) + MCP (GitHub)
เรียก REST API ธรรมดาไม่กี่ขั้น token ง่ายSkill + bash ก็พอ
Fetch config จาก Vault / Secrets ManagerMCP เท่านั้น

5.7 ข้อควรระวัง: Tool Overload

MCP server แต่ละตัวอาจ expose tools จำนวนมาก ถ้าเพิ่มหลาย server โดยไม่ระวัง Copilot จะมี tools ให้เลือกหลายร้อยอย่างในทุก request → response ช้าลง และอาจ confuse เมื่อมี 2 tools ที่ทำงานคล้ายกันจากคนละ server

# ✅ ดี — filter tools เฉพาะที่ agent นั้นต้องใช้
---
name: pr-reviewer
tools:
  - mcp:github/create_review_comment
  - mcp:github/list_pull_requests
  - read_file
---

# ❌ หลีกเลี่ยง — เปิด tools ทั้งหมดของ MCP server
---
name: pr-reviewer
tools:
  - mcp:github  # expose tools ทั้งหมด 50+ อย่าง ทุก request
---

5.8 Environment Support

VS CodeCopilot CLICoding Agent (cloud)
MCP Tools✅✅✅
MCP Resources❌ (ยังไม่รองรับ)❌❌
Remote MCP (OAuth)✅✅❌
Per-agent MCP config✅✅✅

6. Custom Agents

6.1 Custom Agent คืออะไร

Custom Agent คือ specialized version ของ Copilot ที่มี persona, scope, และ tools เป็นของตัวเอง define ครั้งเดียวแทนที่จะต้องให้ context ซ้ำทุก session

6.2 โครงสร้างไฟล์

.github/agents/
└── NAME.agent.md
---
name: backend-orchestrator
description: >
  Use for complex tasks spanning multiple backend projects.
  Trigger: tasks crossing api-core, api-data, api-service, api-client boundaries
tools: ['agent', 'editFiles', 'search', 'read']
agents: ['api-core-agent', 'api-data-agent', 'api-service-agent']
---

You are the backend coordinator for this monorepo.
You NEVER write code yourself. You ALWAYS delegate to subagents.

## Routing Rules
| Task | Delegate to |
|---|---|
| Interface / abstract class | api-core-agent |
| DB / repository / ORM | api-data-agent |
| Business logic / use case | api-service-agent |
| HTTP / external API | api-client-agent |

## Cross-project order
1. interface ใน api-core ก่อน
2. implement ใน project ที่เกี่ยวข้อง
3. wire ใน backend-app สุดท้าย

6.3 Frontmatter Properties

---
name: my-agent                    ← ชื่อ agent (แสดงใน dropdown)
description: >                    ← ใช้ให้ Copilot เลือก agent อัตโนมัติ (สำคัญมาก)
  Use for X tasks...
  Trigger keywords: a, b, c
tools: ['agent', 'editFiles']     ← tools ที่อนุญาต (ต้องมี 'agent' ถึงจะ invoke subagent ได้)
agents: ['sub-agent-1']           ← whitelist: my-agent เรียกได้เฉพาะ sub-agent-1 เท่านั้น
                                    (ถ้าไม่ระบุ agents เลย = เรียกได้ทุก subagent ใน repo)
model: claude-sonnet-4-20250514   ← กำหนด model เฉพาะ (optional)
user-invocable: false             ← ซ่อนจาก dropdown (เป็น subagent เท่านั้น)
handoffs:                         ← sequential workflow ที่ user กด button ส่งต่อเอง
  - label: Implement Plan
    agent: implementer-agent
    prompt: Now implement the plan above.
    send: false
---

agents property — whitelist ของ subagents:

ไม่ระบุ agents:            my-agent เรียก subagent ได้ทุกตัวใน repo  (no restriction)
ระบุ agents: ['x', 'y']   my-agent เรียกได้แค่ x และ y เท่านั้น    (whitelist)

⚠️ ถ้าเขียน routing rule ใน body ให้ delegate ไปยัง agent ที่ไม่อยู่ใน agents whitelist — routing rule นั้นจะ fail ดังนั้นต้องแน่ใจว่า agent ทุกตัวที่ delegate ใน body อยู่ใน whitelist ด้วย หรือไม่ระบุ agents เลยถ้าต้องการ delegate ได้ทุกตัว

agents vs handoffs ต่างกันอย่างไร:

agents (subagents)handoffs
ใครตัดสินใจข้าม agentOrchestrator ตัดสินใจเองตาม routing ruleUser กด button เอง
flowอัตโนมัติ parallel/sequentialsequential ทีละขั้น
เหมาะกับงานที่ต้องการ automate ทั้งหมดงานที่ต้องการ review แต่ละขั้นก่อน
ตัวอย่างorchestrator delegate งานข้าม projectPlan → กด button → Implement → กด button → Review

6.4 เมื่อไรควรสร้าง Custom Agent

สัญญาณตัวอย่าง
ต้องพิมพ์ context เดิมซ้ำทุก session”คุณคือ backend developer ที่ใช้ pattern X”
Task มี scope ชัดเจนและทำบ่อยสร้าง service ใหม่, review API contract
ต้องการจำกัด tools เฉพาะงานนั้นagent นี้ใช้แค่ read-only tools
ต้องการ coordinate งานข้าม projectorchestrator pattern

6.5 Orchestrator Pattern

Orchestrator คือ agent ที่ทำหน้าที่ route และ coordinate เท่านั้น ไม่เขียน code เอง

User → backend-orchestrator → api-service-agent
                            → api-data-agent (parallel)
---
name: backend-orchestrator
description: Main coordinator for all backend tasks
tools: ['agent']              ← มีแค่ agent tool ไม่มี edit
agents: [
  'api-core-agent',
  'api-data-agent',
  'api-service-agent',
  'api-client-agent'
]
---

You are a router. NEVER write code. ALWAYS delegate.

6.6 Subagent และ Context Window

⚠️ สำคัญ: Subagent เริ่มด้วย clean context window ไม่ inherit instructions หรือ conversation history จาก main agent

ดังนั้นแต่ละ agent ต้องรับผิดชอบ context ของตัวเองในไฟล์ .agent.md:

---
name: api-service-agent
---

## Monorepo context
This agent works in backend-libs/api-service only.
Dependency: api-service → api-core only.

## Coding rules
- Use Result<T, E>, never throw
- Constructor injection only
- No direct DB access

## Reference full instruction
@api-service.instructions.md

6.7 Environment Support

FeatureVS CodeCopilot CLIGitHub.com
Custom agents✅✅✅
Subagent delegation✅ (experimental)✅✅
Agent dropdown✅/agent command✅

7. การใช้งานร่วมกันใน Monorepo

7.1 ตัวอย่าง Monorepo Structure

my-monorepo/
├── backend-app/
│   └── src/
├── backend-libs/
│   ├── api-core/
│   ├── api-data/
│   ├── api-service/
│   └── api-client/
└── apps/
    └── web/               ← Next.js frontend

7.2 โครงสร้าง Customization ที่แนะนำ

.github/
├── copilot-instructions.md              ← monorepo-wide context
│
├── instructions/
│   ├── api-core.instructions.md         ← applyTo: backend-libs/api-core/**
│   ├── api-data.instructions.md         ← applyTo: backend-libs/api-data/**
│   ├── api-service.instructions.md      ← applyTo: backend-libs/api-service/**
│   ├── api-client.instructions.md       ← applyTo: backend-libs/api-client/**
│   ├── frontend.instructions.md         ← applyTo: apps/web/**
│   └── testing.instructions.md         ← applyTo: **/*.test.ts,**/*.spec.ts
│
├── agents/
│   └── backend-orchestrator.agent.md   ← สำหรับงาน complex ข้าม project
│
└── skills/
    ├── create-api-service/SKILL.md
    └── create-api-client/SKILL.md

7.3 ตัวอย่างไฟล์ทั้งหมด

copilot-instructions.md (Global)

# Monorepo Overview

## Tech Stack
- Runtime: Node.js, TypeScript strict mode
- Package manager: pnpm workspaces (Turborepo)
- Frontend: Next.js 14 App Router
- ORM: Drizzle
- Testing: Vitest

## Project structure
- backend-libs/api-core     → interfaces & abstract classes
- backend-libs/api-data     → DB repositories (Drizzle)
- backend-libs/api-service  → business logic
- backend-libs/api-client   → HTTP clients
- backend-app               → entry points & DI wiring
- apps/web                  → Next.js frontend

## Dependency direction
backend-app → api-service → api-core ← api-data
api-client → api-core

## Import convention
- Always import shared types from @myapp/api-core
- Never cross-import between api-data and api-service directly

api-service.instructions.md

---
applyTo: "backend-libs/api-service/**"
---

## Responsibility
Business logic layer — implement use cases and domain rules only.

## Scope
- Implement use cases and business rules
- Validate input with zod schemas
- Transform domain objects through mappers
- Define domain-specific error types

## Must NOT contain
- Direct DB queries → use repository interfaces from api-core
- HTTP handler code → belongs in backend-app
- External API calls → belongs in api-client

## Dependencies
- CAN import: @myapp/api-core
- CANNOT import: @myapp/api-data, @myapp/api-client

## Coding Patterns
- Use Result<T, E> for all return types, never throw
- Constructor injection only
- Method naming: verb + noun (getUserById, createOrder)
- All public methods must have JSDoc

## File Structure
src/
├── services/     ← business logic classes
├── validators/   ← zod input schemas
├── mappers/      ← domain object transformations
└── errors/       ← domain-specific error types

## Testing
- Unit tests only, mock all repositories with vitest
- Test location: same folder as source, *.spec.ts
- Required cases: happy path, not found, validation error

api-data.instructions.md

---
applyTo: "backend-libs/api-data/**"
---

## Responsibility
Data access layer — repositories and DB operations only.

## Scope
- Implement repository interfaces defined in api-core
- Define Drizzle ORM models and schema
- Manage DB migrations

## Must NOT contain
- Business rules or domain logic
- HTTP responses or error formatting

## Coding Patterns
- Drizzle ORM only, no raw SQL
- Always wrap write operations in transactions
- Every list query must support pagination (limit/offset)
- Return types must match interfaces defined in api-core

## File Structure
src/
├── repositories/   ← implements IRepository interfaces from api-core
├── models/         ← Drizzle schema definitions
└── migrations/     ← database migrations

## Testing
- Integration tests using test database
- Test: create, read, update, delete, not-found scenarios

testing.instructions.md

---
applyTo: "**/*.test.ts,**/*.spec.ts"
---

## Testing Standards
- Framework: Vitest + React Testing Library (frontend)
- Pattern: Arrange / Act / Assert with comments
- Test behavior, not implementation details
- Use describe blocks to group related cases

## Mocking
- Mock external services with msw
- Mock repositories with vi.mock()
- Never mock the unit under test itself

## Naming
- describe: component or function name
- it/test: "should [expected behavior] when [condition]"

backend-orchestrator.agent.md

---
name: backend-orchestrator
description: >
  Use for complex backend tasks that span multiple projects
  (api-core, api-data, api-service, api-client, backend-app).
  Best for: new features, cross-layer refactoring, adding new domain entities.
  NOT for: simple single-file changes (use instruction auto-load instead).
tools: ['agent', 'search', 'read']
agents: [
  'api-core-subagent',
  'api-data-subagent',
  'api-service-subagent',
  'api-client-subagent'
]
---

You are the backend coordinator. Route tasks, never write code yourself.

## Routing Rules

| Task | Agent |
|---|---|
| Define interface or abstract class | api-core-subagent |
| DB schema, repository, migration | api-data-subagent |
| Business logic, use case, validation | api-service-subagent |
| HTTP client, external API, retry | api-client-subagent |

## Execution Order for cross-project tasks
1. Define interface in api-core first
2. Implement in target project
3. Wire in backend-app last

## Parallel execution
If tasks are independent (e.g., adding to both api-data and api-client),
delegate both simultaneously.

7.4 Workflow จริงในการใช้งานทุกวัน

งานเล็ก (แก้ไฟล์เดียว)
  → เปิดไฟล์ → instruction โหลดอัตโนมัติ → ถาม Copilot ได้เลย

งานปานกลาง (สร้างของใหม่ใน project เดียว)
  → เปิดไฟล์ใน project นั้น → ใช้ skill (/create-api-service)

งานใหญ่ (feature ใหม่ข้าม project)
  → เลือก backend-orchestrator จาก dropdown → บอก task เดียว

8. Decision Framework

8.1 เลือกใช้อะไรเมื่อไร

Copilot ต้องรู้สิ่งนี้ตลอดเวลาขณะเขียน code?
  → YES → Custom Instruction

สิ่งนี้คือขั้นตอนที่ทำเฉพาะตอน task บางอย่าง และ Copilot ควรเลือกเองได้?
  → YES → Skill (ปกติ)

ต้องการให้ agent บังคับใช้ skill เสมอเมื่อเจอ condition นั้น?
  → YES → Instruction → Skill (deterministic)

User ต้องการ shortcut ที่ควบคุมเองได้ หรือ task ต้องการ input ก่อนรัน?
  → YES → Custom Prompt (/command)

ต้องการ persona, จำกัด scope, หรือ coordinate ข้าม project?
  → YES → Custom Agent

8.2 ตารางสรุปเปรียบเทียบทั้งหมด

Custom InstructionSkillInstruction→SkillCustom PromptCustom Agent
เก็บไว้ที่*.instructions.mdskills/*/SKILL.mdinstruction bodyprompts/*.prompt.mdagents/*.agent.md
ใครตัดสินใจอัตโนมัติCopilot (probabilistic)Copilot ตาม ruleUserUser / main agent
ความแน่นอนสูงปานกลางสูงสูงสุดสูง
รับ input❌❌❌✅✅
เขียนอะไรRule, constraintStep-by-stepCondition + skill refTemplate + stepsPersona, scope, routing
ตัวอย่าง”ใช้ Result<T,E>""สร้าง service ทำแบบนี้""ถ้า create → ใช้ skill X”/create-service”ฉันคือ backend coordinator”

8.3 Rule of Thumb สำหรับ Monorepo

สัญญาณควรทำอะไร
Instruction file > 50 บรรทัดแยกเป็น 2 ไฟล์
2 instruction files มี glob ซ้อนกันrefine pattern หรือรวมไฟล์
Convention เปลี่ยน → ต้องแก้หลายไฟล์ย้าย rule นั้นไป global
รวมทุก instruction แล้วยาวกว่า 500 บรรทัดทบทวนว่า rule ไหน linter จัดการได้
ต้องพิมพ์ context เดิมซ้ำทุก sessionสร้าง Custom Agent
งานข้าม project มากกว่า 2 layersสร้าง Orchestrator Agent
Agent improvise นอก pattern ที่กำหนดใช้ Instruction → Skill
ทีมต้องการ shared template ที่ทุกคนใช้ได้สร้าง Custom Prompt

8.4 สิ่งที่ควรเขียนที่ไหน

Contentที่
Monorepo structure, tech stack, dependency directioncopilot-instructions.md
Coding pattern, constraints ของ project*.instructions.md + applyTo
Scaffold steps, file creation workflow (Copilot เลือกเอง)skills/*/SKILL.md
บังคับ agent ใช้ skill เมื่อเจอ conditionbody ของ .agent.md
Shortcut template ที่ user เรียกเองprompts/*.prompt.md
Routing rules, delegation logicbody ของ orchestrator.agent.md
Context ที่ subagent ต้องการbody ของ subagent .agent.md

FAQ

Q: Custom Instructions กับ Custom Agents ต่างกันอย่างไร?

Custom Instructions คือ background context ที่ load อัตโนมัติตาม path — Copilot ไม่ต้องถูกเรียก แค่เปิดไฟล์ตรง glob ก็ apply ทันที ส่วน Custom Agent คือ persona ที่ user เลือกเองหรือ orchestrator delegate ไป มี scope, tools, และ routing rules เป็นของตัวเอง ใช้คนละสถานการณ์กัน — Instruction ให้ ambient context, Agent ให้ specialized behavior

Q: ควรใช้ MCP หรือ Skill เมื่อไหร่?

ใช้ Skill เมื่องานเป็น step-by-step workflow ที่ทำซ้ำบ่อย เช่น scaffold service หรือสร้าง test ตาม pattern — Copilot เลือก Skill เองได้ ใช้ MCP เมื่อต้องการ execute กับ external system เช่น GitHub, database, หรือ Jira โดยไม่ต้องเขียน API call เอง และเมื่อ auth ซับซ้อน หรือต้องการ discover resource แบบ dynamic ที่ไม่รู้ชื่อล่วงหน้า

Q: Custom Agents ทำงานอย่างไรเมื่อใช้ร่วมกับ Subagents?

Orchestrator agent อ่าน routing rules ใน body ของตัวเองแล้วตัดสินใจ delegate ไปยัง subagent ที่เหมาะสม Subagent เริ่มด้วย clean context window ไม่ inherit conversation history จาก main agent — ดังนั้นแต่ละ subagent ต้องมี context ของตัวเองครบใน .agent.md Orchestrator ต้องมี tools: ['agent'] และระบุ agents: [...] whitelist ถ้าต้องการจำกัด subagent ที่เรียกได้

Q: ข้อผิดพลาดที่พบบ่อยในการตั้งค่า GitHub Copilot Customization คืออะไร?

ข้อผิดพลาดที่พบบ่อยที่สุดคือ (1) ใส่ Role / Persona (“You are…”) ใน .instructions.md ทำให้ conflict กับ persona ใน agent file — Role ควรอยู่ใน .agent.md เท่านั้น (2) ไม่ใส่ tools: ['agent'] ใน orchestrator ทำให้ invoke subagent ไม่ได้ (3) เขียน routing rule ใน body ให้ delegate ไป agent ที่ไม่อยู่ใน agents: whitelist

Q: GitHub Copilot Customization เกี่ยวข้องกับ AI-assisted Development อย่างไร?

การ customize Copilot คือการสร้าง context architecture — แทนที่จะพิมพ์ context ซ้ำทุก session คุณ encode conventions, boundaries, และ workflows ลงในไฟล์ที่ Copilot อ่านอัตโนมัติ ผลคือ AI ทำงานภายใน constraint ของทีมได้โดยไม่ต้องควบคุมทุก prompt ซึ่งเป็นแนวคิดเดียวกับ Infrastructure as Code แต่สำหรับ AI behavior

Q: Skill กับ Custom Prompt ต่างกันอย่างไร?

Skill คือ workflow ที่ Copilot เลือกใช้เอง เมื่อ task ตรงกับ description — user ไม่ต้องเรียก ส่วน Custom Prompt คือ template ที่ user เรียกเองผ่าน /command ความแน่นอนต่างกัน Skill มีโอกาส Copilot ไม่เลือกใช้ (probabilistic) แต่ Custom Prompt แน่นอน 100% เพราะ user เป็นคน trigger เอง

Q: โครงสร้างและ pattern ในคู่มือนี้ใช้ได้กับ GitHub Copilot อย่างเดียวหรือเปล่า?

ไม่ครับ — concept ใช้ได้กับ AI coding tools อื่นด้วย แต่ชื่อไฟล์และ syntax ต่างกัน:

ConceptGitHub CopilotCursorClaude CodeWindsurf
Global Instructionscopilot-instructions.md.cursorrules หรือ .cursor/rules/*.mdcCLAUDE.md.windsurfrules
Path-specific Instructions*.instructions.md + applyTo.cursor/rules/*.mdc + globsCLAUDE.md ใน subfolderยังไม่รองรับ
Custom Agents / Persona*.agent.mdCustom Modes (Cursor 1.0+)Sub-agents via SDKยังไม่รองรับ
MCP Integration.mcp.json.cursor/mcp.jsonclaude_desktop_config.jsonรองรับบางส่วน
Skills / Workflow stepsskills/*/SKILL.md.cursor/rules/*.mdc (workflow rules)CLAUDE.md sections.windsurfrules sections

สิ่งที่ portable ข้าม tools ได้เลย:

  • แนวคิด Responsibility + Scope + Must NOT contain ใน instruction file
  • การแยก Role ออกจาก instruction ไปอยู่ใน agent/persona file
  • Orchestrator + Subagent pattern
  • MCP server เดิมใช้ได้ทุก tool ที่รองรับ (MCP เป็น open standard)

สิ่งที่ specific กับ GitHub Copilot:

  • applyTo glob pattern และ excludeAgent ใน frontmatter
  • agents: whitelist และ handoffs: property
  • Custom Prompts ผ่าน /command syntax