Skill คือโฟลเดอร์เล็ก ๆ ที่เอาไว้สอนให้ Claude ทำงานเฉพาะอย่างได้เก่งขึ้น ถ้ายังไม่คุ้น Claude คือผู้ช่วย AI ที่รับคำสั่งผ่านการแชต คล้ายแชตบอตที่หลายคนใช้กันอยู่แล้ว หัวใจของ Skill อยู่ที่ไฟล์เดียวชื่อ SKILL.md เขียนเสร็จครั้งเดียว Claude ก็จะหยิบมาใช้เองทุกครั้งที่เจองานตรงกับที่สอนไว้ ไม่ต้องพิมพ์อธิบายขั้นตอนเดิมซ้ำให้เสียเวลา

ก่อนจะมี Skill ถ้าอยากให้ Claude ทำงานเฉพาะทางให้ได้มาตรฐานเท่ากันทุกครั้ง ต้องอธิบายใหม่ตั้งแต่ต้นทุกรอบ ผลลัพธ์ก็เหวี่ยงไปมาไม่นิ่ง Skill เข้ามาแก้ตรงนี้ด้วยการเก็บวิธีทำงานที่ดีที่สุดไว้ในไฟล์ ให้ Claude ทำตามเองอัตโนมัติ ล่าสุดทีม Anthropic บริษัทผู้พัฒนา Claude เพิ่งปล่อยคู่มือฉบับเต็ม ตั้งแต่โครงสร้างไฟล์ การเขียน description ให้ Claude เรียกใช้ การทดสอบ ไปจนถึงการแจกจ่าย บทความนี้รวบมาเรียงเป็นขั้นตอนที่ทำตามได้จริงตั้งแต่ Skill แรก

Skill จริง ๆ แล้วเป็นแค่โฟลเดอร์เดียว

หน้าตาของ Skill เรียบกว่าที่หลายคนคิด มันคือโฟลเดอร์เดียวที่มีไฟล์ SKILL.md เป็นไฟล์หลัก ส่วนที่เหลือจะใส่หรือไม่ใส่ก็ได้ เช่น scripts/ สำหรับเก็บสคริปต์ references/ สำหรับเอกสารอ้างอิงที่ยาว และ assets/ สำหรับไฟล์ประกอบอย่างเทมเพลตหรือรูป

my-skill/
├── SKILL.md      ← จำเป็น (หัวใจของ Skill)
├── scripts/      ← ใส่หรือไม่ใส่ก็ได้
├── references/   ← ใส่หรือไม่ใส่ก็ได้
└── assets/       ← ใส่หรือไม่ใส่ก็ได้

กฎการตั้งชื่อมีไม่กี่ข้อแต่พลาดไม่ได้ ชื่อโฟลเดอร์ต้องเป็น kebab-case คือใช้ตัวพิมพ์เล็กแล้วคั่นคำด้วยขีดกลางเท่านั้น ห้ามมีช่องว่าง ห้ามขีดล่าง และห้ามตัวพิมพ์ใหญ่ ส่วนไฟล์หลักต้องสะกดว่า SKILL.md ตรงตัวด้วยตัวพิมพ์ใหญ่ทั้งคำ เพราะระบบแยกแยะตัวพิมพ์เล็กพิมพ์ใหญ่ ถ้าตั้งเป็น skill.md หรือ SKILL.MD ระบบจะไม่รู้จัก และอย่าวางไฟล์ README.md ไว้ในโฟลเดอร์ Skill เด็ดขาด ถ้าจะแจกผ่าน GitHub ให้ย้าย README ไปไว้ที่ระดับ repo แทน

ข้างในไฟล์ SKILL.md เองก็แบ่งเป็นสองส่วน ส่วนบนคือ YAML frontmatter ที่คอยบอก Claude ว่าควรโหลด Skill นี้มาใช้เมื่อไหร่ ส่วนล่างคือ instructions ที่เขียนด้วย Markdown สอนว่าให้ทำงานยังไงเป็นขั้นเป็นตอน

