รีวิว mattpocock skills: ไดเรกทอรี .agents ของวิศวกรตัวจริง 216k ดาว ที่ เอาไป remix ได้

นี่คือตัวที่สามที่เราเปิดดูในชุด repo skill สาย Claude Code ที่กำลังมาแรง 2 ตัวก่อนคือ superpowers กับ karpathy skills ตัวนี้ชื่อ mattpocock/skills ดาวสองแสนกว่า คำอธิบายของมันตรงและติดตลกว่า "Skills for Real Engineers" ชุด skill สำหรับวิศวกรตัวจริง ที่ Matt บอกว่าตรงมาจากโฟลเดอร์ .agents ของเขาเอง

ประโยคนั้นคือทั้งหมดของมัน ตัวนี้ไม่ได้ออกแบบมาเป็นระบบให้คนอื่นใช้ตั้งแต่ต้น แต่เป็น ไดเรกทอรีที่ Matt ใช้ทำงานจริงของตัวเอง แล้วเปิดให้คนอื่นก๊อปไปใช้ Matt Pocock เป็นนักสอนสาย TypeScript ที่คนในวงการรู้จัก skill ที่อยู่ในนี้เลยมีกลิ่นของคนที่เขียนโค้ดจริงมานาน ไม่ใช่ทฤษฎี

บทความนี้เล่าเป็นขั้น เริ่มจากมันคืออะไรและทำไมดาวเยอะ ต่อด้วย skill ที่โดดเด่นจริง แล้วเทียบให้เห็นว่าใน 3 ตัวที่รีวิวมา แต่ละตัวเป็นคนละขั้ว ควรหยิบตัวไหนไปใช้ ปิดที่วิธีลงและวิธีที่เราเอามาใช้เอง

ช่วงที่ 1mattpocock skills คืออะไร และทำไมดาวเยอะ

ตัวนี้ต่างจากอีก 2 ตัวตรงที่มันไม่ได้พยายามเป็นผลิตภัณฑ์ มันคือโฟลเดอร์ทำงานจริงที่เปิดให้ดู ข้างในมี skill ราว 35 ตัว จัดเป็นหมวด ที่น่าสนใจคือมันแยกของที่ พร้อมให้คนอื่นใช้ ออกจากของที่ยังเป็นการทดลองส่วนตัว หมวดงานวิศวกรรมกับ productivity คือของที่ขัดเกลาแล้ว ส่วนหมวดอย่าง in-progress หรือ personal คือของที่ยังไม่พร้อม เก็บไว้ในเครื่องตัวเอง การจัดแบบนี้ทำให้คนที่มาหยิบไปใช้ รู้ทันทีว่าตัวไหนเชื่อถือได้

ทำไมดาวถึงแตะสองแสน เพราะมันตอบความอยากที่ตรงมาก คนอยากเห็นว่าคนที่เขียนโค้ดเก่ง ๆ เขาตั้งค่า AI ของตัวเองยังไงจริง ๆ ไม่ใช่คำแนะนำกลาง ๆ แต่เป็นของที่ใช้อยู่ในงานประจำวัน แล้ว Matt ก็ทำให้หยิบไปง่าย มีทั้งคำสั่งลงอัตโนมัติ และวิธี symlink ให้ซิงก์กับ repo ตลอด

repo มี skill อะไรบ้าง

ถ้ามาหาว่าใน repo mattpocock/skills มี skill อะไรบ้าง สรุปหมวดที่ขัดเกลาแล้วไว้ตรงนี้ อ่านตรงจากไฟล์ SKILL.md ในเรพอ แบ่งเป็นสองหมวด ส่วนหมวดทดลองส่วนตัวไม่ได้เปิดให้ใช้ นับรวมทั้ง repo ราว 35 ตัว ในนั้นปลั๊กอิน v1.2.3 เปิดใช้ 25 ตัว

สาย engineering (18 ตัว) ask-matt, grill-with-docs, triage, improve-codebase-architecture, setup-matt-pocock-skills, to-spec, to-tickets, wayfinder, implement, prototype, diagnosing-bugs, research, tdd, domain-modeling, codebase-design, code-review, resolving-merge-conflicts, wizard

