ใช้ skill stack พวกนั้นอยู่ อยากรู้มั้ยว่ามันมาจากไหน
skill stack ที่ใช้กันอยู่คือ DDD, SRP, Facade กับ ADR ที่ถูกหยิบกลับมา เพราะ agent เอาข้อจำกัดของทีมยุคก่อนกลับมาด้วย จะเขียน skill เองให้เริ่มจาก failure ที่เกิดขึ้นจริง
ถ้าตอนนี้ใช้ GStack, PStack, Compound Engineering หรือ skill ของ Matt Pocock อยู่
อยากรู้มั้ยว่าของพวกนั้นมันมาจากไหนจริง ๆ
ไม่ใช่คำถามเชิงประวัติศาสตร์นะครับ มันเปลี่ยนวิธีที่เราจะเขียน skill ของตัวเองเลย
เมื่อวานผมไม่ได้อ่านแค่หน้าเว็บ ผมเปิด repo ทั้งสี่ตัวไล่ดูไฟล์จริง แล้วเจอของที่ทำให้เถียงไม่ได้
ของชิ้นที่ทำให้จบเลย
ใน repo ของ Matt Pocock มี skill ชื่อ domain-modeling
เปิดไฟล์ spec ของมันดู มันสั่งให้สร้างสามอย่าง
GLOSSARY.md คำศัพท์กลางของโปรเจกต์
GLOSSARY-MAP.md ใช้ตอนที่ repo มีหลาย context แล้วแต่ละ context มี glossary ของตัวเอง
docs/adr/ บันทึกการตัดสินใจ เช่น 0001-event-sourced-orders.md
สามอย่างนี้ไม่ใช่ของใหม่
GLOSSARY.md คือ Ubiquitous Language ของ Eric Evans ปี 2003
GLOSSARY-MAP.md คือ Bounded Context ของเล่มเดียวกัน คำเดียวกันแปลว่าคนละอย่างได้ ถ้าอยู่คนละขอบเขต
docs/adr/ คือ Architecture Decision Record ที่ Michael Nygard เขียนไว้ปี 2011
ไม่ใช่การตีความของผม ชื่อไฟล์มันบอกเอง
ในไฟล์ยังมีตัวอย่างบทสนทนาด้วย "คุณพูดว่า account หมายถึง Customer หรือ User สองอันนี้คนละอย่างนะ"
ใครเคยอ่าน DDD จะรู้ว่านั่นคือตัวอย่างเปิดเล่ม
GStack — 9 skills ของ Garry Tan
"Planning is not review. Review is not shipping. Founder taste is not engineering rigor."
หนึ่ง skill หนึ่ง mode เขาเรียกว่า explicit cognitive gears
อันนี้คือ Single Responsibility Principle แต่ย้ายที่ใช้
Uncle Bob ไม่เคยบอกว่า SRP แปลว่าไฟล์ต้องสั้น เขาบอกว่าของชิ้นหนึ่งควรมีเหตุผลให้แก้เหตุผลเดียว
ถ้า skill ตัวเดียวทำทั้ง plan ทั้ง review วันไหนอยากเข้มกับ review ขึ้น ต้องไปแก้ไฟล์ที่คุม plan ด้วย แล้ว plan ก็เพี้ยนโดยไม่ได้ตั้งใจ
เหตุผลให้แก้สองเหตุผลอยู่ในที่เดียว นั่นแหละที่ SRP เตือนไว้
PStack — ของ Lauren Tan
บอก goal ไปที่ poteto-mode ที่เดียว มันเลือก workflow ให้เอง
GStack มี 9 ตัว เลยเปิดให้เรียกตรงได้ เพราะคนจำ 9 อย่างไหว
พอของข้างในเยอะเกินกว่าที่คนเรียกควรต้องรู้ ก็ต้องมีหน้าบ้านมาบังแล้วเลือกให้
นั่นคือ Facade ของ Gang of Four ปี 1994 และเป็นเหตุผลเดียวกับที่ Facade ถูกคิดขึ้นมา
ที่น่าสนใจกว่าคือของแถม pstack มี plugin แยกต่างหากที่เอา TLA+ กับ Lean มาใส่
เขาเขียนเหตุผลไว้ตรง ๆ ว่าเอาไว้จับ "invariants ที่ test เข้าไม่ถึง"
formal methods เป็นของที่เก่ากว่า design pattern อีก และมันกลับมาอยู่ในกล่องเครื่องมือของ agent ปี 2026
Compound Engineering — 36 skills ของ Kieran Klaassen
ลูปคือ brainstorm → plan → build → review → capture
ข้อสุดท้ายคือข้อที่ทุกคนข้าม และเป็นข้อเดียวที่ทำให้มันต่างจาก workflow ธรรมดา
capture ไม่ใช่เขียน doc ไว้อ่านเอง แต่คือเขียนสิ่งที่เพิ่งเรียนรู้ ลงในที่ที่งานครั้งหน้าจะอ่านเจอ
ถ้าบอก agent ว่าอย่าใช้ library ตัวนี้ แล้วไปจดไว้ใน Notion ครั้งหน้ามันไม่เห็น เราก็แก้เรื่องเดิมอีกรอบ
ประเด็นของ Evans ไม่ใช่ว่าต้องมีเอกสาร แต่คือ model ต้องอยู่ในที่ที่งานเกิดขึ้นจริง
เปลี่ยนคำว่าทีม เป็น agent ตัวถัดไป ก็ได้ข้อเดียวกัน
Matt Pocock — เกณฑ์ว่า skill หนึ่งตัวจะมีอยู่ได้ยังไง
อันนี้ของจริงที่สุด เขาเขียนไว้ใน SCOPE.md
ไอเดียจะผ่านได้ต้องมี observed failure คือมีเรื่องที่พังจริงใน session จริง รันอะไร skill ทำอะไร คาดว่าจะได้อะไร
แล้วเขียนต่อว่า ข้อเสนอแบบ "มันน่าจะดีกว่าถ้า..." ไม่ผ่านเกณฑ์นี้
อีกข้อ ถ้าพฤติกรรมนั้นประกอบขึ้นจาก skill ที่มีอยู่แล้วได้ มันจะไม่ได้ skill ใหม่
และมีโฟลเดอร์ชื่อ .out-of-scope เก็บไฟล์ละหนึ่งไอเดียที่ถูกปฏิเสธ พร้อมเหตุผล
ทีนี้ลองเทียบกับ Gang of Four
ของที่ GoF ทิ้งไว้จริง ๆ ไม่ใช่ pattern 23 ตัว แต่เป็นแบบฟอร์ม ชื่อ ปัญหาที่วนกลับมา วิธีแก้ และสิ่งที่ต้องแลก
Pocock ใช้แบบฟอร์มเดียวกัน แล้วเพิ่มอีกชั้นที่ GoF ไม่มี คือบันทึกของที่ไม่รับไว้ด้วย
หลักฐานที่ผมว่าหนักที่สุด
ลองดูชื่อ skill ของสองเจ้าที่ทำกันคนละที่ คนละทีม
Pocock มี handoff, code-review, prototype, retro, diagnosing-bugs
Compound Engineering มี ce-handoff, ce-code-review, ce-prototype, ce-retune, ce-debug
ไม่มีใครลอกใคร แต่พอเจอข้อจำกัดชุดเดียวกัน ของที่ออกมาก็หน้าตาเหมือนกัน
handoff โผล่มาทั้งสองเจ้า เพราะทั้งคู่เจอปัญหาเดียวกัน คือ context มันหายตอนเปลี่ยน session
ทำไมปัญหามันหน้าตาคุ้น
agent ตัวหนึ่งมี context จำกัด จบ session แล้วลืม และไม่รู้ว่าตัวอื่นทำอะไรไปแล้ว
อ่านสามข้อนั้นอีกรอบ แล้วเปลี่ยนคำว่า agent เป็นคำว่า ทีม
คุยกันได้จำกัด คนลืม ไม่มี model กลางที่ทุกคนเห็นตรงกัน
นั่นคือสภาพทีม dev ปี 1995 พอดี และหนังสือ architecture ทั้งหมดถูกเขียนขึ้นมาเพื่อสภาพนั้น
พอ IDE ฉลาดขึ้น ทีมเล็กลง คุยกันง่ายขึ้น เราก็เลิกแคร์กฎพวกนั้นไปเยอะ ไม่ใช่เพราะมันผิด แต่เพราะข้อจำกัดที่มันแก้อยู่มันหายไป
agent เอาข้อจำกัดชุดนั้นกลับมาคืน วิธีแก้เลยกลับมาด้วย
แล้วมันเปลี่ยนอะไรสำหรับเรา
ถ้าจะเขียน skill ของตัวเอง ยืมเกณฑ์ของ Pocock มาใช้สองข้อ
ข้อแรก skill นี้กัน failure อะไร ตอบเป็นเหตุการณ์จริงที่เคยเกิด รันอะไร มันทำอะไร เราคาดว่าจะได้อะไร ถ้าตอบไม่ได้ มันไม่ใช่ skill มันคือ prompt ที่เราชอบ
ข้อสอง ถ้าของที่อยากได้ประกอบจาก skill เดิมได้ อย่าเพิ่งสร้างใหม่
แล้วเพิ่มข้อสามจาก Compound Engineering สิ่งที่เรียนรู้รอบนี้ เขียนลงในที่ที่รอบหน้าจะอ่านเจอหรือยัง ถ้าอยู่ใน Notion แปลว่ายัง
สามข้อนี้คือ GoF กับ Evans ย่อให้สั้นที่สุด
ถ้าอยากรู้ว่า skill stack ปีหน้าหน้าตาเป็นยังไง ไม่ต้องรอ repo ใหม่
ของที่คนเขียน stack พวกนี้อ่าน มันอยู่บนชั้นหนังสือมาสามสิบปีแล้ว