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

• Claude Skills คือแพ็กเกจความรู้เวิร์กโฟลว์ที่ออกแบบมาเพื่อกำหนดลำดับงานที่ทำซ้ำไว้ครั้งเดียวแล้ว นำกลับมาใช้ซ้ำได้อย่างต่อเนื่อง
• คู่มือ PDF 33 หน้า ที่เขียนโดย Anthropic โดยตรง ครอบคลุมกระบวนการทั้งหมดแบบเป็นขั้นตอนตั้งแต่การออกแบบสกิลไปจนถึง การจัดโครงสร้าง การทดสอบ และการเผยแพร่
• ครอบคลุมสถานการณ์การใช้งานอย่างกว้าง ตั้งแต่การทำเวิร์กโฟลว์อัตโนมัติแบบเดี่ยวไปจนถึง การเสริมการผสานเครื่องมือบน MCP
• เขียนขึ้นจากแพตเทิร์นและกรณีล้มเหลวที่ผ่านการพิสูจน์แล้วในสภาพแวดล้อมการใช้งานจริง
• หากมีการจัดระเบียบเวิร์กโฟลว์สำคัญ 2–3 รายการไว้แล้ว ก็สามารถสร้างและทดสอบสกิลแรกได้ ภายใน 15–30 นาที

---

Introduction

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

• สถานการณ์ที่ Skills มีประสิทธิภาพเป็นพิเศษ

  • Skills ให้ผลลัพธ์ดีที่สุดกับ งานที่ทำซ้ำได้และมีโครงสร้างชัดเจน
    • สร้างดีไซน์ฟรอนต์เอนด์จากสเปก
    • ทำรีเสิร์ชตามระเบียบวิธีที่สม่ำเสมอ
    • เขียนเอกสารโดยสะท้อนสไตล์ไกด์ของทีม
    • ออร์เคสเตรตกระบวนการซับซ้อนที่มีหลายขั้นตอน
  • ผสานเข้ากับความสามารถในตัวของ Claude ได้อย่างเป็นธรรมชาติ เช่น การรันโค้ดและการสร้างเอกสาร

• การแบ่งบทบาทระหว่าง MCP กับ Skills

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

• วัตถุประสงค์และขอบเขตของคู่มือ

  • เอกสารนี้ครอบคลุมทุกขั้นตอนที่จำเป็นต่อการสร้าง Skills
    • การวางแผนล่วงหน้าและการออกแบบโครงสร้าง
    • วิธีการเขียนจริง
    • การทดสอบและการปรับปรุงแบบวนซ้ำ
    • การเผยแพร่และการแชร์
  • ครอบคลุม ทุกขอบเขตการใช้งาน ตั้งแต่สกิลส่วนตัว สกิลมาตรฐานภายในทีม ไปจนถึงสกิลสำหรับแชร์กับชุมชน
  • เน้น แพตเทิร์นและตัวอย่างที่พิสูจน์แล้วในการทำงานจริง มากกว่าคำอธิบายเชิงทฤษฎี

• ผู้อ่านเป้าหมาย

  • นักพัฒนาที่ต้องการให้ Claude ทำเวิร์กโฟลว์บางอย่าง ด้วยวิธีเดิมเสมอ
  • ผู้ใช้ระดับสูงที่ต้องการทำงานซ้ำๆ ให้เป็นอัตโนมัติ
  • ทีมที่ต้องการทำให้แนวทางการใช้ Claude เป็นมาตรฐานในระดับองค์กร
  • ผู้สร้างที่ต้องการผสานความรู้เวิร์กโฟลว์เข้ากับ MCP connector

• เส้นทางการใช้งานคู่มือ

  • หากเป้าหมายคือการสร้าง Skills แบบเดี่ยว:
    • Fundamentals
    • Planning and Design
    • แนะนำให้อ้างอิงโดยเน้น Category 1–2
  • หากเป้าหมายคือการเสริมการผสาน MCP:
    • ส่วน Skills + MCP
    • แนะนำให้ใช้งานโดยเน้น Category 3
  • ทั้งสองเส้นทางใช้ข้อกำหนดทางเทคนิคบางส่วนร่วมกัน และ เลือกนำไปใช้เฉพาะส่วนที่จำเป็นได้

• ผลลัพธ์ที่คาดหวัง

  • คู่มือนี้ออกแบบมาเพื่อให้สามารถ สร้าง Skill ที่ใช้งานได้จริงหนึ่งรายการให้เสร็จภายในเซสชันเดียว
  • หากมีเวิร์กโฟลว์ที่ชัดเจนอยู่แล้ว 2–3 รายการ ก็สามารถสร้างและทดสอบ Skill แรกได้ ภายในประมาณ 15–30 นาที
  • Introduction ทำหน้าที่ทำให้มุมมองสำคัญที่ทุกบทถัดไปตั้งอยู่บนพื้นฐานเดียวกันชัดเจนขึ้น กล่าวคือ
    “Skills ไม่ใช่พรอมป์ต์ แต่เป็นความรู้งานที่นำกลับมาใช้ซ้ำได้”

