GitHub repo ตัวหนึ่ง — 4 ไฟล์ รวม 468 บรรทัด ไม่มี code สักบรรทัด ดาวขึ้น
1,700
คนสร้างชื่อ ดร.ธนานนท์ หรือ 9arm — engineer คนไทยที่ทำงานอยู่ Silicon Valley
ปล่อย repo ชื่อ 9arm-skills ลง GitHub สิ่งที่อยู่ข้างในไม่ใช่ library ไม่ใช่ framework
ไม่ใช่แม้แต่ script
เป็น Markdown 4 ไฟล์ ที่สอน Claude Code ว่า “ก่อนจะทำอะไร ให้คิดยังไง”
ข้างในมีอะไรบ้าง
4 สกิล แบ่งเป็น 2 กลุ่ม:
กลุ่ม Engineering (ใช้ตอนเขียน code) –
debug-mantra — วิธี debug อย่างเป็นระบบ –
post-mortem — เขียนบันทึกหลัง fix bug –
scrutinize — review code/PR แบบ outsider
กลุ่ม Productivity (ใช้ตอนสื่อสาร) –
management-talk — แปลเรื่อง technical เป็นภาษาผู้บริหาร
ทั้ง 4 ตัวต่อกันเป็น pipeline ได้: debug → บันทึก → รายงาน
debug-mantra — “ท่องก่อน ทำทีหลัง”
สกิลตัวนี้เปิดมาบรรทัดแรกเขียนว่า:
Recite this — verbatim, as the first thing in your first response
ไม่ได้เขียนผิด AI ต้อง “ท่อง” mantra 4 ข้อก่อนเริ่ม debug:
- First is reproducibility — reproduce ได้ก่อนไหม?
- Know the fail path — เส้นทางที่พังคือตรงไหน?
- Question your hypothesis — สิ่งที่คิดว่าใช่ ลอง prove
ว่าผิดก่อน - Every run is a breadcrumb — ทุกครั้งที่รัน คือหลักฐาน
ถ้า reproduce bug ไม่ได้? ห้ามเดินหน้า ห้ามเดา ห้ามเสนอ fix หยุดตรงนั้น
ใช้ได้ตอนไหน: บอก Claude Code ว่า /debug-mantra หรือแค่
paste error log ให้ — สกิลจะ trigger เอง
post-mortem — บันทึกให้คนต่อไปอ่าน
หลัง fix bug เสร็จ สกิลนี้ช่วยเขียน engineering record ที่ครบ — root cause
คืออะไร fix ยังไง ทำไมถึงหลุดมาได้
แต่มี gate ที่น่าสนใจ: AI จะปฏิเสธเขียน ถ้ายังไม่ครบ 4 เงื่อนไข
- Reliable repro ต้องมี
- Root cause ต้องรู้จริง (ไม่ใช่แค่ hypothesis)
- Fix ต้อง identify แล้ว
- Fix ต้อง validate แล้ว
ขาดข้อไหนข้อหนึ่ง? AI จะบอกว่า “ยังเขียนไม่ได้ ขาดข้อ X” แทนที่จะมั่วเขียนไปก่อน
ตัวอย่างใน repo เป็น GPU hang จริงบน training run — ชื่อ function จริง PR
number จริง อ่านแล้วเห็นภาพ bug ทั้งตัว
ใช้ได้ตอนไหน: หลัง fix bug เสร็จ อยาก document ให้ทีม —
/post-mortem แล้ว AI จะถามข้อมูลที่ขาด
scrutinize — review แบบคนนอก
สกิลนี้สอน AI ให้ review code/PR แบบ outsider — ไม่รู้ว่าใครเขียน
ไม่รู้ว่าทำไมถึงคิดว่าถูก อ่านใหม่จาก 0
ขั้นตอน: 1. Intent — สรุปว่า change นี้พยายามทำอะไร
แล้วถามว่ามีวิธีง่ายกว่าไหม 2. Trace — เดินตาม code path จริงๆ
ไม่ใช่แค่อ่าน diff 3. Verify — claim แต่ละข้อถูกจริงไหม input
อะไรจะ break 4. Report — finding + evidence + suggested
change → ship/fix/rework/reject
กฎที่ชัดมาก: “LGTM” ไม่ใช่ output ที่ valid — ต้องบอกว่า trace อะไรบ้างเพื่อให้
user ตัดสินได้ว่า review ครอบคลุมพอหรือยัง
ใช้ได้ตอนไหน: ก่อน merge PR — /scrutinize แล้วให้ AI อ่าน
change ใหม่ตั้งแต่ต้น
management-talk —
เรื่องเดียวกัน เขียนให้คนละคนอ่าน
สกิลสุดท้ายแปลง technical content เป็นภาษาที่ VP, PM, release manager
อ่านรู้เรื่อง
หลักการแปล: – Keep — ชื่อ product, JIRA keys, PR
numbers (ผู้บริหาร track ตาม key เหล่านี้) – Strip — ชื่อ
function, file path, commit SHA (ไม่มีประโยชน์กับผู้อ่าน) –
Translate — mechanism เป็น cause-and-effect 1-2
ประโยค
แล้วปรับ format ตาม channel:
- JIRA — เต็มรูปแบบ หัวข้อชัด
- Slack — ไม่เกิน 80 คำ bold บรรทัดแรก
- Standup — 1 บรรทัด
- Email — subject line = TL;DR, body 2-3
paragraphs - Meeting — bullet list เรียงตามลำดับที่จะพูด
ตัวอย่างใน repo ใช้ bug เดียวกับ post-mortem เขียนใหม่ 3 แบบ —
เห็นชัดว่าข้อมูลเดียวกัน format ต่างกันยังไง
ใช้ได้ตอนไหน: มี technical update อยากส่งให้ผู้บริหาร — บอก
channel (Slack/email/JIRA) แล้ว AI จะปรับ format ให้
ติดตั้งยังไง
9arm จัด repo ให้ใช้ได้ 2 ทาง:
- Plugin — add repo เป็น Claude Code plugin ผ่าน
.claude-plugin/plugin.json - Symlink — รัน
scripts/link-skills.sh
สร้าง symlink ไปที่~/.claude/skills/
ไม่ต้อง install อะไร ไม่มี dependency ไม่มี build step เป็น Markdown
ล้วนๆ
repo: github.com/thananon/9arm-skills
ใครใช้ Claude Code อยู่แล้ว ลองเริ่มจาก debug-mantra ตัวเดียว — 75
บรรทัดที่เปลี่ยนวิธี debug ทั้งหมด