Claude Code Skills: ไฟล์ SKILL.md ที่โมเดลใช้เรียกใช้งานจริง

อัปเดตล่าสุด: June 28, 2026

Claude Code Skill คือโฟลเดอร์ที่มีไฟล์ SKILL.md ซึ่ง agent จะดึงเข้าสู่ context ก็ต่อเมื่องานที่ทำตรงกับมันเท่านั้น ฉันสร้าง skill แรกของฉันเพื่อหยุดการคัดลอก checklist การย้ายฐานข้อมูล 200 คำเดิม ๆ ไปยังทุกเซสชัน ไฟล์เดียวนี้ช่วยประหยัดเวลาให้ฉันได้ประมาณหนึ่งชั่วโมงต่อสัปดาห์

นี่คือฉบับย่อ จากนั้นจะเป็นส่วนที่ลงรายละเอียดเชิงปฏิบัติ: skill คืออะไร วิธีเขียน frontmatter และ body ของ SKILL.md โมเดลตัดสินใจเรียกใช้ skill อย่างไร และเมื่อไหร่ที่การใช้ skill นั้นเกินความจำเป็นเมื่อเทียบกับการใช้ prompt ธรรมดา หากคุณเคยใช้งาน Claude Code มาก่อน คุณสามารถสร้าง skill แรกของคุณได้ภายในเวลาไม่ถึงห้านาที

คำตอบสั้น ๆ: Claude Code Skill คืออะไร?

Skill คือความสามารถที่นำกลับมาใช้ใหม่ได้และถูกเรียกโดยโมเดล โดยจัดเก็บเป็น SKILL.md (บวกกับสคริปต์สนับสนุนทางเลือก) แตกต่างจาก system prompt ที่โหลดอยู่ตลอดเวลา, skill จะถูกโหลดเมื่อจำเป็น เมื่อโมเดลตัดสินว่ามันเกี่ยวข้องกับคำขอของคุณ คุณเขียนชื่อ คำอธิบายว่า เมื่อไหร่ ควรใช้ และชุดคำสั่งเนื้อหา ส่วนคำอธิบายเป็นฟิลด์ที่สำคัญที่สุด เพราะนั่นคือสิ่งที่โมเดลอ่านเพื่อตัดสินใจว่าจะเรียกใช้งาน skill หรือไม่ Skills อาศัยอยู่ในเครื่องใน .claude/skills/ หรือส่งมาจาก registry ทำให้ทีมสามารถแชร์วิธีมาตรฐานในการทำ migrations, code review, หรือ releases ได้

หากคุณต้องการบริบทที่กว้างขึ้นเกี่ยวกับ CLI เอง โปรดดู Claude Code ultimate guide for 2026 สำหรับวิธีที่ skills แตกต่างจาก sub-agents ที่เปิดตลอดเวลา โปรดอ่าน how I automated my workflow with Claude Code sub-agents

Skill คืออะไรกันแน่ และประกอบด้วยอะไรบ้าง?

Skill คือไดเรกทอรี สิ่งที่จำเป็นขั้นต่ำที่สุดคือไฟล์ SKILL.md นอกจากนี้ยังสามารถรวมสคริปต์ เทมเพลต หรือเอกสารอ้างอิงที่มาพร้อมกับทักษะนั้นได้ เอกสาร agent-skills ของ Anthropic อธิบายว่า skill คือชุดคำแนะนำและทรัพยากรที่ถูกบรรจุไว้ ซึ่งโมเดลสามารถโหลดเมื่อมีความเกี่ยวข้อง (docs.anthropic.com/en/docs/agents-and-tools/agent-skills).

ผมมองว่า skill คือซับรูทีนที่มีชื่อและมีการระบุเวอร์ชันสำหรับโมเดล สิ่งที่ทำให้มันแตกต่างจาก prompt ยาว ๆ มี 3 อย่าง:

1. มันเป็นแบบ opt-in โมเดลจะโหลดมันก็ต่อเมื่องานนั้นดูเหมือนจะตรงกับคำอธิบายเท่านั้น
2. มันเป็นแบบ scoped คุณสามารถแนบไฟล์และสคริปต์ที่สมเหตุสมผลสำหรับความสามารถนั้นเท่านั้น
3. มันเป็นแบบ shareable โฟลเดอร์นี้สามารถพกพาไปใช้ได้ในหลายโปรเจกต์และเพื่อนร่วมทีม

ตัว CLI เองเป็น open source และ convention ของ skill ก็มีการบันทึกไว้พร้อมกับมันบน GitHub (github.com/anthropics/claude-code) ซึ่งเป็นที่ที่ผมตรวจสอบเมื่อพฤติกรรมเปลี่ยนแปลงระหว่างการปล่อยเวอร์ชัน

คุณจะจัดโครงสร้างไฟล์ SKILL.md อย่างไร?

ไฟล์นี้ประกอบด้วยสองส่วนคือ YAML frontmatter และเนื้อหาหลักแบบ Markdown ส่วน frontmatter จะบอกโมเดลว่าต้องรันเมื่อไหร่ ส่วน body จะบอกว่าให้ทำอะไร นี่คือโครงสร้างที่ฉันใช้

---
name: safe-migration
description: Use when the user asks to create, modify, or roll back a database migration. Covers schema changes, down migrations, and verifying against the staging dump.
---

ส่วน body เป็น Markdown ธรรมดา ฉันเก็บสามส่วนไว้: เป้าหมายแบบบรรทัดเดียว ขั้นตอนที่ทำตามลำดับ และเกต "หยุดและยืนยัน" อย่างชัดเจน ชื่อ (name) ต้องตรงกับชื่อโฟลเดอร์ คำอธิบาย (description) ควรเขียนสำหรับโมเดล ไม่ใช่สำหรับมนุษย์ ดังนั้นมันจึงอ่านเหมือนเงื่อนไขกระตุ้น

ฉันได้ทดสอบสิ่งนี้โดยตรง ด้วยคำอธิบายที่คลุมเครือ เช่น "ช่วยเรื่องฐานข้อมูล" ทักษะนี้จะทำงานกับคำถาม SQL ที่ไม่เกี่ยวข้อง หลังจากที่ฉันเขียนใหม่เป็น "Use when the user asks to create, modify, or roll back a database migration," ความแม่นยำในการเรียกใช้ก็เพิ่มขึ้นจากประมาณ 60 percent จนกลายเป็นเชื่อถือได้ คำอธิบายกำลังทำหน้าที่กำหนดเส้นทาง ดังนั้นให้เวลาแก้ไขของคุณตรงส่วนนั้น

ต้องเปลี่ยนสิ่งใดให้เป็น "ทักษะ" เมื่อไหร่?

นี่คือคำถามที่ผมได้รับมากที่สุด กฎของผมคือ: หากผมได้คัดลอกชุดคำแนะนำเดียวกันนี้ไปแล้วสามครั้งภายในสองสัปดาห์ และมันยาวกว่าหนึ่งย่อหน้า มันก็จะกลายเป็น "ทักษะ" ด้านล่างนี้คือตารางการตัดสินใจที่ผมใช้จริง

แกนที่สองคือเรื่องของต้นทุน ทุกทักษะที่โหลดจะเพิ่ม tokens ให้กับ context ดังนั้นชุดคำแนะนำขนาดใหญ่ที่เกี่ยวข้องอยู่เสมอจึงเหมาะที่จะเป็นหน่วยความจำระดับโปรเจกต์ (project-level memory) หรือ custom command มากกว่าการเป็น skill ทักษะจะโดดเด่นสำหรับความเชี่ยวชาญที่ มีความเกี่ยวข้องตามเงื่อนไข