Chapter 1: แนวคิดพื้นฐาน (Fundamentals)

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

• Skill คืออะไร

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

• องค์ประกอบพื้นฐานของ Skill

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

• หลักการออกแบบสำคัญ 1: Progressive Disclosure

  • Skills ใช้ โครงสร้างการโหลดข้อมูล 3 ระดับ

  • ระดับที่ 1: YAML frontmatter

    • ถูกโหลดเข้าสู่ system prompt ของ Claude ตลอดเวลา
    • มีเฉพาะข้อมูลขั้นต่ำที่ใช้ตัดสินว่าสกิลควรถูกใช้เมื่อใด
    • ทำหน้าที่ป้องกันการโหลดคอนเท็กซ์ที่ไม่จำเป็น

  • ระดับที่ 2: เนื้อหาหลักของ SKILL.md

    • ถูกโหลดเมื่อ Claude ตัดสินว่าสกิลนั้นเกี่ยวข้อง
    • มีขั้นตอนการทำงานจริงและคำแนะนำ

  • ระดับที่ 3: ไฟล์ที่เชื่อมโยง

    • เช่น references, scripts, assets
    • Claude จะสำรวจเฉพาะเมื่อเห็นว่าจำเป็น
    • รักษาความเชี่ยวชาญไว้พร้อมลดการใช้โทเค็นให้ต่ำที่สุด
  • โครงสร้างนี้ช่วยให้บรรลุ สมดุลระหว่างต้นทุนของคอนเท็กซ์กับความแม่นยำของงาน

• หลักการออกแบบสำคัญ 2: Composability

  • Claude สามารถโหลดหลาย Skills ได้พร้อมกัน
  • ดังนั้น Skill แต่ละตัวจึง:
    • ไม่ควรตั้งสมมติฐานว่าจะทำงานแบบเดี่ยวเสมอไป
    • และควรถูกออกแบบไม่ให้ชนกับ Skill อื่น
  • ถือว่าสภาพแวดล้อมที่สกิลทำงานร่วมกันได้เป็นเงื่อนไขพื้นฐาน

• หลักการออกแบบสำคัญ 3: Portability

  • Skills ถูกออกแบบให้ทำงานเหมือนกันได้ใน Claude.ai, Claude Code และสภาพแวดล้อม API
  • Skill ที่สร้างครั้งเดียวสามารถ นำกลับมาใช้ซ้ำได้โดยไม่ต้องแก้ตามแพลตฟอร์ม
  • อย่างไรก็ตาม สคริปต์หรือการเข้าถึงเครือข่ายอาจถูกจำกัดโดยสภาพแวดล้อมการรัน

• ความสัมพันธ์ระหว่าง MCP กับ Skills

  • เมื่อใช้ MCP Skills จะทำหน้าที่เป็น ชั้นความรู้ (knowledge layer)
  • MCP ให้การเข้าถึงเครื่องมือและข้อมูล
  • ส่วน Skills นิยามว่าเครื่องมือเหล่านั้น ควรถูกใช้อย่างไร

  • อุปมาห้องครัว

    • MCP: ห้องครัว วัตถุดิบ และเครื่องมือทำอาหาร
    • Skills: สูตรอาหาร
    • เมื่อรวมกัน ผู้ใช้ไม่จำเป็นต้องออกแบบกระบวนการซับซ้อนด้วยตนเอง

• ในกรณีที่ใช้โดยไม่มี MCP

  • แม้ไม่มี MCP Skills ก็ยังมีประโยชน์อย่างมาก
  • เพียงใช้ความสามารถในตัวของ Claude เช่น การสร้างเอกสารและการรันโค้ด ก็สามารถ:
    • ทำให้งานที่ทำซ้ำเป็นมาตรฐาน
    • รักษาคุณภาพให้สม่ำเสมอ
    • ปรับปรุงความเร็วในการทำงานได้

• ข้อความสำคัญของบทนี้

• Skills ไม่ใช่การปรับพรอมป์ต์ระยะสั้น แต่เป็น ทรัพยากรงานที่สะสมอย่างต่อเนื่อง
• แก่นสำคัญไม่ใช่ “ทำอะไรได้บ้าง” แต่คือ “การตรึงวิธีการทำงานให้แน่นอน”
• บทถัดไปจะขยายจากแนวคิดนี้ไปสู่ขั้นตอนการออกแบบและการปฏิบัติงานจริง

บทที่ 2: การวางแผนและการออกแบบ (Planning and Design)

