The Complete Guide to Building Skills for Claude

สรุปเนื้อหาสำคัญจากเอกสาร "The Complete Guide to Building Skills for Claude" :

1. Skill คืออะไร?

Skill (ทักษะ) คือชุดคำสั่งที่บรรจุอยู่ในโฟลเดอร์ เพื่อสอนให้ Claude ทำงานหรือทำเวิร์กโฟลว์เฉพาะเจาะจงได้อย่างสม่ำเสมอ ช่วยให้ผู้ใช้ไม่ต้องเสียเวลาอธิบายบริบทหรือความต้องการซ้ำ ๆ ในทุกการสนทนา

โครงสร้างภายในโฟลเดอร์ประกอบด้วย:

• SKILL.md (จำเป็น): ไฟล์คำสั่งในรูปแบบ Markdown พร้อม YAML frontmatter
• scripts/ (ไม่จำเป็น): โค้ดที่สามารถรันได้ เช่น Python หรือ Bash
• references/ (ไม่จำเป็น): เอกสารอ้างอิงที่จะถูกโหลดเมื่อจำเป็น
• assets/ (ไม่จำเป็น): เทมเพลต ฟอนต์ หรือไอคอนสำหรับผลลัพธ์

2. หลักการออกแบบที่สำคัญ

• Progressive Disclosure (การเปิดเผยข้อมูลตามลำดับ): ระบบจะโหลดเฉพาะส่วนที่จำเป็นเพื่อประหยัด Token เริ่มจากหน้าแรก (YAML frontmatter) ในระบบ Prompt จากนั้นจะโหลดตัวเนื้อหาคำสั่ง (SKILL.md) เมื่อพบว่าเกี่ยวข้องกับงาน และสุดท้ายจะเปิดไฟล์อ้างอิงเมื่อจำเป็นเท่านั้น
• Composability (การทำงานร่วมกัน): Claude สามารถโหลดหลาย ๆ Skill ได้พร้อมกัน ทักษะที่สร้างจึงต้องออกแบบมาให้ทำงานร่วมกับ Skill อื่นได้
• Portability (ความยืดหยุ่นในการพกพา): ทำงานได้เหมือนกันหมดไม่ว่าจะใช้ผ่าน Claude.ai, Claude Code หรือ API

3. ความสัมพันธ์ระหว่าง Skills และ MCP

• MCP (Model Context Protocol): เปรียบเสมือนห้องครัวที่มีเครื่องมือ วัตถุดิบ และอุปกรณ์ (เชื่อมต่อกับบริการภายนอก เช่น Notion, Asana, Linear เพื่อดึงข้อมูล Real-time)
• Skills: เปรียบเสมือนสูตรอาหาร (ขั้นตอนและแนวทางปฏิบัติว่าควรใช้เครื่องมือเหล่านั้นอย่างไรให้มีประสิทธิภาพ)

4. ข้อกำหนดทางเทคนิค (Technical Requirements)

• การตั้งชื่อ: ไฟล์คำสั่งหลักต้องชื่อ SKILL.md (Case-sensitive) เท่านั้น และชื่อโฟลเดอร์ต้องใช้รูปแบบ kebab-case (อักษรตัวเล็กทั้งหมด แยกด้วยเครื่องหมายขีด เช่น my-cool-skill) ห้ามใช้ช่องว่างหรือตัวพิมพ์ใหญ่
• ห้ามมีไฟล์ README.md ไว้ในโฟลเดอร์ระดับ Skill (แต่สามารถมีในระดับ Repository บน GitHub ได้)
• YAML Frontmatter: ต้องระบุ name (ชื่อภาษา kebab-case) และ description (ความยาวไม่เกิน 1,024 ตัวอักษร ต้องระบุชัดเจนว่า ทำอะไร และ ใช้เมื่อไหร่/Trigger คำไหน) และห้ามใช้แท็ก XML (< >) โดยเด็ดขาด

5. รูปแบบแนวทางเวิร์กโฟลว์ (Workflow Patterns)

เอกสารแบ่งแนวทางการสร้างเวิร์กโฟลว์ออกเป็น 5 รูปแบบหลัก:

1. Sequential workflow orchestration: การจัดลำดับขั้นตอนการทำงานก่อนหลังอย่างชัดเจน
2. Multi-MCP coordination: การประสานงานข้ามแพลตฟอร์ม (เช่น ส่งข้อมูลจาก Figma ไป Drive แล้วสร้างงานใน Linear และแจ้งเตือนผ่าน Slack)
3. Iterative refinement: กระบวนการที่ผลลัพธ์จะดีขึ้นผ่านการตรวจสอบและแก้ไขซ้ำ ๆ (เช่น การเขียนรายงาน)
4. Context-aware tool selection: การเลือกใช้เครื่องมือให้เหมาะสมตามบริบท (เช่น ขนาดไฟล์ รูปแบบไฟล์)
5. Domain-specific intelligence: การใส่ความรู้เฉพาะทางหรือกฎเกณฑ์การปฏิบัติตามข้อกำหนดเข้าไปในตรรกะคำสั่ง

6. การทดสอบและการเผยแพร่ (Testing & Distribution)

• การทดสอบ: ควรทดสอบ 3 ด้านหลัก ได้แก่ Triggering tests (ตรวจสอบว่าโหลดใช้งานได้ถูกจังหวะและคำสั่งพาราเฟรสไหม), Functional tests (ได้ผลลัพธ์ที่ถูกต้องและจัดการ Error ได้ดี) และ Performance comparison (เปรียบเทียบว่าใช้ Token ลดลง และประหยัดบทสนทนามากขึ้นเมื่อเทียบกับตอนไม่มี Skill)
• การเผยแพร่: ผู้ใช้ทั่วไปสามารถอัปโหลดไฟล์โฟลเดอร์ในรูปแบบ .zip ผ่านทางเมนู Settings > Capabilities > Skills บน Claude.ai หรือใส่ในไดเรกทอรีของ Claude Code สำหรับในระดับองค์กร แอดมินสามารถ Deploy เวิร์กโฟลว์นี้ให้กับทุกคนใน Workspace ได้ รวมถึงสามารถใช้งานในระดับโปรดักชันสเกลใหญ่ผ่าน Skills API ได้เช่นกัน