ตัวอย่างที่เป็นรูปธรรมที่ผมเขียนเป็น skill: กระบวนการปล่อยเวอร์ชันของเราต้องมีการอัปเดต changelog, เพิ่ม version files สามไฟล์, การติดแท็ก (tagging), และโพสต์สรุปไปยัง Slack ผมเคยเขียนมันครั้งหนึ่งให้เป็น skill และตอนนี้ผมแค่พูดว่า "cut a release" แล้วโมเดลก็จะรันรายการตรวจสอบทั้งหมดตามลำดับ ตัวอย่างที่ผมไม่ได้ทำ: คือการ refactor config file ครั้งเดียว ซึ่งสิ่งนั้นยังคงเป็น prompt

รูปแบบการเรียกใช้ทักษะโดยโมเดลทำงานอย่างไร?

รูปแบบที่ทำให้ทักษะรู้สึกเหมือนเวทมนตร์คือ คุณไม่เรียกใช้มัน. คุณเพียงแค่บรรยายงาน และโมเดลจะอ่านคำอธิบายของทักษะที่มีอยู่และดึงทักษะที่ตรงกันมา นี่มีการบันทึกไว้ในเอกสาร Claude Code อย่างเป็นทางการ (docs.anthropic.com/en/docs/claude-code).

ขั้นตอนการทำงานมีลักษณะดังนี้:

1. คุณพิมพ์คำขอด้วยภาษาธรรมชาติ
2. โมเดลจะเห็น name และ description ของแต่ละทักษะที่ติดตั้งไว้
3. มันจะให้คะแนนความเกี่ยวข้องกับคำขอของคุณ
4. ส่วนของทักษะที่ชนะ (และไฟล์ที่รวมมาด้วย) จะเข้าสู่บริบท
5. โมเดลจะดำเนินการตามคำสั่ง

ผลที่ได้ในทางปฏิบัติคือ: คุณต้องเขียน description ราวกับว่าคุณกำลังเขียนรายการสำหรับเครื่องมือค้นหาให้โมเดล เริ่มต้นด้วยกริยาและขอบเขตการกระตุ้น เปรียบเทียบคำอธิบายทั้งสองนี้:

• Weak: "A skill for handling git things."
• Strong: "Use when the user asks to squash, rebase, or split commits on the current branch. Produces an interactive plan before running any rewrite."

ตัวที่แข็งแกร่งจะระบุกริยาการกระตุ้นและ guardrail นั่นคือสิ่งที่ทำให้การเรียกใช้มีความน่าเชื่อถือ หากคุณกำลังเชื่อมโยงทักษะเข้าด้วยกันด้วยเครื่องมือ Claude Code MCP integration guide จะครอบคลุมวิธีการที่ external tool servers เข้ากับ skill bundles สำหรับโปรโตคอลพื้นฐานที่เชื่อมต่อพวกมัน ให้ดูที่ MCP and the model context.

คุณจะทริกเกอร์และดีบักสกิลได้อย่างไร?

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

• ระบุให้ชัดเจน. การพูดว่า "use the safe-migration skill" บังคับให้มันทำงาน มีประโยชน์เมื่อคำอธิบายคลุมเครือ
• แสดงรายการสกิลที่ติดตั้ง. ขอให้โมเดลแสดงรายการสกิลที่มีอยู่และคำอธิบายของมัน นี่คือวิธีที่ฉันยืนยันว่ามีการลงทะเบียนสกิลใหม่แล้ว
• ตรวจสอบ trace. เมื่อสกิลทำงานผิดพลาด ฉันจะอ่านว่าคำอธิบายใดที่ตรงกันและปรับปรุงถ้อยคำทริกเกอร์ให้รัดกุมขึ้น

เมื่อสกิลไม่ทำงาน สาเหตุเกือบทั้งหมดมาจากคำอธิบาย ไม่ใช่ตำแหน่งไฟล์ ฉันจะเขียนประโยคแรกใหม่ให้ขึ้นต้นด้วย "Use when..." และเพิ่มกริยาที่เฉพาะเจาะจง ซึ่งวิธีนี้แก้ไขปัญหาได้ถึง 9 ใน 10 ครั้ง

นี่คือรายการตรวจสอบการดีบักที่ฉันใช้ตามลำดับ:

Skill เทียบกับ sub-agent และ slash command