• บทนี้ตั้งอยู่บนสมมติฐานว่าความสำเร็จหรือความล้มเหลวของการสร้าง Skills นั้นแทบจะถูกกำหนดไว้แล้วจาก คุณภาพของการออกแบบก่อนเข้าสู่ขั้นตอนการเขียน

• ก่อนลงมือทำด้านเทคนิค ต้องทำให้ชัดเจนก่อนว่าจะแก้ปัญหาอะไร และจะกำหนดโฟลว์แบบใดให้ตายตัว

• Skill ที่ออกแบบมาดีจะทำให้การพัฒนาง่ายขึ้น และลดต้นทุนในการทดสอบกับการบำรุงรักษาลงได้มาก

• จุดเริ่มต้น: การกำหนดกรณีการใช้งาน

  • ก่อนเขียนสกิล ต้องกำหนด กรณีการใช้งาน (use case) ที่เป็นรูปธรรม 2~3 กรณี ให้ชัดเจน
  • กรณีการใช้งานต้องไม่ใช่เพียงเป้าหมายเชิงนามธรรม แต่ต้องรวมถึงประโยคที่ผู้ใช้จะพูดจริงและผลลัพธ์ที่จะได้ด้วย

  • องค์ประกอบของกรณีการใช้งานที่ดี

    • เป้าหมายที่ผู้ใช้ต้องการบรรลุ
    • ประโยคกระตุ้นที่ผู้ใช้น่าจะพูด
    • งานแบบเป็นลำดับขั้นที่ต้องดำเนินการภายใน
    • เครื่องมือที่ใช้ (ฟังก์ชันพื้นฐานของ Claude หรือ MCP)
    • สถานะผลลัพธ์สุดท้าย
  • ผ่านตัวอย่าง บทนี้เน้นย้ำว่าการนิยามแบบที่มี เงื่อนไขเริ่มต้น–ขั้นตอนประมวลผล–สถานะเสร็จสมบูรณ์ ชัดเจน เช่น “การวางแผนสปรินต์” เป็นสิ่งสำคัญ

• คำถามสำคัญที่ต้องถามตัวเองก่อนออกแบบ

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

• ประเภทกรณีการใช้งาน Skill หลักที่พบ

  • Category 1: การสร้างเอกสารและแอสเซ็ต

    • ใช้สำหรับสร้างผลลัพธ์ที่ต้องการคุณภาพสม่ำเสมอ
    • ครอบคลุมเอกสาร พรีเซนเทชัน งานออกแบบ โค้ด และผลลัพธ์ด้าน UI
    • ลักษณะเด่น:
      • ฝังคู่มือสไตล์และกฎของแบรนด์ไว้ภายใน
      • ใช้เทมเพลตเอาต์พุต
      • มีเช็กลิสต์ตรวจสอบคุณภาพขั้นสุดท้าย
    • สามารถทำงานให้จบได้ด้วยฟังก์ชันพื้นฐานของ Claude โดยไม่ต้องใช้เครื่องมือภายนอก

  • Category 2: ระบบอัตโนมัติของเวิร์กโฟลว์

    • เหมาะกับกระบวนการที่ต้องทำหลายขั้นตอนซ้ำ ๆ
    • ตัวอย่าง: skill-creator
    • ลักษณะเด่น:
      • มีความคืบหน้าแบบเป็นขั้นตอนและจุดตรวจสอบความถูกต้อง
      • มีเทมเพลตแบบมีโครงสร้างให้
      • ฝังลูปการรีวิวระหว่างทางและการปรับปรุงไว้
    • อธิบายว่าเป็นประเภทที่ให้ความสำคัญกับ เสถียรภาพของกระบวนการ มากกว่าผลลัพธ์

  • Category 3: การเสริมพลังด้วย MCP

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

• ความสำคัญของการกำหนดเกณฑ์ความสำเร็จ

  • Skill ต้องถูกประเมินไม่ใช่แค่ว่า “ดูเหมือนจะทำงานได้ดี” แต่ต้องดูว่า ช่วยให้ดีขึ้นจริงหรือไม่
  • เกณฑ์ความสำเร็จไม่ได้อยู่ในรูปตัวเลขที่แม่นยำเสมอไป แต่เสนอเป็น เกณฑ์ที่มีทิศทางชัดเจน

  • เกณฑ์เชิงปริมาณ

    • ทริกเกอร์ได้อัตโนมัติในคำขอส่วนใหญ่ที่ตั้งใจรองรับ
    • เมื่อใช้สกิล จำนวนการเรียกเครื่องมือและปริมาณการใช้โทเค็นลดลง
    • เวิร์กโฟลว์เสร็จสมบูรณ์โดยไม่มีการเรียก MCP ล้มเหลว

  • เกณฑ์เชิงคุณภาพ

    • ดำเนินต่อไปได้แม้ผู้ใช้จะไม่ได้สั่งขั้นตอนถัดไป
    • เมื่อรันซ้ำ โครงสร้างและคุณภาพของผลลัพธ์ยังคงสม่ำเสมอ
    • แม้เป็นผู้ใช้ใหม่ก็มีโอกาสสำเร็จได้ตั้งแต่ครั้งแรก
  • ยอมรับว่าการประเมินอาจมี การตัดสินจากความรู้สึก (vibes) อยู่บ้าง แต่ก็ระบุว่าต้องคงเกณฑ์เปรียบเทียบไว้