(หมายเหตุ: แนะนำให้ใช้ตัวช่วย skill-creator skill ที่มีอยู่ในระบบเพื่อช่วยสร้างดราฟต์แรกและตรวจสอบความถูกต้องของ Skill ในเบื้องต้น )

ดาวโหลดเอกสารต้นฉบับ

คู่มือสร้าง Skill สำหรับ Claude ฉบับสมบูรณ์

แปลและสรุปจาก "The Complete Guide to Building Skills for Claude" โดย Anthropic

สารบัญ

1. บทนำ
2. บทที่ 1: พื้นฐาน (Fundamentals)
3. บทที่ 2: การวางแผนและออกแบบ (Planning & Design)
4. บทที่ 3: การทดสอบและปรับปรุง (Testing & Iteration)
5. บทที่ 4: การเผยแพร่และแชร์ (Distribution & Sharing)
6. บทที่ 5: รูปแบบและการแก้ปัญหา (Patterns & Troubleshooting)
7. บทที่ 6: แหล่งอ้างอิง (Resources & References)
8. ภาคผนวก A: Checklist ฉบับย่อ
9. ภาคผนวก B: YAML Frontmatter
10. ภาคผนวก C: ตัวอย่าง Skill สมบูรณ์

บทนำ

Skill คืออะไร?

Skill คือชุดคำสั่ง (instructions) ที่บรรจุอยู่ในโฟลเดอร์ธรรมดา ซึ่งทำหน้าที่สอนให้ Claude รู้วิธีจัดการงานหรือ workflow เฉพาะทาง Skill เป็นหนึ่งในวิธีที่ทรงพลังที่สุดในการ customize Claude ให้เหมาะกับความต้องการเฉพาะของคุณ แทนที่จะต้องอธิบายความต้องการ กระบวนการ และความเชี่ยวชาญในโดเมนใหม่ทุกครั้ง Skill ช่วยให้คุณสอน Claude ครั้งเดียวแล้วได้ประโยชน์ทุกครั้งที่ใช้งาน

Skill เหมาะกับงานแบบไหน?

Skill มีพลังมากเมื่อคุณมี workflow ที่ทำซ้ำๆ เช่น การสร้าง frontend design จาก spec, การทำ research ด้วยวิธีการที่สม่ำเสมอ, การสร้างเอกสารตาม style guide ของทีม หรือการจัดการกระบวนการหลายขั้นตอน Skill ทำงานได้ดีร่วมกับความสามารถในตัวของ Claude เช่น code execution และ document creation สำหรับผู้ที่สร้าง MCP integration, Skill เพิ่มชั้น knowledge ที่ช่วยแปลง raw tool access ให้เป็น workflow ที่เชื่อถือได้และเหมาะสมที่สุด

คู่มือนี้เหมาะสำหรับใคร?

• นักพัฒนาที่ต้องการให้ Claude ทำตาม workflow เฉพาะอย่างสม่ำเสมอ
• ผู้ใช้ขั้นสูงที่ต้องการ customize การทำงานของ Claude
• ทีมที่ต้องการมาตรฐานการใช้ Claude ทั่วทั้งองค์กร

สิ่งที่คุณจะได้เรียนรู้:

• ข้อกำหนดทางเทคนิคและ best practices ด้านโครงสร้าง Skill
• รูปแบบสำหรับ standalone skills และ MCP-enhanced workflows
• วิธีทดสอบ ปรับปรุง และเผยแพร่ Skill
• ตัวอย่างจริงจากการใช้งาน

เส้นทางในคู่มือนี้มี 2 แบบ:

• สร้าง Standalone Skill → เน้นที่บทที่ 1, 2 และ Category 1-2
• เสริม MCP Integration → เน้นที่ส่วน "Skills + MCP" และ Category 3

เมื่อจบคู่มือนี้ คุณจะสามารถสร้าง Skill ที่ใช้งานได้จริงภายในการนั่งทำงานเพียงครั้งเดียว โดยใช้เวลาประมาณ 15-30 นาทีสำหรับ Skill แรก

บทที่ 1: พื้นฐาน

Skill คืออะไร?

Skill คือโฟลเดอร์ที่ประกอบด้วย:

• SKILL.md (บังคับ): คำสั่งในรูปแบบ Markdown พร้อม YAML frontmatter
• scripts/ (ไม่บังคับ): โค้ดที่รันได้ (Python, Bash ฯลฯ)
• references/ (ไม่บังคับ): เอกสารอ้างอิงที่โหลดตามต้องการ
• assets/ (ไม่บังคับ): Templates, fonts, icons ที่ใช้ใน output

หลักการออกแบบหลัก

1. Progressive Disclosure (การเปิดเผยข้อมูลแบบค่อยเป็นค่อยไป)

Skill ใช้ระบบ 3 ชั้น:

• ชั้น 1 (YAML frontmatter): โหลดเข้า system prompt ของ Claude เสมอ ให้ข้อมูลเพียงพอสำหรับให้ Claude รู้ว่าควรใช้ Skill นี้เมื่อไหร่ โดยไม่ต้องโหลดทั้งหมด
• ชั้น 2 (เนื้อหา SKILL.md): โหลดเมื่อ Claude คิดว่า Skill นี้เกี่ยวข้องกับงานปัจจุบัน มีคำสั่งและคำแนะนำครบถ้วน
• ชั้น 3 (ไฟล์ที่ลิงก์ไว้): ไฟล์เพิ่มเติมในโฟลเดอร์ที่ Claude เลือกเข้าถึงเมื่อจำเป็น

การทำแบบนี้ช่วยลดการใช้ token โดยยังคงความเชี่ยวชาญเฉพาะทางไว้

2. Composability (การประกอบร่วมกัน)

Claude สามารถโหลด Skill หลายตัวพร้อมกัน Skill ของคุณควรทำงานร่วมกับตัวอื่นได้ดี ไม่ใช่สมมติว่าตัวเองเป็น skill เดียวที่มี

3. Portability (ความพกพาได้)

