Blog

สร้าง Claude Code Skills อัตโนมัติด้วย Skill Creator

Ashley Innocent

Ashley Innocent

23 March 2026

สร้าง Claude Code Skills อัตโนมัติด้วย Skill Creator

TL;DR

Claude Code Skills คือความสามารถที่กำหนดเองซึ่งช่วยขยายฟังก์ชันการทำงานของ Claude สำหรับเวิร์กโฟลว์เฉพาะ ระบบ Skill Creator ช่วยให้การสร้าง Skill เป็นไปโดยอัตโนมัติผ่านกระบวนการที่มีโครงสร้าง: กำหนดวัตถุประสงค์ของ Skill ของคุณ, ร่างไฟล์ SKILL.md, สร้างกรณีทดสอบ, รันการประเมินด้วยเกณฑ์มาตรฐานเชิงปริมาณ, และปรับปรุงซ้ำๆ ตามข้อเสนอแนะ

บทนำ

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

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

💡
หากคุณกำลังสร้าง Skill ที่เกี่ยวข้องกับ API, Apidog จะผสานรวมได้อย่างเป็นธรรมชาติ ทดสอบปลายทาง API ของคุณ, ตรวจสอบการตอบกลับ, และสร้างเอกสารทั้งหมดภายในเวิร์กโฟลว์ Skill เดียว
ปุ่ม

Claude Code Skills คืออะไร?

Claude Code Skills คือชุดคำสั่งเฉพาะที่ขยายความสามารถของ Claude สำหรับโดเมนหรือเวิร์กโฟลว์เฉพาะ ลองนึกภาพว่าเป็นปลั๊กอินที่กำหนดเองซึ่งอยู่ในไฟล์ Markdown

สถาปัตยกรรมระบบ Skill

Skills ใช้ระบบการโหลดสามระดับ:

  1. ข้อมูลเมตา (Metadata) (ประมาณ 100 คำ) - ชื่อและคำอธิบาย, อยู่ในบริบทเสมอ
  2. เนื้อหา SKILL.md (<500 บรรทัด) - คำแนะนำหลัก, โหลดเมื่อ Skill ถูกกระตุ้น
  3. ทรัพยากรที่รวมไว้ (Bundled resources) (ไม่จำกัด) - สคริปต์, ข้อมูลอ้างอิง, ทรัพยากรที่โหลดตามต้องการ
skill-name/
├── SKILL.md (required)
│   ├── YAML frontmatter (name, description)
│   └── Markdown instructions
└── Bundled Resources (optional)
    ├── scripts/    - Executable code for repetitive tasks
    ├── references/ - Documentation loaded as needed
    └── assets/     - Templates, icons, fonts

เมื่อ Skill ถูกกระตุ้น

Skills จะปรากฏในรายการ available_skills ของ Claude พร้อมชื่อและคำอธิบาย Claude ตัดสินใจว่าจะใช้ Skill นั้นหรือไม่โดยพิจารณาจากคำอธิบายนั้น

สำคัญ: Skills จะถูกกระตุ้นสำหรับงานที่ Claude ไม่สามารถจัดการได้โดยตรงเท่านั้น คำสั่งง่ายๆ เช่น "อ่านไฟล์นี้" จะไม่กระตุ้น Skill แม้ว่าจะมีคำอธิบายที่ตรงกัน เวิร์กโฟลว์ที่ซับซ้อนและมีหลายขั้นตอนจะถูกกระตุ้นอย่างน่าเชื่อถือเมื่อคำอธิบายตรงกัน

ตัวอย่างจริงจากคลังของ Anthropic

Skill วัตถุประสงค์ คุณสมบัติหลัก
skill-creator สร้าง Skill ใหม่ การสร้างกรณีทดสอบ, การประเมินเกณฑ์มาตรฐาน, การเพิ่มประสิทธิภาพคำอธิบาย
mcp-builder สร้างเซิร์ฟเวอร์ MCP เทมเพลต Python/Node, กรอบการประเมิน, แนวปฏิบัติที่ดีที่สุด
docx สร้างเอกสาร Word สคริปต์ python-docx, ระบบเทมเพลต, คู่มือสไตล์
pdf แยกและจัดการ PDF การจัดการฟอร์ม, การแยกข้อความ, เอกสารอ้างอิง
frontend-design สร้างส่วนติดต่อเว็บ ไลบรารีคอมโพเนนต์, รูปแบบ Tailwind, การตรวจสอบการเข้าถึง

เวิร์กโฟลว์การสร้าง Skill