• ภาพรวมข้อกำหนดทางเทคนิค

  • Skill ต้องเป็นไปตามโครงสร้างไดเรกทอรีแบบตายตัว
  • ไฟล์ SKILL.md เป็นสิ่งจำเป็น และชื่อต้องตรงกันอย่างแม่นยำ
  • ชื่อโฟลเดอร์และฟิลด์ name ต้องใช้ kebab-case
  • ไม่วาง README.md ไว้ภายในโฟลเดอร์ Skill

• บทบาทของ YAML frontmatter

  • frontmatter เป็นสัญญาณหลักที่ Claude ใช้ในการตัดสินใจว่า ควรโหลดสกิลเมื่อใด
  • ฟิลด์ขั้นต่ำที่จำเป็น:
    • name
    • description
  • description ต้องมีสิ่งต่อไปนี้เสมอ:
    • สกิลนี้ทำอะไร
    • ควรใช้เมื่อใด
    • ตัวอย่างสำนวนที่เป็นรูปธรรมที่ผู้ใช้น่าจะพูด
  • สิ่งสำคัญคือ ภาษาจากมุมมองของผู้ใช้ มากกว่าคำอธิบายเชิงเทคนิค

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

  • ควรรักษาความยาวไม่เกิน 1024 ตัวอักษร
  • ห้ามใช้แท็ก XML
  • ด้วยเหตุผลด้านความปลอดภัย จึงมีการจำกัดการใช้ชื่อบางชื่อ (claude, anthropic)
  • metadata เป็นตัวเลือก แต่แนะนำให้ใส่ข้อมูลเวอร์ชันและผู้เขียน

• แนวทางการออกแบบเนื้อหาใน SKILL.md

  • ให้คำสั่งที่ชัดเจนและนำไปปฏิบัติได้แบบเป็นขั้นตอน
  • แสดงตัวอย่างพร้อมผลลัพธ์ที่คาดหวัง
  • รวมข้อผิดพลาดที่พบบ่อยและวิธีแก้ไข
  • คำอธิบายที่ยาวเกินไปให้แยกไปไว้ในไดเรกทอรี references

• แก่นของบทที่ 2 คือ Skills ไม่ควรถูกมองเป็นเพียง “ชุดพรอมป์ต์” แต่ต้องมองเป็น ผลลัพธ์ของการออกแบบเวิร์กโฟลว์ที่มีเจตนา

บทที่ 3: การทดสอบและการปรับปรุงซ้ำ (Testing and Iteration)

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

• การเลือกระดับการทดสอบ

  • การทดสอบ Skills สามารถทำได้หลายระดับตามคุณภาพที่ต้องการและขอบเขตการนำไปใช้งาน

  • การทดสอบด้วยตนเอง (Claude.ai)

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

  • การทดสอบแบบใช้สคริปต์ (Claude Code)

    • ทำให้เคสทดสอบเป็นอัตโนมัติในสภาพแวดล้อม Claude Code
    • มีประโยชน์สำหรับ การทดสอบถดถอย เมื่อมีการสะสมของการเปลี่ยนแปลง
    • เหมาะกับสกิลที่ใช้ภายในทีม

  • การทดสอบโปรแกรมผ่าน API

    • ใช้ Skills API เพื่อรันชุดทดสอบที่กำหนดไว้อัตโนมัติ
    • เปรียบเทียบเชิงปริมาณและตรวจสอบอย่างเป็นระบบได้
    • เหมาะกับการใช้งานในวงกว้างและสภาพแวดล้อมระดับองค์กร
• สกิลภายในขนาดเล็กกับสกิลที่เผยแพร่สู่ภายนอก ไม่จำเป็นต้องใช้มาตรฐานการทดสอบเดียวกัน

• แนวทางที่แนะนำ: เริ่มจากงานยากเพียงงานเดียว

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