Skill ทำงานเหมือนกันทั้งบน Claude.ai, Claude Code และ API สร้าง Skill ครั้งเดียวแล้วใช้ได้ทุกที่ โดยไม่ต้องแก้ไข (ถ้า environment รองรับ dependencies ที่ Skill ต้องการ)

สำหรับผู้สร้าง MCP: Skills + Connectors

💡 หากคุณสร้าง Standalone Skill โดยไม่มี MCP ข้ามส่วนนี้ไปก่อนได้

ถ้าคุณมี MCP server ที่ใช้งานได้แล้ว คุณทำส่วนที่ยากสำเร็จแล้ว Skill คือ knowledge layer ที่วางทับลงไป — จับ workflow และ best practices ที่คุณรู้อยู่แล้ว เพื่อให้ Claude นำไปใช้ได้อย่างสม่ำเสมอ

อุปมาครัวมืออาชีพ:

• MCP = ครัวมืออาชีพ: เข้าถึงเครื่องมือ วัตถุดิบ และอุปกรณ์ได้
• Skill = สูตรอาหาร: คำสั่งทีละขั้นตอนในการสร้างสิ่งที่มีคุณค่า

เปรียบเทียบ MCP กับ Skill:

MCP (Connectivity) Skill (Knowledge) เชื่อม Claude กับ service (Notion, Asana, Linear ฯลฯ) สอน Claude วิธีใช้ service ของคุณอย่างมีประสิทธิภาพ ให้ real-time data access และ tool invocation จับ workflow และ best practices Claude ทำอะไรได้ Claude ควรทำอย่างไร ทำไมเรื่องนี้สำคัญสำหรับผู้ใช้ MCP ของคุณ:

โดยไม่มี Skill:

• ผู้ใช้เชื่อม MCP ได้แต่ไม่รู้จะทำอะไรต่อ
• มี support ticket ถามว่า "ทำ X ด้วย integration นี้ยังไง"
• แต่ละบทสนทนาต้องเริ่มใหม่ตั้งแต่ต้น
• ผลลัพธ์ไม่สม่ำเสมอเพราะผู้ใช้แต่ละคน prompt ต่างกัน

เมื่อมี Skill:

• Workflow ที่สร้างไว้แล้วทำงานอัตโนมัติเมื่อต้องการ
• การใช้ tool ที่สม่ำเสมอและเชื่อถือได้
• Best practices ฝังอยู่ในทุก interaction
• Learning curve สั้นลงสำหรับ integration ของคุณ

บทที่ 2: การวางแผนและออกแบบ

เริ่มจาก Use Cases

ก่อนเขียนโค้ดใดๆ ระบุ Use Case ที่ชัดเจน 2-3 ข้อที่ Skill ของคุณควรทำได้

ตัวอย่าง Use Case ที่ดี:

Use Case: Project Sprint Planning
Trigger: ผู้ใช้พูดว่า "ช่วยวางแผน sprint นี้หน่อย" หรือ "สร้าง sprint tasks"
ขั้นตอน:
1. ดึงสถานะ project ปัจจุบันจาก Linear (ผ่าน MCP)
2. วิเคราะห์ velocity และ capacity ของทีม
3. แนะนำการจัดลำดับ task
4. สร้าง tasks ใน Linear พร้อม labels และ estimates
ผลลัพธ์: Sprint ที่วางแผนครบพร้อม tasks ที่สร้างแล้ว

ถามตัวเองว่า:

• ผู้ใช้ต้องการทำอะไร?
• workflow หลายขั้นตอนนี้ต้องการอะไรบ้าง?
• ต้องการ tools ไหน (built-in หรือ MCP)?
• ควรฝัง domain knowledge หรือ best practices อะไรบ้าง?

ประเภท Use Case ที่พบบ่อย

Anthropic พบ Use Case ที่พบบ่อย 3 ประเภท:

Category 1: Document & Asset Creation

ใช้สำหรับ: สร้าง output ที่สม่ำเสมอและมีคุณภาพสูง ทั้งเอกสาร, presentation, apps, designs, code ฯลฯ

ตัวอย่างจริง: frontend-design skill

"สร้าง frontend interface ระดับ production ที่โดดเด่นและมี design quality สูง ใช้เมื่อสร้าง web components, pages, artifacts, posters หรือ applications"

เทคนิคหลัก:

• ฝัง style guides และ brand standards ไว้
• โครงสร้าง template สำหรับ output ที่สม่ำเสมอ
• Quality checklist ก่อนสรุปผล
• ไม่ต้องการ external tools — ใช้ความสามารถในตัวของ Claude

Category 2: Workflow Automation

ใช้สำหรับ: กระบวนการหลายขั้นตอนที่ได้ประโยชน์จาก methodology ที่สม่ำเสมอ รวมถึงการประสานงานระหว่าง MCP หลายตัว

ตัวอย่างจริง: skill-creator skill

"คู่มือแบบ interactive สำหรับสร้าง Skill ใหม่ พาผู้ใช้ผ่านการนิยาม use case, การสร้าง frontmatter, การเขียนคำสั่ง และการ validate"

เทคนิคหลัก:

• Workflow ทีละขั้นพร้อม validation gates
• Template สำหรับโครงสร้างทั่วไป
• Built-in review และข้อเสนอแนะการปรับปรุง
• Iterative refinement loops

Category 3: MCP Enhancement

ใช้สำหรับ: Workflow guidance เพื่อเสริม tool access ที่ MCP server ให้มา

ตัวอย่างจริง: sentry-code-review skill (จาก Sentry)

"วิเคราะห์และแก้ไข bugs ที่ตรวจพบใน GitHub Pull Requests โดยใช้ข้อมูล error monitoring ของ Sentry ผ่าน MCP server"

เทคนิคหลัก:

• ประสาน MCP calls หลายตัวตามลำดับ
• ฝัง domain expertise
• ให้ context ที่ผู้ใช้ต้องระบุเอง
• Error handling สำหรับปัญหา MCP ที่พบบ่อย

กำหนด Success Criteria

จะรู้ได้อย่างไรว่า Skill ทำงานได้ดี?

เหล่านี้คือเป้าหมายที่ควรมุ่งหา ไม่ใช่ตัวเลขตายตัว

Quantitative Metrics (วัดได้เป็นตัวเลข):

