วิธีสร้าง Claude Code Skill ให้ใช้งานได้จริง (คู่มือฉบับสมบูรณ์)

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

ทักษะ (Skill) แก้ปัญหานั้นได้ มันคือโฟลเดอร์เล็กๆ ที่คุณเขียนครั้งเดียวเพื่อสอน Claude ถึงขั้นตอนการทำงานถาวร เพื่อให้มันนำไปใช้ทุกเซสชันโดยไม่ต้องให้คุณขอ

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

ในคู่มือนี้ เราจะสร้างทักษะจริงขึ้นมาจากศูนย์: commit-messages ซึ่งเขียน git commits ในรูปแบบที่คุณต้องการ ถ้าคุณมี Claude ติดตั้งไว้และไม่มีอะไรอื่น คุณสามารถทำตามทุกขั้นตอนได้

สิ่งที่คุณจะได้

โดยแก่นแล้ว ทักษะคือโฟลเดอร์เดียวที่มีไฟล์บังคับหนึ่งไฟล์คือ SKILL.md มีสามโฟลเดอร์เสริมที่เข้ามาเมื่อทักษะเติบโตขึ้น:

1your-skill-name/
2├── SKILL.md          # Required - the main skill file
3├── scripts/          # Optional - executable code
4├── references/       # Optional - documentation
5└── assets/           # Optional - templates, etc.

ตัว SKILL.md เองมีสองส่วน: ส่วนหัวสั้นๆ ที่บอก Claude ว่าเมื่อไหร่ ควรใช้ทักษะ และคำแนะนำด้านล่างที่บอก Claude ว่าต้องทำอะไร เหตุผลที่แบ่งแบบนี้สำคัญ เพราะ Claude อ่านส่วนหัวตลอดเวลา ดังนั้นมันจึงรู้เสมอว่ามีทักษะอยู่ แต่มันจะโหลดคำแนะนำเมื่อคำขอของคุณตรงกันเท่านั้น จำความแตกต่างนี้ไว้ เพราะเกือบทุกอย่างในคู่มือนี้จะตามมาจากมัน

สร้างมันขึ้นมา

ทักษะต่างๆ อยู่ในโฟลเดอร์ที่ชื่อ .claude/skills ในโฮมไดเรกทอรีของคุณ ซึ่งทั้ง Claude Code และแอปเดสก์ท็อปอ่านจากนั้น มันเป็นโฟลเดอร์ที่ซ่อนอยู่และอาจจะยังไม่มีอยู่ ดังนั้นวิธีที่เร็วที่สุดในการสร้างมัน พร้อมกับโฟลเดอร์ของทักษะของคุณ คือคำสั่งเดียว

บน Mac ให้เปิด Terminal แล้วรัน:

1mkdir -p ~/.claude/skills/your-skill-name

บน Windows ให้เปิด PowerShell แล้วรัน:

1New-Item -ItemType Directory -Force -Path "$HOME\.claude\skills\your-skill-name"

ชื่อโฟลเดอร์ไม่ใช่แค่การตกแต่ง Claude ใช้มันเป็นตัวระบุทักษะ และกฎการจัดรูปแบบหนึ่งข้อที่ทำให้คนสะดุดมากกว่าข้ออื่นๆ:

• ใช้ kebab-case: notion-project-setup ✔
• ห้ามมีช่องว่าง: Notion Project Setup ✖
• ห้ามมีขีดล่าง: notion_project_setup ✖
• ห้ามตัวพิมพ์ใหญ่: NotionProjectSetup ✖

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

ออกแบบก่อนที่จะเขียน

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

อย่างแรก ตัดสินใจให้แน่ชัดว่าทักษะควรทำงานเมื่อไหร่ เขียนสถานการณ์จริงสองสามอย่างด้วยคำที่ผู้ใช้จะพิมพ์จริงๆ:

• "commit การเปลี่ยนแปลงเหล่านี้"
• "เขียน commit message สำหรับ diff นี้"
• "stage และ commit"

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

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

คำอธิบายคือสิ่งที่ทำให้สำเร็จหรือล้มเหลว

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

คำอธิบายที่ดีตอบคำถามสองข้อในหนึ่งประโยค: ทักษะทำอะไร และเมื่อไหร่ที่ Claude ควรใช้มัน ครึ่งหลังนั้นคือสิ่งที่คนมักละเว้น

นี่คือความแตกต่าง:

1# weak - บอกว่ามันคืออะไร แต่ไม่ให้อะไรให้ Claude จับคู่กับคำขอ
2description: ช่วยในการ git commits.
3
4# strong - ตั้งชื่อช่วงเวลาที่ควรทำงาน
5description: เขียนข้อความ commit git ในรูปแบบ Conventional Commits ใช้เมื่อผู้ใช้ขอให้ commit การเปลี่ยนแปลง เขียน commit message หรือ stage และ commit ไฟล์