• ขอบเขตการทดสอบหลัก

  • 1. การทดสอบทริกเกอร์

    • วัตถุประสงค์: ตรวจสอบว่าสกิล ถูกโหลดอัตโนมัติเฉพาะในสถานการณ์ที่เหมาะสมหรือไม่
    • รายการที่รวมอยู่:
      • ถูกทริกเกอร์เมื่อเป็นคำขอที่ชัดเจน
      • ถูกทริกเกอร์แม้คำขอจะเปลี่ยนรูปแบบการแสดงออก
      • ไม่ถูกโหลดเมื่อเป็นคำขอที่ไม่เกี่ยวข้อง
    • คุณภาพของทริกเกอร์เชื่อมโยงโดยตรงกับการออกแบบฟิลด์ description

  • 2. การทดสอบฟังก์ชัน

    • วัตถุประสงค์: ตรวจสอบว่าสกิล สร้างผลลัพธ์ที่ตั้งใจไว้อย่างถูกต้องหรือไม่
    • สิ่งที่ต้องตรวจสอบ:
      • ความถูกต้องของผลลัพธ์ที่ส่งออก
      • การเรียก MCP สำเร็จหรือไม่
      • พฤติกรรมการจัดการข้อผิดพลาด
      • การรับมือกับ edge case
    • ไม่ได้ประเมินแค่ความสำเร็จแบบง่าย ๆ แต่พิจารณาจาก ความสมบูรณ์ของเวิร์กโฟลว์ทั้งหมด

  • 3. การทดสอบเปรียบเทียบประสิทธิภาพ

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

• การทดสอบและปรับปรุงด้วย skill-creator

  • skill-creator เป็นเครื่องมือเมตาสำหรับช่วยออกแบบและปรับปรุงสกิล
  • ความสามารถหลัก:
    • สร้างร่างสกิลจากคำอธิบายภาษาธรรมชาติ
    • สร้างรูปแบบ SKILL.md และ frontmatter อัตโนมัติ
    • ตรวจจับความเสี่ยงจากการทริกเกอร์มากเกินไปหรือน้อยเกินไป
    • เสนอเคสทดสอบที่เหมาะกับวัตถุประสงค์
  • แต่ไม่สามารถทดแทนการทดสอบการทำงานจริงหรือการประเมินเชิงปริมาณได้

• การปรับปรุงซ้ำโดยอิงจากฟีดแบ็ก

  • Skills ไม่ใช่ผลลัพธ์ที่ตายตัว แต่เป็น สิ่งที่ต้องขัดเกลาอย่างต่อเนื่อง

  • สัญญาณว่าทริกเกอร์น้อยเกินไป

    • สกิลไม่ถูกโหลดอัตโนมัติ
    • ผู้ใช้เปิดสกิลด้วยตนเอง
    • มีคำถามว่า “สิ่งนี้ควรใช้เมื่อไร”
    • วิธีแก้: เพิ่ม สำนวนและคำศัพท์ที่เฉพาะเจาะจง ใน description

  • สัญญาณว่าทริกเกอร์มากเกินไป

    • สกิลถูกโหลดแม้ในคำถามที่ไม่เกี่ยวข้อง
    • เกิดกรณีที่ผู้ใช้ปิดสกิล
    • เกิดความสับสนเรื่องวัตถุประสงค์
    • วิธีแก้: ลดขอบเขต เพิ่ม negative trigger

  • สัญญาณของปัญหาระหว่างการทำงาน

    • ผลลัพธ์ขาดความสม่ำเสมอ
    • เกิดข้อผิดพลาด MCP หรือมีการลองใหม่
    • จำเป็นต้องให้ผู้ใช้เข้ามาแก้ไข
    • วิธีแก้: ทำคำสั่งให้ชัดเจนขึ้น เสริมความแข็งแรงของการจัดการข้อผิดพลาด

• ข้อความสำคัญของช่วงการทดสอบ

  • การทดสอบคือกระบวนการตรวจสอบไม่ใช่แค่ ความถูกต้องของสกิล แต่รวมถึงความน่าเชื่อถือด้วย
  • เกณฑ์ว่า “สกิลรันได้” อย่างเดียวไม่เพียงพอ
  • เกณฑ์ตัดสินสุดท้ายคือ “ผู้ใช้ไม่ต้องออกคำสั่งถัดไปเพิ่มเติมแล้วมันทำงานจนจบได้หรือไม่”
• บทที่ 3 คือขั้นตอนที่เปลี่ยน Skills จากเครื่องมือเชิงทดลองให้กลายเป็น ทรัพย์สินเวิร์กโฟลว์ที่พร้อมใช้งานจริง

บทที่ 4: การเผยแพร่และการแชร์ (Distribution and Sharing)

• Skills คือองค์ประกอบที่ทำให้คุณค่าของ MCP connector สมบูรณ์ขึ้น โดยแม้จะเป็นการเชื่อมต่อเครื่องมือแบบเดียวกัน แต่หาก มาพร้อมสกิลก็จะเข้าถึงคุณค่าได้เร็วกว่า
• ในมุมมองของผู้ใช้ มีแนวโน้มที่จะชอบ connector ที่มีเวิร์กโฟลว์พร้อมใช้งานได้ทันที มากกว่า connector ที่มีเพียง MCP อย่างเดียว
• บทนี้สรุปวิธีการเผยแพร่ ณ เดือนมกราคม 2026 การเผยแพร่ในระดับองค์กร การใช้ API และกลยุทธ์การดำเนินงานที่แนะนำ