• Skill trigger บน 90% ของ queries ที่เกี่ยวข้อง
• วิธีวัด: รัน test queries 10-20 ข้อที่ควร trigger Skill นับว่าโหลดอัตโนมัติกี่ครั้ง vs. ต้อง invoke เอง
• Complete workflow ใน X tool calls
• วิธีวัด: เปรียบเทียบงานเดียวกันโดยเปิด/ปิด Skill นับ tool calls และ tokens ที่ใช้
• 0 failed API calls ต่อ workflow
• วิธีวัด: ดู MCP server logs ระหว่างการทดสอบ ติดตาม retry rates และ error codes

Qualitative Metrics (ประเมินเชิงคุณภาพ):

• ผู้ใช้ไม่ต้อง prompt Claude เรื่อง next steps
• วิธีประเมิน: ระหว่างทดสอบ สังเกตว่าต้อง redirect หรือ clarify บ่อยแค่ไหน ขอ feedback จาก beta users
• Workflow จบโดยไม่ต้องมีผู้ใช้แก้ไข
• วิธีประเมิน: รัน request เดียวกัน 3-5 ครั้ง เปรียบเทียบ output เรื่องความสม่ำเสมอและคุณภาพ
• ผลลัพธ์สม่ำเสมอข้ามหลาย session
• วิธีประเมิน: ผู้ใช้ใหม่ทำงานสำเร็จในครั้งแรกโดยต้องการคำแนะนำน้อยที่สุดได้ไหม?

ข้อกำหนดทางเทคนิค

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

your-skill-name/
├── SKILL.md            # บังคับ — ไฟล์ Skill หลัก
├── scripts/            # ไม่บังคับ — โค้ดที่รันได้
│   ├── process_data.py
│   └── validate.sh
├── references/         # ไม่บังคับ — เอกสารอ้างอิง
│   ├── api-guide.md
│   └── examples/
└── assets/             # ไม่บังคับ — templates ฯลฯ
    └── report-template.md

กฎสำคัญ:

ชื่อไฟล์ SKILL.md:

• ต้องเป็น SKILL.md เท่านั้น (case-sensitive)
• ไม่รับรูปแบบอื่น เช่น SKILL.MD, skill.md ฯลฯ

ชื่อโฟลเดอร์ Skill:

• ✅ ใช้ kebab-case: notion-project-setup
• ❌ ห้ามเว้นวรรค: Notion Project Setup
• ❌ ห้าม underscore: notion_project_setup
• ❌ ห้ามตัวพิมพ์ใหญ่: NotionProjectSetup

ห้ามมี README.md:

• อย่าใส่ README.md ในโฟลเดอร์ Skill
• เอกสารทั้งหมดอยู่ใน SKILL.md หรือ references/ เท่านั้น
• หมายเหตุ: เมื่อ distribute ผ่าน GitHub ยังต้องมี README ระดับ repo สำหรับผู้อ่านที่เป็นมนุษย์

YAML Frontmatter: ส่วนที่สำคัญที่สุด

YAML frontmatter คือส่วนที่ Claude ใช้ตัดสินใจว่าจะโหลด Skill ของคุณหรือไม่

รูปแบบขั้นต่ำที่ต้องมี:

---
name: your-skill-name
description: ทำอะไร ใช้เมื่อผู้ใช้พูดว่า [วลีเฉพาะ]
---

ข้อกำหนดของแต่ละ field:

name (บังคับ):

• kebab-case เท่านั้น
• ห้ามเว้นวรรคหรือตัวพิมพ์ใหญ่
• ควรตรงกับชื่อโฟลเดอร์

description (บังคับ):

• ต้องมี ทั้งสองอย่าง: สิ่งที่ Skill ทำ + เงื่อนไขการใช้ (trigger conditions)
• ไม่เกิน 1,024 ตัวอักษร
• ห้ามมี XML tags (< หรือ >)
• รวมงานที่ผู้ใช้อาจพูดถึง
• ระบุประเภทไฟล์ที่เกี่ยวข้อง (ถ้ามี)

license (ไม่บังคับ):

• ใช้ถ้าทำ Skill open source (เช่น MIT, Apache-2.0)

compatibility (ไม่บังคับ, 1-500 ตัวอักษร):

• ระบุข้อกำหนดด้าน environment เช่น intended product, required system packages, network access

metadata (ไม่บังคับ):

• key-value pairs ที่กำหนดเอง
• แนะนำ: author, version, mcp-server

ข้อจำกัดด้านความปลอดภัย:

ห้ามใน frontmatter:

• XML angle brackets (< >)
• Skill ที่ชื่อมีคำว่า "claude" หรือ "anthropic" (สงวนไว้)

สาเหตุ: Frontmatter ปรากฏใน system prompt ของ Claude เนื้อหาที่เป็นอันตรายอาจฉีด instructions ได้

การเขียน Skill ที่มีประสิทธิภาพ

โครงสร้างของ description field:

[สิ่งที่ทำ] + [เมื่อใช้] + [ความสามารถหลัก]

ตัวอย่าง description ที่ดี:

# ดี — เฉพาะเจาะจงและ actionable
description: วิเคราะห์ Figma design files และสร้างเอกสาร developer handoff 
ใช้เมื่อผู้ใช้อัปโหลด .fig files หรือขอ "design specs", "component documentation" 
หรือ "design-to-code handoff"

# ดี — มี trigger phrases
description: จัดการ Linear project workflows ครอบคลุม sprint planning, 
task creation และ status tracking ใช้เมื่อผู้ใช้พูดถึง "sprint", "Linear tasks", 
"project planning" หรือขอ "create tickets"

ตัวอย่าง description ที่ไม่ดี:

# แย่ — คลุมเครือเกินไป
description: ช่วยเรื่อง projects

# แย่ — ไม่มี triggers
description: สร้างระบบเอกสารหลายหน้าที่ซับซ้อน

# แย่ — technical เกินไป ไม่มี user triggers
description: Implements the Project entity model with hierarchical relationships

การเขียน Instructions หลัก

หลังจาก frontmatter ให้เขียน instructions จริงใน Markdown

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

---
name: your-skill
description: [...]
---

# ชื่อ Skill ของคุณ

## Instructions