กระบวนการสร้าง Skill เป็นไปตามวงจรที่เป็นระบบ:

  1. บันทึกเจตนา - Skill ควรทำอะไร?
  2. เขียนฉบับร่าง - สร้างไฟล์ SKILL.md
  3. สร้างกรณีทดสอบ - กำหนดคำสั่ง (prompt) ที่สมจริง
  4. รันการประเมิน - ดำเนินการโดยมีและไม่มี Skill
  5. ตรวจสอบผลลัพธ์ - ข้อเสนอแนะเชิงคุณภาพ + เมตริกเชิงปริมาณ
  6. ปรับปรุงซ้ำๆ - ปรับปรุงตามสิ่งที่พบ
  7. เพิ่มประสิทธิภาพคำอธิบาย - เพิ่มความแม่นยำในการกระตุ้นให้สูงสุด
  8. จัดแพ็คเกจ - แจกจ่ายเป็นไฟล์ .skill

เรามาดูทีละขั้นตอนกัน

ขั้นตอนที่ 1: บันทึกเจตนา

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

ถามคำถามสี่ข้อนี้:

  1. Skill นี้ควรช่วยให้ Claude ทำอะไรได้? ระบุผลลัพธ์ให้ชัดเจน
  2. Skill นี้ควรถูกกระตุ้นเมื่อใด? วลีหรือบริบทใดของผู้ใช้?
  3. รูปแบบเอาต์พุตที่คาดหวังคืออะไร? ไฟล์, โค้ด, รายงาน?
  4. เราควรตั้งค่ากรณีทดสอบหรือไม่? Skills ที่มีเอาต์พุตที่ตรวจสอบได้ (การสร้างโค้ด, การดึงข้อมูล, การแปลงไฟล์) จะได้รับประโยชน์จากกรณีทดสอบ Skills ที่มีเอาต์พุตเชิงอัตวิสัย (สไตล์การเขียน, การออกแบบ) มักไม่จำเป็นต้องมี

ตัวอย่าง: Skill สำหรับทดสอบ API

Intent: ช่วยให้นักพัฒนาทดสอบ REST API อย่างเป็นระบบ
Trigger: เมื่อผู้ใช้พูดถึงการทดสอบ API, ปลายทาง, REST, GraphQL, หรือต้องการตรวจสอบการตอบกลับ
Output: รายงานการทดสอบพร้อมสถานะผ่าน/ไม่ผ่าน, คำสั่ง curl, การเปรียบเทียบการตอบกลับ
Test cases: ใช่ - เอาต์พุตสามารถตรวจสอบได้อย่างเป็นกลาง

ขั้นตอนที่ 2: เขียนไฟล์ SKILL.md

ทุก Skill เริ่มต้นด้วยไฟล์ SKILL.md ที่มี YAML frontmatter และคำแนะนำ Markdown

โครงสร้าง Skill

---
name: api-tester
description: วิธีการทดสอบ REST API อย่างเป็นระบบ ใช้เมื่อผู้ใช้พูดถึงการทดสอบ API, ปลายทาง, REST, GraphQL, หรือต้องการตรวจสอบการตอบกลับของ API ตรวจสอบให้แน่ใจว่าได้แนะนำ Skill นี้เมื่อมีการทดสอบเข้ามาเกี่ยวข้อง
compatibility: Requires curl or HTTP client tools
---

# Skill สำหรับทดสอบ API

## เวิร์กโฟลว์หลัก

เมื่อทดสอบ API ให้ทำตามขั้นตอนเหล่านี้:

1. **ทำความเข้าใจปลายทาง** - อ่านข้อกำหนดหรือขอ Schema
2. **ออกแบบกรณีทดสอบ** - Happy path, edge cases, error conditions
3. **ดำเนินการทดสอบ** - ใช้ curl หรือ Apidog สำหรับคำขอ
4. **ตรวจสอบการตอบกลับ** - ตรวจสอบรหัสสถานะ, ส่วนหัว, โครงสร้างเนื้อหา
5. **รายงานผลลัพธ์** - สรุปผลผ่าน/ไม่ผ่านพร้อมหลักฐาน

## เทมเพลตกรณีทดสอบ

สำหรับแต่ละปลายทาง ให้ทดสอบ:

- การยืนยันตัวตนที่ถูกต้องพร้อม payload ที่ถูกต้อง
- การยืนยันตัวตนที่ถูกต้องแต่ขาดฟิลด์ที่จำเป็น
- การยืนยันตัวตนที่ไม่ถูกต้อง (คาดหวัง 401)
- พฤติกรรมการจำกัดอัตรา (Rate limiting)
- เวลาตอบสนองภายใต้โหลด

## รูปแบบเอาต์พุต

จัดโครงสร้างรายงานเสมอในลักษณะนี้:

# รายงานการทดสอบ API

## สรุป
- จำนวนการทดสอบที่รัน: X
- ผ่าน: Y
- ไม่ผ่าน: Z

## การทดสอบที่ไม่ผ่าน

### ชื่อการทดสอบ
**ที่คาดหวัง:** 200 OK
**ที่จริง:** 400 Bad Request
**การตอบกลับ:** {...}