• โมเดลการเผยแพร่ปัจจุบัน (ณ เดือนมกราคม 2026)

  • วิธีการเผยแพร่สำหรับผู้ใช้รายบุคคล

    • ดาวน์โหลดโฟลเดอร์ Skill ลงในเครื่อง
    • หากจำเป็น ให้บีบอัดทั้งโฟลเดอร์เป็นไฟล์ zip
    • อัปโหลดใน Claude.ai ที่ Settings → Capabilities → Skills
    • หรือวางโดยตรงในไดเรกทอรี skills ของสภาพแวดล้อม Claude Code
    • หลังอัปโหลดแล้ว ผู้ใช้ต้องเปิดใช้งานสกิลด้วยตนเอง

  • การเผยแพร่ในระดับองค์กร

    • ผู้ดูแลระบบสามารถเผยแพร่สกิลให้ทั้งเวิร์กสเปซได้
    • รองรับฟังก์ชันการเผยแพร่ในระดับองค์กรตั้งแต่วันที่ 18 ธันวาคม 2025
    • รองรับการจัดการแบบรวมศูนย์และการอัปเดตอัตโนมัติ
    • เหมาะสำหรับการบังคับใช้หรือคงไว้ซึ่งเวิร์กโฟลว์มาตรฐานภายในองค์กรอย่างสม่ำเสมอ

• Skills ในฐานะโอเพนสแตนดาร์ด

  • Agent Skills ถูกเปิดเผยเป็น โอเพนสแตนดาร์ด เช่นเดียวกับ MCP
  • เป้าหมายคือไม่ผูกติดกับแพลตฟอร์มใดแพลตฟอร์มหนึ่ง และให้สกิลเดียวกันทำงานได้ในเครื่องมือ AI หลายตัว
  • บางสกิลอาจใช้ความสามารถเฉพาะของแพลตฟอร์มอย่างเต็มที่ ซึ่งในกรณีนี้สามารถระบุข้อจำกัดของสภาพแวดล้อมไว้ในฟิลด์ compatibility ได้
  • กำลังพัฒนามาตรฐานนี้ร่วมกับผู้เข้าร่วมในอีโคซิสเต็ม

• การใช้งาน Skills ผ่าน API

  • วัตถุประสงค์ของการใช้ API

    • เหมาะกับ กรณีการใช้งานแบบโปรแกรม เช่น แอปพลิเคชัน ออโตเมชันไปป์ไลน์ และระบบเอเจนต์
    • สามารถควบคุมสกิลได้ในระดับระบบ ไม่ใช่การใช้งานแบบแมนนวลผ่าน UI

  • ความสามารถหลัก

    • ดูรายการและจัดการสกิลผ่านเอนด์พอยต์ /v1/skills
    • ระบุสกิลด้วยพารามิเตอร์ container.skills เมื่อส่งคำขอไปยัง Messages API
    • จัดการเวอร์ชันและควบคุมการเผยแพร่ผ่าน Claude Console
    • ผสานการทำงานกับ Claude Agent SDK เพื่อสร้างเอเจนต์แบบคัสตอมได้

  • แนวทางเลือกสภาพแวดล้อมการใช้งาน

    • Claude.ai / Claude Code:
      • ใช้งานโดยผู้ใช้ปลายทางโดยตรง
      • ทดสอบแบบแมนนวลระหว่างพัฒนาและวนรอบได้อย่างรวดเร็ว
      • เวิร์กโฟลว์แบบรายบุคคลและไม่สม่ำเสมอ
    • API:
      • ฝังในแอปพลิเคชัน
      • การเผยแพร่สู่โปรดักชันในวงกว้าง
      • เอเจนต์และไปป์ไลน์แบบอัตโนมัติ

  • ข้อควรระวัง

    • การใช้ Skills ผ่าน API ต้องใช้ Code Execution Tool เวอร์ชันเบตา
    • โดยตั้งอยู่บนสมมติฐานว่ามีสภาพแวดล้อมการรันที่ปลอดภัย

• กลยุทธ์การเผยแพร่ที่แนะนำ

  • 1. ดูแลที่เก็บสาธารณะบน GitHub

    • จัดการตัวสกิลเป็นหนึ่งโฟลเดอร์
    • ที่รากของที่เก็บควรมี README สำหรับคนอ่าน
    • แนะนำให้ใส่วิธีติดตั้ง วัตถุประสงค์การใช้งาน และภาพหน้าจอตัวอย่าง
    • ภายในโฟลเดอร์ Skill ไม่ควรมี README.md

  • 2. เชื่อมโยงกับเอกสาร MCP

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

  • 3. จัดทำคู่มือการติดตั้ง

    • ระบุวิธีดาวน์โหลดสกิล
    • อธิบายขั้นตอนการติดตั้งใน Claude.ai หรือ Claude Code แบบทีละขั้น
    • รวมขั้นตอนตรวจสอบการเชื่อมต่อกับเซิร์ฟเวอร์ MCP
    • ให้ตัวอย่างพรอมป์ทดสอบแบบง่าย