เวอร์ชันอ่อนบอก Claude ว่ามีทักษะอยู่ แต่ไม่เคยเชื่อมโยงกับสิ่งที่คุณจะพูด เวอร์ชันแข็งแกร่งตั้งชื่อวลีจริง ดังนั้นเมื่อคุณพิมพ์ "commit การเปลี่ยนแปลงเหล่านี้" Claude มีบางอย่างให้จับคู่ ตั้งชื่อคำที่ผู้ใช้จะใช้จริงๆ เก็บทั้งหมดให้ต่ำกว่า 1024 ตัวอักษร และอย่าใส่ < หรือ > ไว้ข้างใน

เมื่อทักษะไม่ทำงาน การแก้ไขมักจะอยู่ที่นี่ เพิ่มวลีที่คุณใช้จริง ถ้าคุณพูดว่า "บันทึกงานของฉัน" แต่คำอธิบายกล่าวถึงแค่ "commit" Claude ไม่มีทางเชื่อมโยงทั้งสองได้ และถ้าตรงกันข้าม ทักษะทำงานเมื่อไม่ควร ให้จำกัดคำอธิบายให้แคบลงหรือเพิ่มตัวกระตุ้นเชิงลบ:

1description: เขียนข้อความ commit git ในรูปแบบ Conventional Commits ใช้เมื่อ commit การเปลี่ยนแปลง อย่าใช้สำหรับการเขียนความคิดเห็นในโค้ดหรือเอกสารประกอบ

มีวิธีตรวจสอบงานของคุณอย่างรวดเร็วก่อนที่คุณจะพึ่งพามัน ถาม Claude โดยตรง:

"คุณจะใช้ทักษะ commit-messages เมื่อไหร่?"

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

เขียนคำแนะนำที่ Claude ทำตามจริง

ด้านล่างส่วนหัวคือเนื้อหา ใน Markdown ธรรมดา นี่คือที่ที่ขั้นตอนการทำงานจริงของคุณอาศัยอยู่ และนิสัยสองอย่างแยกคำแนะนำที่ Claude ทำตามออกจากคำแนะนำที่มันค่อยๆ เบี่ยงเบนไป

อย่างแรกคือการเจาะจง Claude ทำตามคำแนะนำที่เป็นรูปธรรมและมองข้ามคำแนะนำที่คลุมเครือ ดังนั้นยิ่งคุณเจาะจงมากเท่าไหร่ มันก็ยิ่งทำงานได้น่าเชื่อถือมากขึ้น:

1# ไม่ดี
2ตรวจสอบ commit ก่อนที่จะสรุป
3
4# ดี
5รัน `python scripts/validate.py "<message>"`
6ถ้ามันล้มเหลว ให้แก้ไขสิ่งเหล่านี้:
7- ประเภทไม่ถูกต้อง: ใช้ feat, fix, docs, refactor, test, chore
8- สรุปเกิน 60 ตัวอักษร: ทำให้สั้นลง

อย่างที่สองคือการจัดลำดับ Claude ให้ความสำคัญกับสิ่งที่อ่านก่อน ดังนั้นกฎที่ถูกฝังไว้ที่ด้านล่างของไฟล์ยาวคือกฎที่ถูกมองข้าม ใส่สิ่งที่ต้องไม่ละเมิดไว้ด้านบน ใต้หัวข้อที่บ่งบอก:

1## สำคัญ
2- บรรทัดสรุปต้องต่ำกว่า 60 ตัวอักษร เสมอ
3- ใช้ปัจจุบันกาลเท่านั้น: "add" ไม่ใช่ "added"

นอกจากนี้ยังมีข้อจำกัดในสิ่งที่ภาษาสามารถรับประกันได้ คำแนะนำถูกตีความ ซึ่งหมายความว่า Claude ทำตามได้ดี แต่ไม่เหมือนกันทุกครั้ง เมื่อการตรวจสอบต้องผ่านทุกครั้งจริงๆ อย่าอธิบายเป็นร้อยแก้ว ย้ายมันไปไว้ในสคริปต์และให้คำแนะนำรันมัน โค้ดทำสิ่งเดียวกันทุกครั้ง ประโยคไม่ทำ (นั่นคือสิ่งที่โฟลเดอร์ scripts/ มีไว้สำหรับ ครอบคลุมในหัวข้อถัดไป)

โครงสร้างที่ใช้ได้กับทักษะส่วนใหญ่มีลักษณะดังนี้:

1# ชื่อทักษะ
2
3## สำคัญ
4กฎสำคัญที่ต้องไม่พลาด
5
6## คำแนะนำ
7ทีละขั้นตอน เจาะจง และปฏิบัติได้
8
9## ตัวอย่าง
10อินพุตและเอาต์พุตที่เป็นรูปธรรม Claude คัดลอกตัวอย่างได้น่าเชื่อถือมากกว่าการทำตามกฎ

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

สคริปต์ เอกสารอ้างอิง สินทรัพย์

ทุกอย่างที่ผ่านมาสร้างทักษะที่ให้คำแนะนำแก่ Claude สามโฟลเดอร์เสริมเปลี่ยนมันเป็นทักษะที่ให้เครื่องมือแก่ Claude และนี่คือจุดที่ทักษะทำสิ่งที่พรอมต์ธรรมดาทำไม่ได้

scripts/ เก็บโค้ดที่ Claude รัน สำหรับสิ่งที่ต้องแม่นยำ แทนที่จะเชื่อว่า Claude จะกะด้วยสายตาว่า commit ถูกจัดรูปแบบหรือไม่ คุณส่งสคริปต์ที่ตรวจสอบให้:

1# scripts/validate.py
2import sys
3msg = sys.argv[1]
4types = ("feat", "fix", "docs", "refactor", "test", "chore")
5
6if msg.split(":")[0] not in types:
7    print(f"Invalid type. Use: {', '.join(types)}")
8elif len(msg.split("\n")[0]) > 60:
9    print("Summary too long (over 60 chars)")
10else:
11    print("OK")

จากนั้นคุณบอก Claude ให้ใช้มันใน SKILL.md:

1ก่อนสรุป ให้รัน `python scripts/validate.py "<message>"`
2และแก้ไขสิ่งที่มันแจ้งเตือน

ตอนนี้กฎรูปแบบถูกบังคับใช้โดยโค้ดที่ทำงานในลักษณะเดียวกันทุกครั้ง แทนที่จะพึ่งพาให้ Claude จำต้องตรวจสอบ

references/ เก็บเอกสารที่โหลดเมื่อจำเป็นเท่านั้น สมมติว่าข้อตกลง commit ของคุณยาวถึงสองหน้าของขอบเขต ส่วนท้าย และกรณีขอบ ใส่ทั้งหมดนั้นใน SKILL.md แล้วมันจะโหลดทุกครั้งที่มีการ commit แม้แต่บรรทัดเดียว ย้ายมันไปไว้ในไฟล์อ้างอิงแทน:

1your-skill-name/
2├── SKILL.md
3└── references/
4    └── conventions.md

และชี้ไปที่มันจากไฟล์หลัก:

1สำหรับรายการข้อตกลงทั้งหมด ดูที่ references/conventions.md

Claude จะเปิดไฟล์นั้นเมื่องานต้องการเท่านั้น นี่คือเหตุผลทั้งหมดที่ทักษะยังคงมีค่าใช้จ่ายต่ำ: รายละเอียดหนักๆ อยู่บนดิสก์จนกว่าจะเกี่ยวข้องจริงๆ แทนที่จะมากับบริบททุกครั้ง

assets/ เก็บไฟล์ที่ทักษะใช้ในผลลัพธ์ แทนที่จะอ่านเป็นแนวทาง เช่น เทมเพลต ไฟล์กำหนดค่า หรือโลโก้ ทักษะ commit ไม่จำเป็นต้องมี แต่ทักษะที่สร้างรายงานอาจเก็บ template.md ไว้ที่นี่และกรอกข้อมูลทุกครั้ง เพื่อให้รายงานทุกฉบับมีโครงสร้างเดียวกัน

เมื่อรวมกันแล้ว สามโฟลเดอร์นี้คือความแตกต่างระหว่างทักษะที่บอก Claude ว่าคุณทำงานอย่างไร กับทักษะที่ส่งเครื่องมือที่แน่นอนให้ Claude เพื่อทำงานในแบบของคุณ

สิ่งเดียวที่ต้องจำ

ทักษะไม่ใช่การสอนความสามารถใหม่ให้ Claude มันรู้วิธีเขียน commit อยู่แล้ว สิ่งที่ทักษะทำคือทำให้มันทำงานในแบบของคุณ ทุกครั้ง โดยไม่ต้องให้คุณอธิบายอีกครั้ง

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

ถ้าสิ่งนี้มีประโยชน์ ไปที่โปรไฟล์ของฉันและติดตาม ฉันเขียนเกี่ยวกับเทคโนโลยี AI และระบบที่ทำงานจริง

Ciao,

@undefinedKi