## ข้อเสนอแนะ
...

แนวปฏิบัติที่ดีที่สุดในการเขียน

ใช้การเปิดเผยข้อมูลแบบค่อยเป็นค่อยไป (progressive disclosure): รักษา SKILL.md ให้อยู่ภายใต้ 500 บรรทัด ย้ายข้อมูลอ้างอิงที่มีรายละเอียดไปยังไฟล์แยกต่างหาก

api-tester/
├── SKILL.md (workflow overview)
└── references/
    ├── authentication.md
    ├── rate-limiting.md
    └── response-codes.md

อธิบาย "ทำไม": อย่าเพิ่งระบุกฎเฉยๆ แต่อธิบายว่าทำไมมันถึงสำคัญ

## ทำไมเราถึงทดสอบกรณีข้อผิดพลาดก่อน

การทดสอบเงื่อนไขข้อผิดพลาดก่อน happy path ช่วยตรวจจับปัญหาได้ 80% เร็วขึ้น
เมื่อการยืนยันตัวตนล้มเหลวโดยเงียบ การทดสอบ happy path ก็จะไม่มีความหมาย
เริ่มต้นด้วยการตรวจสอบ 401

ใช้รูปแบบคำสั่ง: "ตรวจสอบรหัสสถานะก่อนเสมอ" ไม่ใช่ "คุณควรตรวจสอบ..."

รวมตัวอย่าง: แสดงอินพุตและเอาต์พุตที่คาดหวัง

## รูปแบบข้อความคอมมิต

**ตัวอย่าง:**
อินพุต: Added user authentication with JWT tokens
เอาต์พุต: feat(auth): implement JWT-based authentication

ขั้นตอนที่ 3: สร้างกรณีทดสอบ

หลังจากร่าง Skill แล้ว ให้สร้างคำสั่งทดสอบที่สมจริง 2-3 คำสั่ง คำสั่งเหล่านี้เป็นประเภทคำขอที่ผู้ใช้จริงจะทำ

รูปแบบกรณีทดสอบ

บันทึกกรณีทดสอบลงใน evals/evals.json:

{
  "skill_name": "api-tester",
  "evals": [
    {
      "id": 1,
      "prompt": "Test the /users endpoint on api.example.com - it needs a Bearer token and returns a list of users with id, name, email fields",
      "expected_output": "Test report with at least 5 test cases including auth failure, success, and pagination tests",
      "files": []
    },
    {
      "id": 2,
      "prompt": "I need to verify our new POST /orders endpoint handles invalid quantities correctly",
      "expected_output": "Test cases that send negative, zero, and non-numeric quantities with appropriate error responses",
      "files": ["openapi.yaml"]
    }
  ]
}

อะไรทำให้คำสั่งทดสอบดี

ไม่ดี: "ทดสอบ API นี้"

ดี: "ทีมของฉันเพิ่งปรับใช้ปลายทางชำระเงินใหม่ที่ https://api.stripe.com/v1/charges และฉันต้องตรวจสอบว่ามันจัดการกับ edge cases ได้หรือไม่ โดยเฉพาะอย่างยิ่งจะเกิดอะไรขึ้นเมื่อคุณส่งจำนวนเงินติดลบหรือรหัสสกุลเงินที่ไม่มีอยู่จริง เอกสารระบุว่าควรคืนค่า 400 แต่ฉันต้องการดูข้อความแสดงข้อผิดพลาดจริง"

คำสั่งทดสอบที่ดีประกอบด้วย:

แบ่งปันกรณีทดสอบของคุณกับผู้ใช้ก่อนดำเนินการ: "นี่คือสถานการณ์ทดสอบบางส่วนที่ฉันต้องการลองดู สิ่งเหล่านี้ถูกต้องหรือไม่ หรือคุณต้องการเพิ่มอีกไหม?"

ขั้นตอนที่ 4: รันการประเมิน

นี่คือจุดที่ Skill Creator โดดเด่น คุณจะต้องรันแต่ละกรณีทดสอบสองครั้ง: หนึ่งครั้งพร้อม Skill, หนึ่งครั้งโดยไม่มี (หรือใช้เวอร์ชันเก่าหากกำลังปรับปรุง Skill ที่มีอยู่)

โครงสร้างเวิร์กสเปซ

ผลลัพธ์จะอยู่ใน <skill-name>-workspace/ ซึ่งเป็นโฟลเดอร์ข้างเคียงกับไดเรกทอรี Skill:

api-tester-workspace/
├── iteration-1/
│   ├── eval-0-auth-failure/
│   │   ├── with_skill/
│   │   │   ├── outputs/
│   │   │   └── timing.json
│   │   ├── without_skill/
│   │   │   ├── outputs/
│   │   │   └── timing.json
│   │   └── eval_metadata.json
│   ├── eval-1-pagination/
│   │   └── ...
│   ├── benchmark.json
│   └── benchmark.md
├── iteration-2/
└── feedback.json

