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

TL;DR

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

ทดลองใช้ Apidog วันนี้

บทนำ

คุณใช้ 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 ของคุณให้ชัดเจน

ถามตัวเอง 4 ข้อ:

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

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

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

---

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

ทุก Skill ต้องมีไฟล์ SKILL.md ขึ้นต้นด้วย YAML frontmatter และคำแนะนำ markdown

ตัวอย่างโครงสร้างไฟล์

---
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
**การตอบกลับ:** {...}

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

Best Practices:

• รักษา SKILL.md ให้น้อยกว่า 500 บรรทัด
• ข้อมูลอ้างอิงยาวๆ แยกไฟล์
• ใช้รูปแบบคำสั่งสั้น กระชับ อธิบาย "เหตุผล"
• แสดงอินพุต/เอาต์พุตตัวอย่าง

---

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

สร้างคำสั่งทดสอบที่สมจริง 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"]
    }
  ]
}

คำสั่งทดสอบที่ดีควร:

• ชัดเจนระบุ URL
• อธิบายสถานการณ์
• ระบุผลลัพธ์ที่คาดหวัง
• มีบริบทจริง

---

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

รันแต่ละกรณีทดสอบทั้งแบบมี Skill และไม่มี Skill

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

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

Logging Timing:

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

---

ขั้นตอนที่ 5: ร่างข้อกล่าวอ้าง

ขณะการรันประเมิน ให้เตรียม assertions สำหรับแต่ละ test case

ตัวอย่าง assertions สำหรับ API

{
  "assertions": [
    {
      "name": "includes_auth_failure_test",
      "description": "รายงานการทดสอบมีกรณีทดสอบความล้มเหลวในการยืนยันตัวตนอย่างน้อยหนึ่งรายการ",
      "type": "contains",
      "value": "401"
    },
    {
      "name": "includes_success_test",
      "description": "รายงานการทดสอบมีกรณีทดสอบคำขอที่สำเร็จอย่างน้อยหนึ่งรายการ",
      "type": "contains",
      "value": "200"
    }
  ]
}

---

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

• รัน grader subagent เพื่อประเมินแต่ละ assertion
• บันทึกลง grading.json:

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

• รวบรวมผลด้วย script:

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

---

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

• สร้าง review interface ด้วย

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=$!

• ผู้ใช้สามารถดูผลลัพธ์และให้ feedback ได้ทันที

---

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

อ่าน feedback จาก feedback.json ปรับปรุง Skill ตามข้อเสนอแนะที่ได้รับ และวนลูปซ้ำ (รัน iteration ถัดไป, เปิด viewer ใหม่, รอ feedback, ทำซ้ำ) จนกว่าผู้ใช้จะพอใจหรือไม่มีข้อเสนอแนะเพิ่มเติม

---

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

ฟิลด์ description ใน SKILL.md มีผลต่อการ trigger

ขั้นตอนการเพิ่มประสิทธิภาพ:

1. สร้างชุด prompt ทดสอบ trigger (true/false) ~20 prompt
2. ให้ผู้ใช้รีวิวและปรับแต่ง
3. รันสคริปต์ optimize:

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

1. ใช้ best_description ที่ได้มาอัปเดต SKILL.md

---

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

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

จะแพ็คเกจเป็นไฟล์ .skill สำหรับติดตั้งและแจกจ่าย

การติดตั้ง:

นำไฟล์ .skill ไปวางในไดเรกทอรี Skill ของผู้ใช้

---

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

1. คำอธิบายคลุมเครือ

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

แก้ไข: ระบุวัตถุประสงค์และ trigger ให้ชัดเจน

2. คำสั่งที่เข้มงวดเกินไป

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

แก้ไข: อธิบายเหตุผลและเปิดกว้างต่อ context

3. ข้ามกรณีทดสอบ

ไม่ควรข้าม test cases แม้จะเป็น skill ด้าน subjective

4. ละเลยข้อมูลเวลา

บันทึก duration และ token usage ทุกครั้งเพื่อ optimize

5. ไม่ได้รวมสคริปต์ที่ซ้ำกัน

หากทุก test case สร้าง script เดียวกัน ควรรวมไว้ใน Skill

---

ตัวอย่าง Skill ในโลกจริง

Skill ตัวสร้าง MCP

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

Skill Docx

• ใช้ python-docx
• ระบบเทมเพลต
• workflow: ทำความเข้าใจข้อกำหนด → สร้างเทมเพลต → สร้างเอกสาร → ตรวจสอบ

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

• Tailwind CSS, ตรวจสอบ accessibility
• เวิร์กโฟลว์ใน SKILL.md, รายละเอียดคอมโพเนนต์ใน references/

---

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

หาก Skill ของคุณเกี่ยวกับ API, Apidog ผสานเข้า workflow ได้อย่างง่าย

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

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

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

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

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

โครงสร้าง Skill:

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

---

บทสรุป

Claude Code Skills ช่วยขยายความสามารถของ Claude ให้รองรับเวิร์กโฟลว์เฉพาะได้อย่างมีระบบ:

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

---

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

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

Skill ง่ายๆ ใช้เวลา 15-30 นาที Skill ที่ซับซ้อนอาจใช้เวลา 2-3 ชั่วโมง (รวมรอบประเมิน)

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

ไม่จำเป็น Skill ที่ตรวจสอบผลลัพธ์ได้ควรมี test case Skill ด้าน subjective ใช้ qualitative feedback ได้

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

เพิ่มประสิทธิภาพ description field ใส่คำ/บริบท trigger ที่เหมาะสม และรันรอบ optimize

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

จัดแพ็คเกจด้วย python -m scripts.package_skill <path> แจกไฟล์ .skill ให้เพื่อนร่วมทีม

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

ได้ รวมสคริปต์เรียก API ไว้ใน Skill (เก็บ key ไว้ใน env var)

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

SKILL.md ไม่ควรเกิน 500 บรรทัด ไฟล์อ้างอิง/สคริปต์ไม่จำกัด (โหลดแบบ on-demand)

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

แก้ไข Skill ในไดเรกทอรีที่เขียนได้ แล้วจัดแพ็คเกจใหม่

---

เพิ่มเติม:

• Apidog สำหรับการทดสอบและจัดการ API อย่างมืออาชีพ