• หลักการวางตำแหน่งของสกิล

  • อธิบายโดยยึดผลลัพธ์มากกว่าฟังก์ชัน

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

  • การผสาน MCP + Skills เป็นสิ่งสำคัญ

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

Chapter 5: แพตเทิร์นและการแก้ปัญหา (Patterns and Troubleshooting)

• บทนี้สรุปทั้ง แพตเทิร์นการออกแบบที่พิสูจน์แล้วว่าได้ผลซ้ำๆ จากผู้ใช้ Skills ระยะแรกและกรณีศึกษาของทีมภายใน รวมถึงวิธีแก้ปัญหาที่พบบ่อยระหว่างการใช้งานจริง
• แพตเทิร์นที่นำเสนอไม่ใช่กฎตายตัว แต่เป็น ชุดของแนวทางที่ผ่านการพิสูจน์แล้ว โดยมีข้อสมมติฐานว่าสามารถเลือกและผสมใช้ให้เหมาะกับเป้าหมายของแต่ละสกิล
• ข้อความสำคัญคือ ไม่ใช่แค่ “การเชื่อมต่อเครื่องมือ” แต่คือ การออกแบบลำดับการแก้ปัญหา

• การเลือกแนวทาง: ยึดปัญหาเป็นศูนย์กลาง vs ยึดเครื่องมือเป็นศูนย์กลาง

  • ในการออกแบบ Skills สิ่งสำคัญคือการเลือกมุมมองหลักจากหนึ่งในสองแบบนี้

  • ยึดปัญหาเป็นศูนย์กลาง (Problem-first)

    • ผู้ใช้บอกถึง ผลลัพธ์ที่ต้องการบรรลุ
    • สกิลจะตัดสินใจเองภายในว่าจะใช้เครื่องมือ MCP ใดและเรียกตามลำดับอย่างไร
    • ตัวอย่าง: “ช่วยสร้าง project workspace ให้หน่อย” → สกิลจัดการการเรียกเครื่องมือทั้งหมด
    • เหมาะกับประสบการณ์แบบมุ่งผลลัพธ์

  • ยึดเครื่องมือเป็นศูนย์กลาง (Tool-first)

    • ผู้ใช้รู้การเชื่อมต่อ MCP อยู่แล้ว
    • สกิลทำหน้าที่ให้ ความรู้เฉพาะทางเกี่ยวกับวิธีใช้เครื่องมือนั้นให้มีประสิทธิภาพ
    • ตัวอย่าง: วิธีใช้ Notion MCP, คำแนะนำ workflow ที่เหมาะสมที่สุด
    • เหมาะกับผู้ใช้ระดับเชี่ยวชาญและคู่มือเครื่องมือภายใน
• สกิลส่วนใหญ่มักเอนเอียงไปด้านใดด้านหนึ่งมากกว่า และการตระหนักเรื่องนี้อย่างชัดเจนจะส่งผลโดยตรงต่อคุณภาพการออกแบบ

• แพตเทิร์น 1: การ orchestration ของ workflow แบบลำดับขั้น

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

• แพตเทิร์น 2: การทำงานร่วมกันของหลาย MCP

  • ใช้เมื่อจำเป็นต้อง ใช้หลายบริการ (MCP) ต่อเนื่องกัน เพื่อให้ได้ผลลัพธ์หนึ่งเดียว
  • แยก MCP เป็นรายขั้นตอน และกำหนด flow การส่งต่อข้อมูลให้ชัดเจน
  • ต้องมีการตรวจสอบก่อนขยับไปขั้นถัดไป
  • เหมาะกับ workflow แบบซับซ้อน เช่น ออกแบบ → บันทึก → สร้าง task → แจ้งเตือน

• แพตเทิร์น 3: การปรับปรุงแบบวนซ้ำ (Iterative Refinement)

  • เหมาะกับงานที่ คุณภาพดีขึ้นอย่างมากผ่านการทำซ้ำ มากกว่าผลลัพธ์ตั้งต้น
  • ออกแบบลูปแบบชัดเจน: สร้างร่าง → ตรวจสอบ → แก้ไข → ตรวจสอบซ้ำ
  • ต้องกำหนดเกณฑ์คุณภาพและเงื่อนไขจบการวนซ้ำให้ชัดเจน
  • มีประสิทธิภาพกับการสร้างรายงานและงานปรับปรุงคุณภาพเอกสาร