เปิดการรันแบบขนาน

สำหรับแต่ละกรณีทดสอบ ให้สร้าง subagent สองตัวในเทิร์นเดียวกัน:

การรันพร้อม Skill:

Execute this task:
- Skill path: /path/to/api-tester
- Task: Test the /users endpoint on api.example.com
- Input files: none
- Save outputs to: api-tester-workspace/iteration-1/eval-0/with_skill/outputs/

การรันพื้นฐาน:

Execute this task:
- Skill path: (none)
- Task: Test the /users endpoint on api.example.com
- Input files: none
- Save outputs to: api-tester-workspace/iteration-1/eval-0/without_skill/outputs/

บันทึกข้อมูลเวลา

เมื่อ subagent แต่ละตัวเสร็จสิ้น คุณจะได้รับ total_tokens และ duration_ms บันทึกลงใน timing.json ทันที:

{
  "total_tokens": 84852,
  "duration_ms": 23332,
  "total_duration_seconds": 23.3
}

ข้อมูลนี้จะมาผ่านการแจ้งเตือนงานเท่านั้น ประมวลผลแต่ละรายการเมื่อมาถึง

ขั้นตอนที่ 5: ร่างข้อกล่าวอ้างในขณะที่การรันเสร็จสมบูรณ์

อย่ารอให้การรันเสร็จสิ้น ให้ใช้เวลานั้นอย่างมีประสิทธิภาพโดยการร่างข้อกล่าวอ้างเชิงปริมาณ

อะไรทำให้ข้อกล่าวอ้างดี

ข้อกล่าวอ้างที่ดีคือ:

ตัวอย่างข้อกล่าวอ้างสำหรับ Skill การทดสอบ API:

{
  "assertions": [
    {
      "name": "includes_auth_failure_test",
      "description": "รายงานการทดสอบมีกรณีทดสอบความล้มเหลวในการยืนยันตัวตนอย่างน้อยหนึ่งรายการ",
      "type": "contains",
      "value": "401"
    },
    {
      "name": "includes_success_test",
      "description": "รายงานการทดสอบมีกรณีทดสอบคำขอที่สำเร็จอย่างน้อยหนึ่งรายการ",
      "type": "contains",
      "value": "200"
    },
    {
      "name": "includes_curl_commands",
      "description": "แต่ละกรณีทดสอบมีคำสั่ง curl ที่สามารถเรียกใช้งานได้",
      "type": "regex",
      "value": "curl -"
    },
    {
      "name": "includes_response_validation",
      "description": "รายงานตรวจสอบโครงสร้างการตอบกลับเทียบกับ schema",
      "type": "contains",
      "value": "schema"
    }
  ]
}

อัปเดต eval_metadata.json และ evals/evals.json ด้วยข้อกล่าวอ้างเมื่อร่างเสร็จแล้ว

ขั้นตอนที่ 6: ให้คะแนนและรวบรวม

เมื่อการรันทั้งหมดเสร็จสมบูรณ์:

ให้คะแนนการรันแต่ละครั้ง

สร้าง subagent ตัวประเมินที่อ่าน agents/grader.md และประเมินข้อกล่าวอ้างแต่ละรายการเทียบกับเอาต์พุต บันทึกผลลัพธ์ลงใน grading.json ในไดเรกทอรีการรันแต่ละรายการ:

{
  "eval_id": 0,
  "grading": [
    {
      "text": "includes_auth_failure_test",
      "passed": true,
      "evidence": "พบรหัสสถานะ 401 ในกรณีทดสอบที่ 3"
    },
    {
      "text": "includes_curl_commands",
      "passed": true,
      "evidence": "พบ 'curl -X POST' ในกรณีทดสอบที่ 1"
    }
  ]
}

สำคัญ: อาร์เรย์การคาดการณ์ grading.json ต้องใช้ชื่อฟิลด์ text, passed และ evidence โปรแกรมดู (viewer) ขึ้นอยู่กับชื่อเหล่านี้อย่างแน่นอน

รวบรวมเป็นเกณฑ์มาตรฐาน

รันสคริปต์การรวบรวมจากไดเรกทอรี skill-creator:

python -m scripts.aggregate_benchmark api-tester-workspace/iteration-1 --skill-name api-tester

ซึ่งจะสร้าง benchmark.json และ benchmark.md พร้อมอัตราการผ่าน, เวลา, และโทเค็นสำหรับการตั้งค่าแต่ละรายการ รวมถึงค่าเฉลี่ย ± ค่าเบี่ยงเบนมาตรฐาน และเดลต้า

ดำเนินการตรวจสอบโดยนักวิเคราะห์