### ขั้นตอนที่ 1: [ขั้นตอนหลักแรก]
อธิบายชัดเจนว่าเกิดอะไรขึ้น

ตัวอย่าง:
```bash
python scripts/fetch_data.py --project-id PROJECT_ID
Expected output: [อธิบายหน้าตาของความสำเร็จ]

ตัวอย่าง

Example 1: [สถานการณ์ทั่วไป] ผู้ใช้พูดว่า: "ตั้งค่า marketing campaign ใหม่" Actions:

1. ดึง campaigns ที่มีอยู่ผ่าน MCP
2. สร้าง campaign ใหม่ด้วย parameters ที่ระบุ Result: Campaign ที่สร้างพร้อม confirmation link

Troubleshooting

Error: [ข้อความ error ที่พบบ่อย] สาเหตุ: [ทำไมถึงเกิด] วิธีแก้: [แก้อย่างไร]

**Best Practices สำหรับ Instructions:**

ความเฉพาะเจาะจงและ Actionable:

✅ ดี: รัน python scripts/validate.py --input {filename} เพื่อตรวจสอบรูปแบบข้อมูล ถ้า validate ไม่ผ่าน ปัญหาที่พบบ่อย ได้แก่:

• Fields ที่บังคับขาดหาย (เพิ่มลงใน CSV)
• รูปแบบวันที่ไม่ถูก (ใช้ YYYY-MM-DD)

❌ แย่: Validate ข้อมูลก่อนดำเนินการต่อ

รวม Error Handling:
- เพิ่มส่วน "Common Issues" พร้อมขั้นตอนการแก้ไขที่ชัดเจน

อ้างอิง bundled resources อย่างชัดเจน:
- ก่อนเขียน queries ให้ดู references/api-patterns.md

ใช้ Progressive Disclosure:
- เก็บ SKILL.md ไว้สำหรับ core instructions
- ย้ายเอกสารละเอียดไปที่ references/ แล้วลิงก์ไว้

---

## บทที่ 3: การทดสอบและปรับปรุง

### ระดับความเข้มข้นในการทดสอบ

สามารถทดสอบได้หลายระดับตามความต้องการ:

- **Manual testing ใน Claude.ai** — รัน queries โดยตรงและสังเกตพฤติกรรม รวดเร็ว ไม่ต้องตั้งค่า
- **Scripted testing ใน Claude Code** — Automate test cases เพื่อ validate ซ้ำๆ ข้ามการเปลี่ยนแปลง
- **Programmatic testing ผ่าน Skills API** — สร้าง evaluation suites ที่รันอย่างเป็นระบบ

เลือก approach ตามความต้องการ Skill ที่ใช้ภายในทีมเล็กมี testing needs ต่างกับที่ deploy ให้ enterprise users หลายพันคน

> **Pro Tip:** ทำซ้ำบน task เดียวก่อนขยาย
> วิธีที่ effective ที่สุดคือทำซ้ำบน task ที่ท้าทายเพียงข้อเดียวจนกว่า Claude จะสำเร็จ แล้วจึง extract วิธีที่ชนะออกมาเป็น Skill

---

### แนวทางการทดสอบที่แนะนำ

**1. Triggering Tests**

เป้าหมาย: ตรวจสอบว่า Skill โหลดในเวลาที่ถูกต้อง

Test cases:
- ✅ Trigger บน tasks ที่ชัดเจน
- ✅ Trigger บน requests ที่พูดต่างวิธี (paraphrased)
- ❌ ไม่ trigger บน topics ที่ไม่เกี่ยวข้อง

ควร trigger:

• "ช่วยตั้งค่า ProjectHub workspace ใหม่หน่อย"
• "ฉันต้องสร้าง project ใน ProjectHub"
• "Initialize ProjectHub project สำหรับ Q4 planning"

ไม่ควร trigger:

• "อากาศ San Francisco เป็นยังไง?"
• "ช่วยเขียน Python code หน่อย"
• "สร้าง spreadsheet" (ถ้า ProjectHub skill ไม่ handle sheets)

**2. Functional Tests**

เป้าหมาย: ตรวจสอบว่า Skill สร้าง outputs ที่ถูกต้อง

Test cases:
- Valid outputs ถูกสร้าง
- API calls สำเร็จ
- Error handling ทำงาน
- Edge cases ครอบคลุม

Test: สร้าง project พร้อม 5 tasks Given: ชื่อ project "Q4 Planning", 5 task descriptions When: Skill รัน workflow Then:

• Project ถูกสร้างใน ProjectHub
• 5 tasks ถูกสร้างพร้อม properties ที่ถูกต้อง
• Tasks ทั้งหมด linked กับ project
• ไม่มี API errors

**3. Performance Comparison**

เป้าหมาย: พิสูจน์ว่า Skill ปรับปรุงผลลัพธ์ vs. baseline

โดยไม่มี Skill: เมื่อมี Skill:

• ผู้ใช้ให้คำสั่งทุกครั้ง - Automatic workflow execution
• ส่งข้อความกลับไปกลับมา 15 ครั้ง - ถามเพิ่มแค่ 2 ครั้ง
• API failed 3 ครั้งต้อง retry - 0 failed API calls
• ใช้ tokens 12,000 - ใช้ tokens 6,000

---

### การใช้ skill-creator

Skill `skill-creator` ช่วยสร้างและปรับปรุง Skills ได้ ถ้าคุณมี MCP server และรู้ workflow 2-3 อย่างหลัก สามารถสร้างและทดสอบ Skill ที่ใช้งานได้ใน 15-30 นาที

ความสามารถ:
- สร้าง Skill จาก natural language descriptions
- สร้าง SKILL.md ที่มีรูปแบบถูกต้องพร้อม frontmatter
- แนะนำ trigger phrases และโครงสร้าง
- ตรวจสอบและแนะนำการปรับปรุง
- แนะนำ test cases

วิธีใช้:

"ช่วยสร้าง Skill สำหรับ [use case ของคุณ] โดยใช้ skill-creator"

---

### Iteration ตาม Feedback

Skill คือ living documents ต้องวางแผน iterate ตามสัญญาณเหล่านี้:

**Undertriggering (Skill ไม่โหลดเมื่อควรโหลด):**
- สัญญาณ: Skill ไม่โหลดอัตโนมัติ, ผู้ใช้ต้อง enable เอง
- แก้ไข: เพิ่มรายละเอียดและ keywords ใน description

**Overtriggering (Skill โหลดบ่อยเกินไป):**
- สัญญาณ: Skill โหลดสำหรับ queries ที่ไม่เกี่ยวข้อง, ผู้ใช้ปิดมัน
- แก้ไข: เพิ่ม negative triggers, ระบุให้ specific มากขึ้น

**Execution issues (ปัญหาในการรัน):**
- สัญญาณ: ผลลัพธ์ไม่สม่ำเสมอ, API call ล้มเหลว, ผู้ใช้ต้องแก้ไข
- แก้ไข: ปรับปรุง instructions, เพิ่ม error handling

---

## บทที่ 4: การเผยแพร่และแชร์

### รูปแบบการ distribute ปัจจุบัน

**ผู้ใช้รายบุคคลติดตั้ง Skill อย่างไร:**
1. ดาวน์โหลดโฟลเดอร์ Skill
2. Zip โฟลเดอร์ (ถ้าจำเป็น)
3. อัปโหลดไปที่ Claude.ai ผ่าน Settings > Capabilities > Skills
4. หรือวางไว้ใน Claude Code skills directory

**Organization-level Skills:**
- Admin deploy Skills ทั่ว workspace ได้
- อัปเดตอัตโนมัติ
- จัดการจากส่วนกลาง

---

### Open Standard

Anthropic ได้เผยแพร่ Agent Skills เป็น open standard เหมือนกับ MCP เราเชื่อว่า Skills ควรพกพาได้ข้าม tools และ platforms — Skill เดียวกันควรทำงานได้ทั้งบน Claude และ AI platforms อื่นๆ

---

### การใช้ Skills ผ่าน API

สำหรับ use cases เชิง programmatic เช่น การสร้าง applications, agents หรือ automated workflows:

**ความสามารถหลัก:**
- endpoint `/v1/skills` สำหรับจัดการ Skills
- เพิ่ม Skills ใน Messages API requests ผ่าน parameter `container.skills`
- Version control ผ่าน Claude Console
- ทำงานร่วมกับ Claude Agent SDK

**เมื่อไหรควรใช้ Skills ผ่าน API vs. Claude.ai:**

| Use Case | แนะนำใช้ |
|---|---|
| ผู้ใช้ interact กับ Skills โดยตรง | Claude.ai / Claude Code |
| Testing และ iteration ระหว่าง develop | Claude.ai / Claude Code |
| Workflows แบบ ad-hoc ส่วนบุคคล | Claude.ai / Claude Code |
| Applications ที่ใช้ Skills แบบ programmatic | API |
| Production deployments ขนาดใหญ่ | API |
| Automated pipelines และ agent systems | API |

---

### วิธีที่แนะนำในปัจจุบัน

เริ่มจาก host Skill บน GitHub แล้วเพิ่ม section ใน MCP documentation

**1. Host บน GitHub:**
- Public repo สำหรับ open-source skills
- README ชัดเจนพร้อม installation instructions
- ตัวอย่างการใช้งานพร้อม screenshots

**2. เพิ่มเอกสารใน MCP Repo:**
- ลิงก์ไปที่ Skills จาก MCP documentation
- อธิบายคุณค่าของการใช้ทั้งสองอย่างร่วมกัน
- คู่มือ quick-start

**3. Installation Guide ตัวอย่าง:**

```markdown
## ติดตั้ง [Your Service] Skill