ทำไม Claude ถึงรู้ว่าควรหยิบ Skill ไหนมาใช้

คำถามที่หลายคนสงสัยคือ ถ้าเรามี Skill อยู่เป็นสิบ ๆ อัน Claude จะเลือกหยิบอันที่ใช่ขึ้นมาได้ยังไง โดยไม่ทำให้ทุกอย่างช้าลง คำตอบอยู่ที่กลไกที่เรียกว่า progressive disclosure หรือการทยอยเปิดข้อมูลทีละชั้น ซึ่งแบ่งเป็นสามระดับ

ระดับแรกคือ YAML frontmatter ระบบโหลดส่วนนี้เข้าไปอยู่ใน system prompt ตลอดเวลา แต่มีเพียงข้อมูลสั้น ๆ พอให้ Claude รู้ว่า Skill อันนี้เกี่ยวกับงานตรงหน้าหรือเปล่า

ระดับสองคือเนื้อหาในตัว SKILL.md ระบบจะโหลดส่วนนี้ก็ต่อเมื่อ Claude ตัดสินใจแล้วว่า Skill นี้เกี่ยวข้องกับงานที่ขอจริง ๆ

ระดับสามคือไฟล์ยาวๆ ที่เก็บไว้ใน references/ Claude จะเปิดอ่านเฉพาะตอนที่ต้องใช้ข้อมูลนั้นจริงเท่านั้น

ผลก็คือ Claude ไม่ต้องแบกเนื้อหาของทุก Skill ไว้พร้อมกัน จึงประหยัด token และไม่อืด นี่ยังเป็นเหตุผลที่คู่มือแนะนำให้ SKILL.md ยาวไม่เกินราว 5,000 คำ ถ้ายาวกว่านั้นให้ย้ายรายละเอียดไปไว้ใน references/ แทน

หัวใจของการถูกเรียกใช้อยู่ที่ description

ในบรรดาข้อมูลทั้งหมดที่เขียนลง Skill ช่องที่ตัดสินว่า Claude จะหยิบมันมาใช้หรือมองข้ามคือ description ใน frontmatter ถ้าเขียนช่องนี้ไม่ดี Skill ที่อุตส่าห์ทำมาก็จะนอนเฉย ไม่มีวันถูกเรียก

description ที่ดีต้องบอกสองอย่างเสมอ คือ WHAT มันทำอะไรได้ และ WHEN ควรใช้ตอนไหน ให้ระบุงานเจาะจง ใส่วลีที่ผู้ใช้จะพิมพ์ออกมาจริงเข้าไป และถ้าเกี่ยวกับไฟล์ประเภทไหนก็บอกไว้ด้วย ความยาวทั้งหมดห้ามเกิน 1,024 ตัวอักษร

---
name: figma-handoff
description: Analyzes Figma design files and generates developer handoff documentation. Use when user uploads .fig files, asks for 'design specs', 'component documentation', or 'design-to-code handoff'.
---

ลองเทียบกับตัวอย่างที่แย่อย่าง Helps with projects. ที่กว้างเสียจนไม่มีทางรู้ว่าควรเรียกตอนไหน Claude ก็จะไม่หยิบมาใช้ เพราะไม่มีสัญญาณบอกเลยว่างานแบบไหนเข้าข่าย

ข้อห้ามมีสองข้อที่ต้องจำให้ขึ้นใจ ข้อแรกคือห้ามใส่เครื่องหมาย XML หรือวงเล็บแหลม < > ในทุกช่อง เพราะ frontmatter จะไปอยู่ใน system prompt ถ้ามีเนื้อหาแปลกปลอมแทรกเข้ามา คนอื่นอาจใช้ฝังคำสั่งอันตรายได้ ข้อสองคือชื่อ Skill ห้ามขึ้นต้นด้วยคำว่า claude หรือ anthropic เพราะเป็นชื่อสงวนของระบบ