สาย productivity (7 ตัว) grill-me, grilling, handoff, teach, writing-for-agents, to-questionnaire, wait-what

ตัวที่เราหยิบมาเล่าต่อด้านล่างคือ diagnosing-bugs, tdd, grilling และ codebase-design เพราะกลิ่นคนทำงานจริงชัดสุด

ทำไมเลขใน README ไม่ใช่เลขที่โมเดลหยิบได้

เพราะมันมี 3 เลข ไม่ใช่เลขเดียว แล้วมันหล่นลงทีละชั้น 35 ไฟล์บนดิสก์ · 25 ตัวที่ปลั๊กอินประกาศ · เหลือ 11 ตัวที่โมเดลหยิบเองได้ เลขชุดนี้เราวัดจากเครื่องที่ลงปลั๊กอิน v1.2.3 ไว้จริง ไม่ได้นับจากหน้า README

ชั้นแรกหายไป 10 ตัว เพราะ plugin.json ไม่ได้ประกาศหมวด misc กับ in-progress ของยังอยู่ในรีโปให้เปิดอ่านได้ แต่ไม่ได้ถูกส่งมากับปลั๊กอิน

ชั้นที่สองน่าสนใจกว่า อีก 14 ตัวที่หายไปคือตัวที่เขียนกำกับไว้ในหัวไฟล์ว่า disable-model-invocation: true แปลว่า คนสั่งเองได้ แต่โมเดลหยิบมาใช้เองไม่ได้ เช่น to-spec to-tickets wayfinder triage handoff implement และอีก 8 ตัว

พอไล่ดูว่าตัวไหนอยู่ฝั่งไหน เส้นแบ่งชัดมาก ตัวที่ปล่อยให้โมเดลหยิบเองได้คือตัวที่ให้ วิธีคิด อย่าง tdd code-review diagnosing-bugs codebase-design ส่วนตัวที่ล็อกไว้ให้คนกดคือตัวที่ ลงมือเปลี่ยนของจริง หรือกินเวลายาว อย่างแตกงานเป็นตั๋ว วางแผนทั้งโปรเจกต์ ส่งไม้ต่อให้เซสชันหน้า

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

ผลพลอยได้คือรายชื่อที่โมเดลต้องแบกไว้ทุกเทิร์นสั้นลง จาก 25 บรรทัดเหลือ 11 บรรทัด ซึ่งในทางปฏิบัติแปลว่ามันเลือกผิดตัวได้ยากขึ้นด้วย

ช่วงที่ 2skill ที่โดดเด่นจริง

เปิดอ่านของจริงแล้ว มีหลายตัวที่กลิ่นของคนทำงานจริงชัดมาก ขอหยิบมาเล่า 4 ตัว

1. diagnosing-bugs ก่อนจะไปเดาสาเหตุบั๊ก ให้สร้างสัญญาณที่บอกผ่านหรือไม่ผ่านให้ชัดก่อน พอมีสัญญาณที่จับบั๊กได้แน่น ที่เหลือคือไล่บีบให้แคบลง เป็นการวางลำดับที่ถูก คือทำ feedback loop ให้แน่นก่อน ค่อยตั้งสมมติฐาน
2. tdd ไม่ได้บอกแค่ว่าเขียนเทสต์ก่อน แต่ตั้งชื่อสิ่งที่คนทำพลาดบ่อยไว้ด้วย เช่น เทสต์ที่ผูกกับวิธีเขียนข้างในเกินไป และย้ำให้เขียนเป็น แนวตั้งทีละฟีเจอร์ พร้อมตกลงขอบเขต seam ก่อนลงมือ
3. grilling เวลาให้ AI ซักข้อมูลจากเรา ให้ถามทีละคำถามแล้วรอคำตอบ ไม่ใช่ยิงรัวหลายคำถามทีเดียว เพราะคำถามชุดใหญ่ทำให้คนตอบข้าม ๆ
4. codebase-design บังคับใช้คำศัพท์ให้ตรง ทั้งโมดูล ความลึก และ seam มีกฎที่จำง่ายคือ ลองถามว่าถ้าลบโมดูลนี้ทิ้ง ความซับซ้อนจะกระจุกขึ้นหรือแค่ย้ายไปที่อื่น ถ้าแค่ย้าย แปลว่าโมดูลนั้นตื้น ไม่ได้ช่วยอะไร

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