1. ดาวน์โหลด Skill:
   - Clone repo: git clone https://github.com/yourcompany/skills
   - หรือดาวน์โหลด ZIP จาก Releases

2. ติดตั้งใน Claude:
   - เปิด Claude.ai > Settings > Skills
   - คลิก "Upload skill"
   - เลือกโฟลเดอร์ Skill (zip)

3. เปิดใช้งาน Skill:
   - Toggle on [Your Service] Skill
   - ตรวจสอบว่า MCP server เชื่อมต่ออยู่

4. ทดสอบ:
   - ถาม Claude: "ตั้งค่า project ใหม่ใน [Your Service]"

การ positioning Skill ของคุณ

เน้น outcomes ไม่ใช่ features:

✅ ดี:
"ProjectHub skill ช่วยให้ทีมตั้งค่า project workspace สมบูรณ์ได้ในไม่กี่วินาที 
— รวมถึง pages, databases และ templates — แทนที่จะเสีย 30 นาทีในการตั้งค่าเอง"

❌ แย่:
"ProjectHub skill คือโฟลเดอร์ที่มี YAML frontmatter และ Markdown instructions 
ที่เรียก MCP server tools"

เน้นเรื่อง MCP + Skills story:

"MCP server ของเราให้ Claude เข้าถึง Linear projects ของคุณ
Skills ของเราสอน Claude เรื่อง sprint planning workflow ของทีม
ร่วมกัน พวกมัน enable AI-powered project management"

บทที่ 5: รูปแบบและการแก้ปัญหา

เลือก Approach: Problem-first vs. Tool-first

เหมือนกับ Home Depot คุณอาจเข้าไปด้วยปัญหา ("ต้องซ่อมตู้ครัว") แล้วพนักงานชี้ไปที่เครื่องมือที่เหมาะสม หรือคุณอาจเลือก drill ใหม่แล้วถามว่าจะใช้กับงานเฉพาะของคุณยังไง

Skills ก็ทำงานแบบเดียวกัน:

• Problem-first: "ต้องการตั้งค่า project workspace" → Skill จัดการ MCP calls ที่ถูกต้องในลำดับที่ถูกต้อง ผู้ใช้อธิบาย outcomes; Skill จัดการ tools
• Tool-first: "มี Notion MCP เชื่อมต่อแล้ว" → Skill สอน Claude workflows และ best practices ที่เหมาะสม ผู้ใช้มี access; Skill ให้ expertise

Skills ส่วนใหญ่โน้มเอียงไปทางใดทางหนึ่ง รู้ว่า use case ของคุณเหมาะกับ framing ไหน ช่วยเลือก pattern ที่ถูกต้อง