เริ่มจากตอบสามคำถามก่อนลงมือเขียน

ก่อนสร้างโฟลเดอร์ใด ๆ คู่มือแนะนำให้กำหนด use case สัก 2-3 ข้อก่อน โดยตอบคำถามสี่ข้อนี้กับตัวเอง ผู้ใช้อยากทำอะไร ต้องใช้เครื่องมืออะไรบ้าง วลีที่ผู้ใช้จะพิมพ์เพื่อเรียกใช้คืออะไร และผลลัพธ์ที่อยากได้หน้าตาเป็นแบบไหน

พอเห็นภาพชัดแล้ว ลำดับการลงมือก็ตรงไปตรงมา

1. สร้างโฟลเดอร์ชื่อ kebab-case เช่น meeting-notes
2. สร้างไฟล์ SKILL.md ไว้ข้างใน เริ่มจาก frontmatter ที่มี name กับ description
3. เขียน instructions ต่อท้ายเป็นขั้นตอน แล้วค่อยเพิ่ม scripts/ references/ assets/ เมื่อจำเป็น

โครงสร้างของ SKILL.md ที่คู่มือแนะนำให้ใช้เป็นแม่แบบ หน้าตาประมาณนี้

---
name: your-skill
description: [ทำอะไร] + [ใช้เมื่อไหร่] + [ความสามารถหลัก]
---
# ชื่อ Skill
## Instructions
### Step 1: ...
## Examples
## Troubleshooting

งานที่คนนิยมเอามาทำเป็น Skill แบ่งได้สามกลุ่ม ดูไว้จะได้เลือกถูกว่าของเราเข้าข่ายแบบไหน

• Document & Asset Creation สำหรับงานผลิตชิ้นงานที่ต้องออกมาสม่ำเสมอ เช่น เอกสาร สไลด์ ดีไซน์ หรือโค้ด ตัวอย่างคือ frontend-design
• Workflow Automation สำหรับกระบวนการหลายขั้นที่ต้องทำตามวิธีเดิมทุกครั้ง ตัวอย่างคือ skill-creator
• MCP Enhancement สำหรับเสริมวิธีใช้งานเครื่องมือที่ต่อกับ Claude ผ่าน MCP (ช่องทางมาตรฐานที่เชื่อม Claude เข้ากับเครื่องมือและข้อมูลภายนอกแบบเรียลไทม์) อยู่แล้ว ตัวอย่างคือ sentry-code-review

ถ้ายังไม่คุ้นกับ MCP ให้นึกภาพแบบนี้ MCP คือครัวที่เต็มไปด้วยเครื่องมือและวัตถุดิบสดที่ Claude เอื้อมหยิบได้ ส่วน Skill คือสูตรอาหารที่บอกว่าจะใช้เครื่องมือในครัวนั้นยังไงให้ออกมาดีทุกครั้ง วิธีเลือกกลุ่มก็ง่าย ถ้าเป็นงานผลิตชิ้นงานซ้ำ ๆ ให้เริ่มที่กลุ่มแรก ถ้าเป็นกระบวนการหลายขั้นให้เลือกกลุ่มที่สอง ถ้าต่อกับเครื่องมือภายนอกอยู่แล้วให้เลือกกลุ่มที่สาม

ถ้าไม่อยากเริ่มจากศูนย์ ก็มี Skill สำเร็จรูปชื่อ skill-creator ให้เปิดใช้ได้เลย มันช่วยสร้าง Skill แรกจากคำอธิบายภาษาคนได้ในราว 15-30 นาที ช่วยรีวิว Skill ที่มีอยู่ และแนะนำ test case ให้ด้วย เปิดใช้แล้วพิมพ์สั่งทำนองนี้

Use the skill-creator skill to help me build a skill for [your use case]

ข้อจำกัดของมันคือรันชุดทดสอบอัตโนมัติแทนเราไม่ได้ และไม่ได้ให้คะแนนประเมินออกมาเป็นตัวเลข