ช่วงที่ 3สามขั้ว superpowers, karpathy, mattpocock เลือกตัวไหน

พอรีวิวครบ 3 ตัว เห็นภาพชัดว่าแต่ละตัวตอบคนละโจทย์ ไม่ได้แข่งกันตรง ๆ

• superpowers ชุด skill พร้อมตัวกันพลาดบังคับ เหมาะกับ ปล่อย AI ทำงานยาวเอง ต้องมีรั้วแน่น
• karpathy skills 4 หลักนามธรรมในไฟล์เดียว เหมาะกับ อยากได้หลักสั้น ๆ ไปแปะเริ่มต้น
• mattpocock skills ไดเรกทอรีจริงของคนทำงาน เหมาะกับ อยากได้เครื่องมือเป็นชิ้น ๆ ไป remix เลือกหยิบเฉพาะที่เข้ากับงาน

ถ้าจะให้เรียงตามสไตล์การใช้ superpowers คือคนที่อยากได้ระบบสำเร็จรูปพร้อมรั้ว karpathy คือคนที่อยากได้หลักคิดสั้นที่สุด ส่วน mattpocock คือคนที่ชอบประกอบเอง หยิบทีละชิ้นมาต่อเป็นชุดของตัวเอง ทั้งสามไม่ได้ขัดกัน จะเอา 4 หลักของ karpathy เป็นฐาน แล้วหยิบ skill เด่น ๆ ของ mattpocock มาเสริม โดยยืมวิธีดักข้ออ้างของ superpowers มาทำให้กฎอยู่จริง ก็ทำได้

ช่วงที่ 4ควรลงไหม แล้วเอาไปใช้ยังไง

ควรลอง mattpocock skills ไหม

คุ้มที่จะลอง โดยเฉพาะถ้าอยากดูตัวอย่าง skill ที่เขียนดีจากคนที่ทำงานจริง ตั้งแต่รุ่น v1.2.3 วิธีลงแยกเป็นสองทาง ต่างกันตรงความเป็นเจ้าของ ลงเป็นปลั๊กอินคือการบอกรับ ก๊อปไฟล์คือการเอามาเป็นของเรา ทางแรก claude plugins install mattpocock-skills ได้ทั้งชุดแบบอ่านอย่างเดียว เจ้าของออกรุ่นใหม่เมื่อไร มันก็ตามให้เอง ทางที่สอง npx skills@latest add mattpocock/skills ก๊อปไฟล์ลง repo เราตรงๆ เลือกได้ว่าจะเอาตัวไหน แก้ได้ตามใจ แลกกับต้องสั่ง npx skills update เอง แล้วรัน /setup-matt-pocock-skills หนึ่งครั้งต่อ repo README บอกไว้ชัดว่าอย่าลงทั้งสองทางพร้อมกัน ไม่งั้นได้ skill ซ้ำ 2 ชุด ถ้าตั้งใจจะ remix เลือกทางที่สอง

ไอเดียที่หยิบไปใช้ได้เลย

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

ส่วนเราเอง หยิบมาเทียบกับ skill ที่ใช้อยู่ แล้วยืมโครงบางตัวมาปรับ ไม่ได้ลงทั้งชุด เพราะหลายตัวผูกกับสาย TypeScript ที่ไม่ตรงกับงานเราทุกวัน วิธีที่เราเลือกและผสมเข้ากับ stack ตัวเองเป็นรายละเอียดที่ยังไม่ลงในบทความนี้ แต่หลักข้างบนใช้ได้ทันที

กฎข้อเดียวที่ต้องจำ

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

บทความนี้เป็นหนึ่งชั้นใน สถาปัตยกรรม AI agent ระดับ production ทั้ง 7 ชั้น