ทั้งสามอย่างนี้มีความทับซ้อนกัน และผู้คนมักจะสับสนอยู่เสมอ ผมจึงแยกความแตกต่างให้เข้าใจง่ายๆ ด้วยการแบ่งประเภทดังนี้

• Skill: คำสั่งที่ถูกเรียกใช้โดยโมเดล พร้อมไฟล์เสริม เหมาะสำหรับความเชี่ยวชาญแบบมีเงื่อนไข (conditional expertise)
• Sub-agent: อินสแตนซ์ Claude Code แยกต่างหากที่ทำงานแบบโดดเดี่ยว เหมาะสำหรับงานที่ต้องทำพร้อมกันและใช้เวลานาน บทความ sub-agent automation write-up ของผมจะเจาะลึกในส่วนนี้
• Slash command: ทางลัดที่คุณพิมพ์โดยตั้งใจ เหมาะสำหรับสิ่งที่ต้องการใช้งานทันทีเสมอ

Skill เป็นอย่างเดียวในสามอย่างนี้ที่โมเดลจะเลือกให้คุณ นั่นคือทั้งพลังพิเศษและความเสี่ยงของมัน: หากอธิบาย Skill ผิดพลาด จะทำให้บริบทสูญเปล่าไปโดยที่คุณไม่รู้ตัว

คุณจะแชร์ทักษะและใช้ Registry ได้อย่างไร?

ทักษะ (skill) ก็เป็นเพียงโฟลเดอร์ ดังนั้นในทางหลักการแล้ว การแชร์จึงทำได้ง่ายมาก ฉันจะวางโฟลเดอร์ไว้ใต้ .claude/skills/ ใน repo แล้ว commit เพื่อนร่วมทีมก็จะได้รับมันเมื่อทำการ clone สำหรับการแชร์ข้ามทีม ชุมชนจะดูแล registries และเครื่องมืออย่างเป็นทางการก็จะชี้ไปยังตำแหน่งทั่วไป

การตั้งค่าที่ใช้ได้จริงของฉัน:

1. เก็บทักษะเฉพาะโปรเจกต์ไว้ใน repo และมีการควบคุมเวอร์ชัน (version-controlled)
2. เก็บทักษะส่วนตัวไว้ใน dotfiles repo โดยทำ symlink เข้าไปที่ .claude/skills/
3. กำหนดเวอร์ชันของทักษะ (Pin skill versions) เมื่อแชร์ภายนอก เนื่องจากการเปลี่ยนแปลงคำอธิบายอาจทำให้พฤติกรรมเปลี่ยนไปอย่างเงียบๆ

ข้อควรระวังที่ต้องพูดถึงเรื่องการแชร์: ทักษะจะมีการเข้ารหัสสมมติฐานเกี่ยวกับ stack ของคุณ ทักษะการย้ายข้อมูล (migration skill) ที่เขียนสำหรับ Drizzle จะสร้างผลลัพธ์ที่ผิดพลาดในโปรเจกต์ Prisma อย่างมั่นใจ หากคำอธิบายไม่ได้ป้องกันขอบเขตงานเสมอ ควรระบุ framework และ guardrails ในคำอธิบาย และเพิ่มขั้นตอน "หยุดและยืนยัน" ก่อนดำเนินการใดๆ ที่เป็นแบบทำลายข้อมูล (destructive actions) ฉันได้เรียนรู้เรื่องนี้ด้วยวิธีที่ยากลำบาก เมื่อทักษะที่แชร์ไปทำการ rewrite แบบทำลายล้างบน branch ผิด ดังนั้นให้ถือว่าทุกทักษะที่แชร์มานั้นไม่น่าเชื่อถือ จนกว่าคำอธิบายของมันจะพิสูจน์เป็นอย่างอื่น

แหล่งที่มาของรูปภาพ

• Black screen with code text overlay on a developer workstation — ภาพโดย Pixabay บน Pexels
• Close-up of programming code on a monitor during development — ภาพโดย Christina Morillo บน Pexels
• Laptop showing a code editor during software development — ภาพโดย luis gomes บน Pexels