• แพตเทิร์น 4: การเลือกเครื่องมือโดยอิงการรับรู้บริบท

  • ใช้เมื่อแม้เป้าหมายจะเหมือนกัน แต่ เครื่องมือที่เหมาะสมที่สุดอาจต่างกันตามสถานการณ์
  • ต้องมีเกณฑ์ตัดสินที่ชัดเจน เช่น ขนาดไฟล์ ประเภทไฟล์ หรือการทำงานร่วมกัน
  • อธิบายเหตุผลของการเลือกให้ผู้ใช้เข้าใจเพื่อสร้างความน่าเชื่อถือ
  • เหมาะกับ workflow ด้าน storage, การจัดการเอกสาร และการจัดเก็บโค้ด

• แพตเทิร์น 5: ฝังความฉลาดเฉพาะโดเมน

  • เป็นสกิลที่ไม่ได้หยุดแค่การเรียกใช้เครื่องมือ แต่ ฝังความรู้เฉพาะทางและกฎต่างๆ ไว้ภายใน
  • ขั้นตอนการตัดสินใจและการตรวจสอบก่อนลงมือทำคือหัวใจสำคัญ
  • บันทึกทุกกระบวนการตัดสินใจเพื่อให้ตรวจสอบย้อนหลังได้
  • เหมาะกับโดเมนความเสี่ยงสูง เช่น การเงิน compliance และความปลอดภัย

• คู่มือการแก้ปัญหา

  • อัปโหลดล้มเหลว

    • มักเกิดเมื่อชื่อไฟล์ SKILL.md ไม่ถูกต้องตรงตามกำหนด
    • อาจเกิดจากข้อผิดพลาดด้านรูปแบบ เช่น ไม่มีตัวคั่น YAML (---) หรือปิดเครื่องหมายอัญประกาศไม่ครบ
    • หากฟิลด์ name มีตัวพิมพ์ใหญ่หรือมีช่องว่าง ระบบจะปฏิเสธการอัปโหลด

  • กรณีที่สกิลไม่ถูก trigger

    • เกิดเมื่อ description นามธรรมเกินไป หรือไม่สะท้อนถ้อยคำที่ผู้ใช้ใช้จริง
    • ควรปรับให้มีวลีที่ผู้ใช้จริงน่าจะพูด
    • สามารถดีบักได้โดยถาม Claude ว่า “สกิลนี้ใช้เมื่อไร”

  • กรณีที่สกิลถูก trigger มากเกินไป

    • สาเหตุคือ description มีขอบเขตกว้างเกินไป
    • เพิ่ม negative trigger (Do NOT use when…)
    • แยกให้ชัดเจนระหว่างสิ่งที่ต้องประมวลผลกับสิ่งที่ต้องยกเว้น

  • การเรียก MCP ล้มเหลว

    • ตรวจสอบสถานะการเชื่อมต่อของเซิร์ฟเวอร์ MCP
    • ตรวจสอบข้อมูลยืนยันตัวตน (API key, OAuth token)
    • แยกหาสาเหตุของปัญหาโดยลองเรียก MCP โดยตรงโดยไม่ผ่านสกิล
    • ตรวจสอบความถูกต้องของตัวพิมพ์เล็ก-ใหญ่ในชื่อเครื่องมือ

  • กรณีที่ระบบไม่ปฏิบัติตามคำสั่งได้ดี

    • อาจเกิดจากคำสั่งยาวเกินไปหรือประเด็นสำคัญถูกกลบ
    • ควรวางเงื่อนไขสำคัญไว้ด้านบนและย้ำซ้ำ
    • ใช้ รายการเงื่อนไขที่ตรวจสอบได้ แทนถ้อยคำกำกวม
    • การทำ validation สำคัญด้วยสคริปต์มักเสถียรกว่า

  • ประสิทธิภาพลดลงจาก context ขนาดใหญ่

    • มักเกิดเมื่อ SKILL.md มีขนาดใหญ่เกินไป
    • ควรแยกเอกสารรายละเอียดออกไปไว้ใน references
    • หากมีสกิลที่เปิดใช้งานพร้อมกันมากเกินไป แนะนำให้ลดจำนวนลง
    • การเปิดใช้งานสกิลพร้อมกันมากกว่า 20~50 รายการอาจทำให้ประสิทธิภาพลดลง
• “สกิลไม่ใช่ artefact ที่สร้างครั้งเดียวแล้วจบ แต่เป็น สิ่งที่ต้องดูแลในการใช้งานจริงและค่อยๆ เติบโตผ่านการเลือกแพตเทิร์นและการปรับปรุงแบบวนซ้ำ”

[kaydash]

Anthropic เจ๋งที่สุดจริง ๆ

[pluto]

ของจริง