Pattern 1: Sequential Workflow Orchestration

ใช้เมื่อ: ผู้ใช้ต้องการกระบวนการหลายขั้นตอนในลำดับเฉพาะ

## Workflow: Onboard New Customer

### ขั้นตอนที่ 1: Create Account
เรียก MCP tool: create_customer
Parameters: name, email, company

### ขั้นตอนที่ 2: Setup Payment
เรียก MCP tool: setup_payment_method
รอ: payment method verification

### ขั้นตอนที่ 3: Create Subscription
เรียก MCP tool: create_subscription
Parameters: plan_id, customer_id (จาก Step 1)

### ขั้นตอนที่ 4: Send Welcome Email
เรียก MCP tool: send_email
Template: welcome_email_template

เทคนิคหลัก: ลำดับขั้นตอนชัดเจน, dependencies ระหว่างขั้น, validation แต่ละ stage, คำสั่ง rollback เมื่อล้มเหลว

Pattern 2: Multi-MCP Coordination

ใช้เมื่อ: Workflows ครอบคลุมหลาย services

ตัวอย่าง: Design-to-development handoff

### Phase 1: Design Export (Figma MCP)
1. Export design assets จาก Figma
2. สร้าง design specifications
3. สร้าง asset manifest

### Phase 2: Asset Storage (Drive MCP)
1. สร้าง project folder ใน Drive
2. อัปโหลด assets ทั้งหมด
3. สร้าง shareable links

### Phase 3: Task Creation (Linear MCP)
1. สร้าง development tasks
2. แนบ asset links ไปที่ tasks
3. Assign ให้ engineering team

### Phase 4: Notification (Slack MCP)
1. Post handoff summary ไปที่ #engineering
2. รวม asset links และ task references

เทคนิคหลัก: แยก phase ชัดเจน, ส่งข้อมูลระหว่าง MCPs, validate ก่อนไปขั้นถัดไป, centralized error handling

Pattern 3: Iterative Refinement

ใช้เมื่อ: คุณภาพ output ดีขึ้นเมื่อทำซ้ำ

## Iterative Report Creation

### Initial Draft
1. ดึงข้อมูลผ่าน MCP
2. สร้าง draft report แรก
3. Save ไฟล์ชั่วคราว

### Quality Check
1. รัน validation script: scripts/check_report.py
2. ระบุปัญหา: sections ที่ขาด, formatting ไม่สม่ำเสมอ, data errors

### Refinement Loop
1. แก้ไขปัญหาแต่ละข้อ
2. Regenerate sections ที่ได้รับผลกระทบ
3. Re-validate
4. ทำซ้ำจนผ่าน quality threshold

### Finalization
1. Apply final formatting
2. สร้าง summary
3. Save final version

เทคนิคหลัก: เกณฑ์คุณภาพชัดเจน, การปรับปรุงแบบ iterative, validation scripts, รู้ว่าเมื่อไหรต้องหยุด iterate

Pattern 4: Context-aware Tool Selection

ใช้เมื่อ: Outcome เดียวกัน แต่ tools ต่างกันตาม context

## Smart File Storage

### Decision Tree
1. ตรวจสอบประเภทและขนาดไฟล์
2. เลือก storage location ที่ดีที่สุด:
   - ไฟล์ใหญ่ (>10MB): ใช้ cloud storage MCP
   - Collaborative docs: ใช้ Notion/Docs MCP
   - Code files: ใช้ GitHub MCP
   - Temporary files: ใช้ local storage

### Execute Storage
- เรียก MCP tool ที่เหมาะสม
- Apply service-specific metadata
- สร้าง access link

### อธิบายให้ผู้ใช้
อธิบายว่าทำไมถึงเลือก storage นั้น

เทคนิคหลัก: เกณฑ์การตัดสินใจชัดเจน, fallback options, ความโปร่งใสในการเลือก

Pattern 5: Domain-specific Intelligence

ใช้เมื่อ: Skill เพิ่ม specialized knowledge เกิน tool access

## Payment Processing with Compliance

### ก่อน Process (Compliance Check)
1. ดึง transaction details ผ่าน MCP
2. Apply compliance rules:
   - ตรวจ sanctions lists
   - Verify jurisdiction allowances
   - ประเมิน risk level
3. บันทึก compliance decision

### Processing
IF compliance passed:
  - เรียก payment processing MCP tool
  - Apply fraud checks ที่เหมาะสม
  - Process transaction
ELSE:
  - Flag for review
  - สร้าง compliance case

### Audit Trail
- Log compliance checks ทั้งหมด
- บันทึก processing decisions
- สร้าง audit report

เทคนิคหลัก: ฝัง domain expertise ใน logic, compliance ก่อน action, เอกสารครบถ้วน, governance ชัดเจน

Troubleshooting: การแก้ปัญหาที่พบบ่อย

Skill อัปโหลดไม่ได้:

Error: "Could not find SKILL.md in uploaded folder"
สาเหตุ: ไฟล์ชื่อไม่ถูกต้อง
วิธีแก้: เปลี่ยนชื่อเป็น SKILL.md (case-sensitive)

Error: "Invalid frontmatter"
สาเหตุ: YAML formatting ผิดพลาด
ผิด: ขาด delimiters ---
ผิด: quotes ไม่ปิด
ถูก: ใช้ --- เปิดและปิด frontmatter

Error: "Invalid skill name"
สาเหตุ: ชื่อมีช่องว่างหรือตัวพิมพ์ใหญ่
ผิด: name: My Cool Skill
ถูก: name: my-cool-skill

Skill ไม่ trigger:

สัญญาณ: Skill ไม่โหลดอัตโนมัติเลย

วิธีแก้: ปรับ description field

• Generic เกินไปไหม? ("ช่วยเรื่อง projects" ไม่ work)
• มี trigger phrases ที่ผู้ใช้จะพูดจริงๆ ไหม?
• ระบุประเภทไฟล์ที่เกี่ยวข้องไหม?

Debug: ถาม Claude ว่า "คุณจะใช้ [ชื่อ skill] เมื่อไหร่?" Claude จะ quote description กลับมา แก้ไขตามที่ขาดหาย

Skill trigger บ่อยเกินไป:

สัญญาณ: Skill โหลดสำหรับ queries ที่ไม่เกี่ยวข้อง

แก้ไข:

1. เพิ่ม negative triggers: ...Do NOT use for simple data exploration
2. ระบุให้ specific มากขึ้น
3. Clarify scope: ระบุให้ชัดว่าสำหรับอะไรเท่านั้น

MCP connection issues:

Checklist:

1. ตรวจว่า MCP server เชื่อมต่อ (Claude.ai: Settings > Extensions > [Service])
2. ตรวจ authentication (API keys ยังใช้ได้, permissions ถูกต้อง)
3. ทดสอบ MCP อิสระ ("ใช้ [Service] MCP ดึง projects ของฉัน")
4. ตรวจ tool names (case-sensitive)

Instructions ไม่ได้รับการปฏิบัติ:

สาเหตุที่พบบ่อย:

1. Instructions ยาวเกินไป → ย่อลง ใช้ bullet points
2. Instructions ถูกฝัง → ใส่ critical instructions ไว้ด้านบน
3. ภาษาคลุมเครือ → ใช้ CRITICAL header และระบุให้ชัด
4. Model "laziness" → เพิ่มใน user prompt ว่า "ทำให้ครบถ้วน อย่าข้ามขั้นตอน"

ปัญหา Large Context:

สาเหตุ: Skill ใหญ่เกิน, เปิด Skills พร้อมกันมากเกิน (มากกว่า 20-50)

แก้ไข:

1. ย้าย detailed docs ไป references/, ให้ SKILL.md ไม่เกิน 5,000 คำ
2. ลด Skills ที่เปิดพร้อมกัน, สร้าง "skill packs" สำหรับ related capabilities

บทที่ 6: แหล่งอ้างอิง

เอกสารทางการ

Anthropic Resources:

• Best Practices Guide
• Skills Documentation
• API Reference
• MCP Documentation

Blog Posts:

• Introducing Agent Skills
• Engineering Blog: Equipping Agents for the Real World
• How to Create Skills for Claude
• Building Skills for Claude Code

ตัวอย่าง Skills

• GitHub: anthropics/skills — Skills ที่ Anthropic สร้างไว้ให้ customize
• Partner Skills — จาก Asana, Atlassian, Canva, Figma, Sentry, Zapier และอื่นๆ

Tools และ Utilities

skill-creator skill:

• Built-in ใน Claude.ai และ Claude Code
• สร้าง Skills จาก descriptions
• Review และแนะนำการปรับปรุง

การขอความช่วยเหลือ

• คำถามทางเทคนิค: Claude Developers Discord
• Bug Reports: GitHub Issues > anthropics/skills/issues

ภาคผนวก A: Checklist ฉบับย่อ

ใช้ checklist นี้ validate Skill ก่อนและหลังอัปโหลด

ก่อนเริ่ม

• [ ] ระบุ use cases ที่ชัดเจน 2-3 ข้อ
• [ ] ระบุ tools ที่ต้องการ (built-in หรือ MCP)
• [ ] อ่านคู่มือนี้และ example skills แล้ว
• [ ] วางแผน folder structure แล้ว

ระหว่างพัฒนา

• [ ] โฟลเดอร์ชื่อเป็น kebab-case
• [ ] ไฟล์ SKILL.md มีอยู่ (สะกดถูก)
• [ ] YAML frontmatter มี delimiters ---
• [ ] name field: kebab-case, ไม่มีช่องว่าง, ไม่มีตัวพิมพ์ใหญ่
• [ ] description มีทั้ง WHAT และ WHEN
• [ ] ไม่มี XML tags (< >) ที่ไหนเลย
• [ ] Instructions ชัดเจนและ actionable
• [ ] Error handling รวมไว้
• [ ] ตัวอย่างมีให้
• [ ] References ลิงก์ชัดเจน

ก่อนอัปโหลด

• [ ] ทดสอบ triggering บน obvious tasks
• [ ] ทดสอบ triggering บน paraphrased requests
• [ ] ตรวจสอบว่าไม่ trigger บน unrelated topics
• [ ] Functional tests ผ่าน
• [ ] Tool integration ทำงานได้ (ถ้ามี)
• [ ] Compress เป็น .zip แล้ว

หลังอัปโหลด

• [ ] ทดสอบในบทสนทนาจริง
• [ ] Monitor under/over-triggering
• [ ] รวบรวม user feedback
• [ ] Iterate บน description และ instructions
• [ ] อัปเดต version ใน metadata

ภาคผนวก B: YAML Frontmatter

Required Fields

---
name: skill-name-in-kebab-case
description: ทำอะไรและเมื่อไหรควรใช้ รวม trigger phrases เฉพาะ
---

Optional Fields ทั้งหมด

name: skill-name
description: [required description]
license: MIT
allowed-tools: "Bash(python:*) Bash(npm:*) WebFetch"
metadata:
  author: Company Name
  version: 1.0.0
  mcp-server: server-name
  category: productivity
  tags: [project-management, automation]
  documentation: https://example.com/docs
  support: support@example.com

Security Notes

Allowed (ทำได้):

• Standard YAML types (strings, numbers, booleans, lists, objects)
• Custom metadata fields
• Long descriptions (สูงสุด 1,024 ตัวอักษร)

Forbidden (ห้าม):

• XML angle brackets (< >) — security restriction
• Code execution ใน YAML
• Skills ที่ชื่อขึ้นต้นด้วย "claude" หรือ "anthropic" (สงวนไว้)

ภาคผนวก C: ตัวอย่าง Skill สมบูรณ์

ดู Skills ระดับ production จริงที่แสดง patterns ในคู่มือนี้ได้ที่:

• Document Skills — การสร้าง PDF, DOCX, PPTX, XLSX
• Example Skills — รูปแบบ workflow ต่างๆ
• Partner Skills Directory — Skills จาก Asana, Atlassian, Canva, Figma, Sentry, Zapier และอื่นๆ

Clone, แก้ไขตาม use case ของคุณ และใช้เป็น template ได้เลย

คู่มือนี้แปลจาก "The Complete Guide to Building Skills for Claude" โดย Anthropic สงวนสิทธิ์โดย Anthropic — claude.ai