ทดสอบสามระดับก่อนปล่อยใช้จริง

Skill ที่เขียนเสร็จยังไม่ควรเอาไปใช้งานทันที คู่มือแนะนำให้ทดสอบสามระดับไล่จากเบาไปหนัก

ระดับแรกคือ triggering test ดูว่า Skill ถูกเรียกในจังหวะที่ควรทำงานหรือเปล่า ให้ลองพิมพ์ทั้งคำสั่งตรง ๆ คำสั่งที่ใช้คำอื่นแทน และคำสั่งที่ไม่เกี่ยวกันเลย โดยอันสุดท้ายนี้ Skill ต้องไม่ถูกเรียกขึ้นมา เป้าหมายที่คู่มือตั้งไว้คือเรียกติดราว 90% จากคำสั่งที่เกี่ยวข้องสัก 10-20 แบบ

ระดับสองคือ functional test ดูว่าพอถูกเรียกขึ้นมาแล้ว มันทำงานออกมาถูกต้องตามที่ตั้งใจไว้ไหม

ระดับสามคือการเทียบผลลัพธ์ ลองทำงานเดียวกันทั้งแบบเปิด Skill และไม่เปิด แล้วดูว่ามันช่วยให้ผลดีขึ้นจริงหรือเปล่า

ตัวเลขพวกนี้คู่มือย้ำเองว่าเป็นเป้าหมายแบบคร่าวๆ ไม่ใช่เกณฑ์ตายตัว ใช้เป็นแนวเทียบว่าใกล้เคียงแล้วหรือยังก็พอ ไม่ต้องเป๊ะถึงจะถือว่าผ่าน

ห้าแพตเทิร์นการออกแบบที่หยิบมาใช้ซ้ำได้

พอเริ่มทำ Skill ที่ซับซ้อนขึ้น คู่มือรวบแพตเทิร์นการออกแบบที่ได้ผลไว้ห้าแบบ ให้เลือกหยิบตามหน้างาน

• Sequential workflow orchestration สำหรับงานที่ต้องทำเป็นลำดับตายตัว และต้องตรวจความถูกต้องทุกขั้นก่อนทำขั้นถัดไป
• Multi-MCP coordination สำหรับ workflow ที่วิ่งข้ามหลายบริการต่อกัน เช่น Figma ไป Drive ไป Linear ไป Slack
• Iterative refinement สำหรับงานที่ต้องวนปรับ ตั้งแต่ร่าง ตรวจคุณภาพ ปรับแก้ แล้วค่อยสรุป
• Context-aware tool selection สำหรับงานที่ผลลัพธ์เหมือนเดิม แต่ต้องเลือกเครื่องมือต่างกันตามบริบท เช่น เลือกตามขนาดไฟล์
• Domain-specific intelligence สำหรับฝังความรู้เฉพาะทางลงไป เช่น ให้ตรวจกฎ compliance ก่อนประมวลผลการจ่ายเงิน

วิธีเลือกก็ดูจากหน้างาน ถ้างานมีลำดับชัดให้เลือกแบบแรก ถ้าพัวพันหลายเครื่องมือให้เลือกแบบที่สอง ถ้าเน้นวนแก้จนเนี้ยบให้เลือกแบบที่สาม ส่วนสองแบบที่เหลือเหมาะกับงานที่ต้องตัดสินใจตามบริบท หรือมีกฎเฉพาะของวงการนั้น ๆ

เมื่อ Skill ไม่ยอมทำงานอย่างที่หวัง

ปัญหาที่เจอบ่อยกับ Skill มักวนอยู่ไม่กี่อาการ และแต่ละอาการก็มีทางแก้ที่ตรงตัว

ถ้าอยากดีบักว่า Skill จะถูกเรียกตอนไหน ลองพิมพ์ถาม Claude ทำนองนี้

When would you use the [skill-name] skill?

