Free

Slash Command: สร้างระบบคำสั่งที่นำมาใช้ซ้ำได้สำหรับ Claude Code

กำหนด slash command ที่นำมาใช้ซ้ำได้เป็นไฟล์ Markdown แชร์กับทีมผ่าน git และครอบคลุมงานบ่อยๆ เช่น code review, สร้าง test และ PR description


Claude Code มี slash command ในตัวอยู่บ้าง — /help, /clear, /compact แต่สิ่งที่เร่งความเร็ว workflow จริงๆ คือสิ่งที่คุณเขียนเอง

บทความนี้อธิบายวิธีออกแบบระบบ slash command ที่นำมาใช้ซ้ำได้ เพื่อให้ทีมทั้งหมดใช้ prompt library เดียวกัน แทนที่จะต้องเขียนคำอธิบายงานใหม่ทุกครั้ง

Slash Command แบบกำหนดเองคืออะไร

ใน Claude Code slash command แบบกำหนดเองคือไฟล์ Markdown ธรรมดา วางไว้ในไดเรกทอรีที่ถูกต้อง Claude Code จะตรวจพบเมื่อเริ่มต้น และพิมพ์ /ชื่อไฟล์ ก็จะทำงาน

เนื้อหาในไฟล์คือ prompt ที่ส่งไปยัง Claude แค่นั้นเอง

ไม่มีไวยากรณ์พิเศษ ไม่มีรูปแบบการตั้งค่า — ไฟล์ .md หนึ่งไฟล์คือหนึ่งคำสั่ง

วางไฟล์ไว้ที่ไหน

สองตำแหน่ง สองวัตถุประสงค์:

ตำแหน่ง เส้นทาง ขอบเขต
โปรเจกต์ .claude/commands/ เฉพาะโปรเจกต์ปัจจุบัน commit ลง git ได้
ผู้ใช้ ~/.claude/commands/ ทุกโปรเจกต์ ส่วนตัว

ระดับโปรเจกต์คือแกนกลางของการแชร์ในทีม Commit .claude/commands/ ลง git ทุกคนที่ clone repository จะได้ชุดคำสั่งครบโดยอัตโนมัติ

ระดับผู้ใช้เหมาะสำหรับนิสัยส่วนตัว เช่น การตรวจสอบ code style ที่ชอบ หรือการผสานเครื่องมือที่ใช้คนเดียว

สร้าง Command แรก

จาก root ของโปรเจกต์:

mkdir -p .claude/commands

สร้าง .claude/commands/review.md:

ตรวจสอบคุณภาพโค้ดของการเปลี่ยนแปลงปัจจุบัน เน้นที่:

1. ข้อผิดพลาดทางตรรกะและกรณีขอบ
2. ความชัดเจนของการตั้งชื่อ
3. โค้ดซ้ำที่ควรแยกออก
4. ปัญหาความปลอดภัย (SQL injection, XSS, secret ที่ถูกเปิดเผย)

ให้คำแนะนำที่เจาะจงและนำไปใช้ได้จริง ไม่ใช่คำแนะนำทั่วไป

รีสตาร์ท Claude Code และพิมพ์ /review เพื่อเปิดใช้งาน

ใช้ $ARGUMENTS รับข้อมูลนำเข้า

คำสั่งที่มีเนื้อหาคงที่มีการใช้งานจำกัด $ARGUMENTS ทำให้ยืดหยุ่น — สิ่งที่ผู้ใช้พิมพ์หลัง /คำสั่ง จะถูกแทรกเข้าไปใน prompt

ตัวอย่าง .claude/commands/test.md:

เขียน test สำหรับสิ่งต่อไปนี้: $ARGUMENTS

ข้อกำหนด:
- ครอบคลุม happy path และ edge case
- ชื่อ test ต้องอธิบายตัวเองได้
- ใช้ข้อมูลจริงแทน mock เมื่อทำได้

การใช้งาน:

/test เมธอด login ของคลาส UserAuthentication

Claude ได้รับ:

เขียน test สำหรับสิ่งต่อไปนี้: เมธอด login ของคลาส UserAuthentication

ข้อกำหนด:
...

$ARGUMENTS สามารถปรากฏที่ใดก็ได้ใน prompt และใช้ได้หลายครั้ง

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

หนึ่งคำสั่ง หนึ่งความรับผิดชอบ

อย่าเขียนคำสั่ง "ทำทุกอย่าง" /review สำหรับ code review, /test สำหรับเขียน test, /pr สำหรับ PR description คำสั่งที่เฉพาะเจาะจงจำง่ายและนำมาใช้ซ้ำได้ง่ายกว่า

เขียน prompt ที่เจาะจง ไม่ใช่นามธรรม

แย่:

ช่วยฉัน optimize โค้ดนี้

ดี:
```
Optimize โค้ดนี้ด้านประสิทธิภาพ ให้ความสำคัญกับ:
1. ลด database query ที่ไม่จำเป็น (ปัญหา N+1)
2. หลีกเลี่ยงการคำนวณซ้ำในลูป
3. แทนที่การค้นหาเชิงเส้นด้วยโครงสร้างข้อมูลที่มีประสิทธิภาพมากขึ้น

คงอินเทอร์เฟซไว้ — เปลี่ยนแค่การ implement ภายใน
```

ข้อจำกัดที่เจาะจงนำไปสู่ผลลัพธ์ที่ตรงเป้า

กุญแจสู่การนำไปใช้ในทีม: commit ลง git

คุณค่าที่แท้จริงของคำสั่งแบบกำหนดเองไม่ใช่ผลผลิตส่วนตัว แต่คือการให้ภาษาร่วมแก่ทีม

Commit .claude/commands/ ลง repository และบันทึกคำสั่งที่ใช้ได้ใน README หรือ CLAUDE.md สมาชิกใหม่ได้รับ prompt library ที่ทีมสะสมไว้ทันทีที่ clone repo

เมื่อโปรเจกต์พัฒนา คำสั่งก็พัฒนาด้วย ถ้า prompt ไม่ทำงานได้ดี แก้หนึ่งบรรทัดแล้ว push — ทีมทั้งหมดได้รับการอัปเดต

โครงสร้างไดเรกทอรีอ้างอิง

.claude/
├── commands/
│   ├── review.md
│   ├── test.md
│   ├── pr.md
│   └── explain.md
└── settings.json