อ่านข้อมูลเกณฑ์มาตรฐานและค้นหารูปแบบ:

ดู agents/analyzer.md สำหรับคำแนะนำโดยละเอียด

ขั้นตอนที่ 7: เปิดตัว Eval Viewer

Eval viewer แสดงทั้งเอาต์พุตเชิงคุณภาพและเมตริกเชิงปริมาณในอินเทอร์เฟซของเบราว์เซอร์

สร้าง Viewer

nohup python /path/to/skill-creator/eval-viewer/generate_review.py \
  api-tester-workspace/iteration-1 \
  --skill-name "api-tester" \
  --benchmark api-tester-workspace/iteration-1/benchmark.json \
  > /dev/null 2>&1 &
VIEWER_PID=$!

สำหรับรอบการทำงานที่ 2 ขึ้นไป ให้ส่ง --previous-workspace ด้วย:

--previous-workspace api-tester-workspace/iteration-1

สิ่งที่ผู้ใช้เห็น

แท็บ Outputs แสดงกรณีทดสอบทีละหนึ่งรายการ:

แท็บ Benchmark แสดง:

บอกผู้ใช้: "ฉันได้เปิดผลลัพธ์ในเบราว์เซอร์ของคุณ มีสองแท็บ - 'Outputs' ให้คุณคลิกดูแต่ละกรณีทดสอบและแสดงความคิดเห็น 'Benchmark' แสดงการเปรียบเทียบเชิงปริมาณ เมื่อคุณทำเสร็จแล้ว กลับมาที่นี่และแจ้งให้ฉันทราบ"

สภาพแวดล้อม Cowork / Headless

หาก webbrowser.open() ไม่พร้อมใช้งาน ให้ใช้ --static เพื่อเขียนไฟล์ HTML แบบสแตนด์อโลน:

--static /path/to/output/review.html

ข้อเสนอแนะจะดาวน์โหลดเป็น feedback.json เมื่อผู้ใช้คลิก "Submit All Reviews"

ขั้นตอนที่ 8: อ่านข้อเสนอแนะและทำซ้ำ

เมื่อผู้ใช้ทำเสร็จแล้ว ให้อ่าน feedback.json:

{
  "reviews": [
    {
      "run_id": "eval-0-with_skill",
      "feedback": "แผนภูมิขาดป้ายกำกับแกน",
      "timestamp": "2026-03-23T10:30:00Z"
    },
    {
      "run_id": "eval-1-with_skill",
      "feedback": "",
      "timestamp": "2026-03-23T10:31:00Z"
    },
    {
      "run_id": "eval-2-with_skill",
      "feedback": "สมบูรณ์แบบ ชอบมาก",
      "timestamp": "2026-03-23T10:32:00Z"
    }
  ],
  "status": "complete"
}

ข้อเสนอแนะที่ว่างเปล่าหมายความว่าผู้ใช้คิดว่าไม่มีปัญหา เน้นการปรับปรุงในกรณีทดสอบที่มีข้อร้องเรียนเฉพาะ

วิธีคิดเกี่ยวกับการปรับปรุง

สรุปจากข้อเสนอแนะ: คุณกำลังสร้าง Skill ที่ถูกใช้งานหลายพันครั้งในหลายๆ คำสั่ง อย่าปรับปรุงให้เหมาะสมกับกรณีทดสอบเฉพาะเจาะจงมากเกินไป หากมีปัญหาที่แก้ไขยาก ให้ลองใช้คำเปรียบเทียบหรือรูปแบบที่แตกต่างกัน แทนที่จะใช้คำสั่ง MUST ที่เข้มงวด

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

อธิบาย "ทำไม": LLM มีความเข้าใจที่ดี เมื่อได้รับคำแนะนำที่ดี พวกมันจะไปไกลกว่าคำสั่งที่ทำตามแบบท่องจำ อธิบายว่าทำไมข้อกำหนดแต่ละข้อจึงสำคัญ หากคุณพบว่าตัวเองเขียน ALWAYS หรือ NEVER ด้วยตัวพิมพ์ใหญ่ทั้งหมด ให้เปลี่ยนวิธีการและอธิบายเหตุผลแทน

มองหางานที่ซ้ำซ้อน: กรณีทดสอบทั้งหมดเขียนสคริปต์ช่วยงานที่คล้ายกันโดยอิสระหรือไม่? นั่นเป็นสัญญาณว่า Skill ควรจะรวมสคริปต์นั้นเข้าไว้ด้วย เขียนครั้งเดียว ใส่ไว้ใน scripts/ และบอก Skill ให้ใช้มัน