Claude จะตอบกลับมาโดยยกข้อความจาก description ของเราขึ้นมา ทำให้เห็นทันทีว่าตรงไหนเขียนกว้างหรือแคบเกินไป ส่วนอาการทำงานลวกๆ ลองเติมประโยคกำกับสั้นๆ ทำนองนี้เข้าไป

Take your time to do this thoroughly

คู่มือสังเกตว่า ประโยคแบบนี้ได้ผลกว่าเมื่อใส่ในคำสั่งของผู้ใช้ มากกว่าฝังเอาไว้ใน SKILL.md

แจกจ่ายให้คนอื่นเอาไปใช้ต่อ

พอ Skill ใช้ได้ดีแล้ว ขั้นต่อไปคือส่งต่อให้คนอื่น ซึ่งทำได้หลายทางตามแพลตฟอร์มที่ใช้งาน

• บน Claude.ai สำหรับผู้ใช้ทั่วไป ดาวน์โหลดโฟลเดอร์ออกมาบีบเป็นไฟล์ .zip แล้วเข้าไปที่ Settings > Capabilities > Skills แล้วกด Upload
• บน Claude Code (เครื่องมือของ Claude สำหรับเขียนโค้ดผ่านเทอร์มินัล) แค่วางโฟลเดอร์ Skill ลงในไดเรกทอรี skills ก็ใช้ได้เลย
• ผ่าน API ใช้ /v1/skills endpoint สำหรับจัดการ แล้วเรียกใช้ใน Messages API ผ่าน container.skills โดยต้องเปิด Code Execution Tool beta ไว้ก่อน
• ผ่าน GitHub แจกเป็น repo ได้ จุดที่ต้องระวังคืออย่าวาง README ไว้ในโฟลเดอร์ Skill ให้ไปไว้ที่ระดับ repo แทน และมี repo สาธารณะชื่อ anthropics/skills ที่รวมตัวอย่าง Skill ไว้ให้ดูเป็นแนวได้

นอกจากนี้ยังมี organization-level skills ที่ผู้ดูแลระบบ deploy ให้คนทั้ง workspace ใช้พร้อมกันได้ ซึ่งเพิ่งเปิดตัวไปเมื่อ 18 ธันวาคม 2025

จุดที่ทำให้ Skill น่าลงทุนเรียนคือมันเป็น open standard เหมือนกับ MCP เขียนครั้งเดียวก็ย้ายข้ามแพลตฟอร์มได้ ทำงานเหมือนกันทั้งบน Claude.ai, Claude Code และ API ตอนนี้ก็เริ่มมี partner skill จากเจ้าใหญ่ๆ อย่าง Asana, Atlassian, Canva, Figma, Sentry และ Zapier ให้หยิบมาใช้กันแล้ว

เริ่มจากงานน่าเบื่อที่ทำซ้ำทุกวัน

Skill ที่ดีไม่ได้เริ่มจากงานใหญ่หรือซับซ้อน แต่เริ่มจากงานน่าเบื่อสักอย่างที่ต้องทำซ้ำเกือบทุกวัน ลองเขียนวิธีที่ดีที่สุดของงานนั้นลง SKILL.md ไฟล์เดียว ตั้งชื่อโฟลเดอร์ให้ถูก ใส่ description ที่บอก WHAT กับ WHEN ให้ครบ แล้วทดสอบสักสิบกว่าคำสั่งว่า Claude เรียกใช้จริงไหม เท่านี้ก็ได้ Skill แรกแล้ว

สิ่งที่เปลี่ยนไปจริง ๆ ไม่ใช่ Claude ฉลาดขึ้น แต่เป็นความรู้ที่เคยอยู่แค่ในหัวเรา ซึ่งถูกย้ายลงไฟล์ที่หยิบมาใช้ซ้ำได้ไม่รู้จบ

ที่มา: คู่มือ The Complete Guide to Building Skills for Claude จาก Anthropic