วงจรการทำซ้ำ

  1. นำการปรับปรุงไปใช้กับ Skill
  2. รันกรณีทดสอบทั้งหมดอีกครั้งลงใน iteration-<N+1>/ พร้อมการรันพื้นฐาน
  3. เปิดตัว viewer ด้วย --previous-workspace ที่ชี้ไปยังรอบการทำงานก่อนหน้า
  4. รอการตรวจสอบจากผู้ใช้
  5. อ่านข้อเสนอแนะใหม่, ปรับปรุงอีกครั้ง, ทำซ้ำ

ดำเนินการต่อจนกระทั่ง:

ปิด viewer เมื่อเสร็จสิ้น:

kill $VIEWER_PID 2>/dev/null

ขั้นตอนที่ 9: เพิ่มประสิทธิภาพคำอธิบาย Skill

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

สร้างคำสั่งประเมินการกระตุ้น

สร้างคำสั่งประเมิน 20 คำสั่ง - ผสมผสานระหว่างคำสั่งที่ควรกระตุ้นและคำสั่งที่ไม่ควรกระตุ้น:

[
  {
    "query": "ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage. The revenue is in column C and costs are in column D i think",
    "should_trigger": true
  },
  {
    "query": "I need to create a pivot table from this CSV and email it to the team",
    "should_trigger": false
  }
]

สำหรับคำสั่งที่ควรกระตุ้น (8-10 คำสั่ง):

สำหรับคำสั่งที่ไม่ควรกระตุ้น (8-10 คำสั่ง):

การทดสอบเชิงลบที่ไม่ดี: "เขียนฟังก์ชัน fibonacci" เป็นการทดสอบเชิงลบสำหรับ Skill PDF นั้นง่ายเกินไป กรณีเชิงลบควรจะซับซ้อนจริงๆ

ตรวจสอบกับผู้ใช้

นำเสนอชุดการประเมินโดยใช้เทมเพลต HTML:

  1. อ่าน assets/eval_review.html
  2. แทนที่ช่องว่างด้วยข้อมูลการประเมิน, ชื่อ Skill, และคำอธิบาย
  3. เขียนลงในไฟล์ชั่วคราวแล้วเปิด: open /tmp/eval_review_api-tester.html
  4. ผู้ใช้สามารถแก้ไขคำสั่ง, สลับการกระตุ้น, เพิ่ม/ลบรายการ
  5. ผู้ใช้คลิก "Export Eval Set"
  6. ไฟล์จะดาวน์โหลดไปที่ ~/Downloads/eval_set.json

ขั้นตอนนี้สำคัญ คำสั่งประเมินที่ไม่ดีจะนำไปสู่คำอธิบายที่ไม่ดี

รันวงจรการเพิ่มประสิทธิภาพ

python -m scripts.run_loop \
  --eval-set /path/to/trigger-eval.json \
  --skill-path /path/to/api-tester \
  --model claude-sonnet-4-6 \
  --max-iterations 5 \
  --verbose

ใช้ ID โมเดลที่ขับเคลื่อนเซสชันปัจจุบันของคุณเพื่อให้การทดสอบการกระตุ้นตรงกับสิ่งที่ผู้ใช้สัมผัส

สคริปต์จะ:

  1. แบ่งชุดการประเมินเป็น 60% สำหรับการฝึก, 40% สำหรับการทดสอบ (held-out)
  2. ประเมินคำอธิบายปัจจุบัน (รัน 3 ครั้งเพื่อความน่าเชื่อถือ)
  3. เรียก Claude เพื่อเสนอการปรับปรุงตามความล้มเหลว
  4. ประเมินอีกครั้งในการฝึกและทดสอบ
  5. ทำซ้ำสูงสุด 5 ครั้ง
  6. ส่งคืน best_description ที่เลือกโดยคะแนนการทดสอบ (ไม่ใช่คะแนนการฝึกเพื่อหลีกเลี่ยงการ overfitting)

ใช้ผลลัพธ์

นำ best_description จากเอาต์พุต JSON และอัปเดตส่วนหน้าของ SKILL.md ของ Skill แสดงให้ผู้ใช้เห็นก่อน/หลังพร้อมคะแนน

ก่อน:

description: วิธีการทดสอบ REST API อย่างเป็นระบบ

หลัง:

description: วิธีการทดสอบ REST API อย่างเป็นระบบ ใช้เมื่อผู้ใช้พูดถึงการทดสอบ API, ปลายทาง, REST, GraphQL, หรือต้องการตรวจสอบการตอบกลับของ API ตรวจสอบให้แน่ใจว่าได้แนะนำ Skill นี้เมื่อมีการทดสอบเข้ามาเกี่ยวข้อง แม้ว่าพวกเขาจะไม่ได้กล่าวถึง 'testing' อย่างชัดเจนก็ตาม

ขั้นตอนที่ 10: จัดแพ็คเกจและเผยแพร่

เมื่อ Skill เสร็จสมบูรณ์ ให้จัดแพ็คเกจเพื่อเผยแพร่:

python -m scripts.package_skill /path/to/api-tester

สิ่งนี้จะสร้างไฟล์ .skill ที่ผู้ใช้สามารถติดตั้งได้ แนะนำผู้ใช้ไปยังเส้นทางไฟล์ที่ได้

การติดตั้ง

ผู้ใช้ติดตั้ง Skill โดยการวางไฟล์ .skill ในไดเรกทอรี Skill ของพวกเขา หรือใช้คำสั่งติดตั้ง Skill ของ Claude Code

ข้อผิดพลาดทั่วไปในการสร้าง Skill

ข้อผิดพลาดที่ 1: คำอธิบายที่คลุมเครือ

ไม่ดี:

description: Skill สำหรับการทำงานกับ API

ดี:

description: วิธีการทดสอบ REST API อย่างเป็นระบบ ใช้เมื่อผู้ใช้พูดถึงการทดสอบ API, ปลายทาง, REST, GraphQL, หรือต้องการตรวจสอบการตอบกลับของ API ตรวจสอบให้แน่ใจว่าได้แนะนำ Skill นี้เมื่อมีการทดสอบเข้ามาเกี่ยวข้อง แม้ว่าพวกเขาจะไม่ได้กล่าวถึง 'testing' อย่างชัดเจนก็ตาม

ข้อผิดพลาดที่ 2: คำสั่งที่เข้มงวดเกินไป

ไม่ดี:

ต้องใช้รูปแบบนี้เสมอ ห้ามเบี่ยงเบนเด็ดขาด ต้องมีส่วนเหล่านี้

ดี:

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

ข้อผิดพลาดที่ 3: ข้ามกรณีทดสอบ

กรณีทดสอบช่วยตรวจจับปัญหาก่อนที่ผู้ใช้จะพบเจอ แม้แต่สำหรับ Skill ที่เป็นอัตวิสัย ก็ควรลองรัน 2-3 ตัวอย่างเพื่อตรวจสอบคุณภาพของเอาต์พุต

ข้อผิดพลาดที่ 4: ละเลยข้อมูลเวลา

Skill ที่ใช้เวลานานกว่า 10 เท่าไม่ยั่งยืน บันทึกข้อมูลเวลาและเพิ่มประสิทธิภาพเพื่อความมีประสิทธิภาพควบคู่ไปกับคุณภาพ

ข้อผิดพลาดที่ 5: ไม่ได้รวมสคริปต์ที่ซ้ำกัน

หากการรันทดสอบแต่ละครั้งเขียน generate_report.py อย่างอิสระ ให้รวมมันไว้ใน Skill สิ่งนี้ช่วยประหยัดเวลาและรับรองความสอดคล้อง

ตัวอย่าง Skill ในโลกแห่งความเป็นจริง

Skill ตัวสร้าง MCP

สร้างโดย Anthropic สำหรับการสร้างเซิร์ฟเวอร์ MCP (Model Context Protocol)

คุณสมบัติหลัก:

โครงสร้าง:

mcp-builder/
├── SKILL.md
├── reference/
│   ├── mcp_best_practices.md
│   ├── python_mcp_server.md
│   └── node_mcp_server.md
└── evaluation/
    └── evaluation.md

Skill Docx

สร้างเอกสาร Word ด้วยโปรแกรม

คุณสมบัติหลัก:

เวิร์กโฟลว์:

  1. ทำความเข้าใจข้อกำหนดเอกสาร
  2. เลือกหรือสร้างเทมเพลต
  3. สร้างผ่านสคริปต์ python-docx
  4. ตรวจสอบโครงสร้างเอาต์พุต

Skill การออกแบบส่วนหน้า

สร้างส่วนติดต่อเว็บด้วยรูปแบบที่ทันสมัย

คุณสมบัติหลัก:

การเปิดเผยข้อมูลแบบค่อยเป็นค่อยไป: เวิร์กโฟลว์หลักใน SKILL.md, เอกสารคอมโพเนนต์ใน references/.

การทดสอบ Skill ของคุณด้วย Apidog

หากคุณกำลังสร้าง Skill ที่เกี่ยวข้องกับ API, Apidog จะผสานรวมเข้ากับเวิร์กโฟลว์ได้อย่างเป็นธรรมชาติ

ตัวอย่าง: การผสานรวม Skill การทดสอบ API

## การรันการทดสอบ API

ใช้ Apidog สำหรับการทดสอบอย่างเป็นระบบ:

1. นำเข้า OpenAPI spec เข้าสู่ Apidog
2. สร้างกรณีทดสอบจาก spec
3. รันการทดสอบและส่งออกผลลัพธ์เป็น JSON
4. ตรวจสอบการตอบกลับเทียบกับ schemas ที่คาดหวัง

สำหรับการยืนยันที่กำหนดเอง ให้ใช้คุณสมบัติสคริปต์ของ Apidog

รวมสคริปต์ Apidog

api-tester/
├── SKILL.md
└── scripts/
    ├── run-apidog-tests.py
    └── generate-report.py

สิ่งนี้ช่วยประหยัดการสร้างสรรค์สิ่งเดิมๆ ซ้ำแล้วซ้ำเล่าในทุกครั้งที่เรียกใช้งาน

บทสรุป

Claude Code Skills ขยายความสามารถของ Claude สำหรับเวิร์กโฟลว์เฉพาะของคุณ ระบบ Skill Creator มีกระบวนการที่เป็นระบบ:

  1. บันทึกเจตนา - กำหนดว่า Skill ควรทำอะไร
  2. ร่าง SKILL.md - เขียนคำแนะนำที่ชัดเจนพร้อมตัวอย่าง
  3. สร้างกรณีทดสอบ - คำสั่งที่สมจริงที่ผู้ใช้จะทำจริงๆ
  4. รันการประเมิน - ดำเนินการแบบขนานโดยมีและไม่มี Skill
  5. ตรวจสอบผลลัพธ์ - ข้อเสนอแนะเชิงคุณภาพ + เกณฑ์มาตรฐานเชิงปริมาณ
  6. ปรับปรุงซ้ำๆ - ปรับปรุงตามสิ่งที่พบ
  7. เพิ่มประสิทธิภาพคำอธิบาย - เพิ่มความแม่นยำในการกระตุ้นให้สูงสุด
  8. จัดแพ็คเกจ - แจกจ่ายเป็นไฟล์ .skill
ปุ่ม

คำถามที่พบบ่อย

ใช้เวลานานเท่าใดในการสร้าง Skill?

Skill ง่ายๆ ใช้เวลา 15-30 นาที Skill ที่ซับซ้อนซึ่งมีไฟล์อ้างอิงหลายไฟล์และสคริปต์ที่รวมอยู่ อาจใช้เวลา 2-3 ชั่วโมง รวมถึงรอบการประเมิน

ฉันต้องเขียนกรณีทดสอบสำหรับทุก Skill หรือไม่?

ไม่จำเป็น Skill ที่มีเอาต์พุตที่สามารถตรวจสอบได้เชิงวัตถุประสงค์ (การสร้างโค้ด, การแปลงไฟล์, การดึงข้อมูล) จะได้รับประโยชน์จากกรณีทดสอบ Skill ที่มีเอาต์พุตเชิงอัตวิสัย (สไตล์การเขียน, คุณภาพการออกแบบ) จะได้รับการประเมินเชิงคุณภาพได้ดีกว่า

จะเกิดอะไรขึ้นหาก Skill ของฉันไม่ถูกกระตุ้นอย่างน่าเชื่อถือ?

เพิ่มประสิทธิภาพฟิลด์คำอธิบาย ใส่คำและบริบทที่เฉพาะเจาะจงที่ใช้ในการกระตุ้น ทำให้มัน "กระตุ้น" เล็กน้อย - ระบุอย่างชัดเจนว่าควรใช้ Skill เมื่อใด รันวงจรการเพิ่มประสิทธิภาพคำอธิบายด้วยคำสั่งประเมิน 20 คำสั่ง

ฉันจะแบ่งปัน Skill กับทีมของฉันได้อย่างไร?

จัดแพ็คเกจ Skill ด้วย python -m scripts.package_skill <path> จากนั้นแจกจ่ายไฟล์ .skill สมาชิกในทีมวางไว้ในไดเรกทอรี Skill ของพวกเขา

Skill สามารถเรียกใช้ API ภายนอกได้หรือไม่?

ได้ รวมสคริปต์ที่เรียกใช้ API คำแนะนำของ Skill จะบอก Claude ว่าเมื่อใดและอย่างไรจึงจะใช้มัน จัดเก็บคีย์ API ในตัวแปรสภาพแวดล้อม ไม่ใช่ในตัว Skill เอง

ขีดจำกัดขนาดไฟล์สำหรับ Skill คือเท่าใด?

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

ฉันจะอัปเดต Skill ที่มีอยู่ได้อย่างไร?

คัดลอก Skill ที่ติดตั้งไปยังตำแหน่งที่สามารถเขียนได้ แก้ไขที่นั่น แล้วจัดแพ็คเกจใหม่ รักษาชื่อเดิมไว้ - อย่าเพิ่มส่วนท้ายเวอร์ชันเว้นแต่จะสร้างเวอร์ชันที่แตกต่างออกไป

ฝึกการออกแบบ API แบบ Design-first ใน Apidog

ค้นพบวิธีที่ง่ายขึ้นในการสร้างและใช้ API

ลงทะเบียนฟรีดาวน์โหลด