ประเมิน opencode-config: repo ดาวห้าร้อยที่ควรหยิบแค่ไอเดีย ไม่ใช่ทั้งชุด

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

บทความนี้สรุปจากบันทึกการอ่านโค้ดต้นฉบับของทีมเรา ซึ่งเก็บไว้ที่ Issue #2 ของ muse101 โดยใช้ upstream opencode-config ของ Joel Hooks เป็นหลักควบคู่กัน ข้อความที่อ้างแหล่งรอง (เช่นข่าวรุ่น OpenCode) จะบอกไว้ชัดว่ายังไม่ได้ตรวจสอบเอง

สรุปสำหรับผู้บริหาร

• คำตัดสิน: ไม่ adopt ทั้ง repo หยิบเฉพาะไอเดีย 7 ข้อ เรียงตามคุ้มค่าเร็วสุดก่อน
• เพราะ repo หยุดนิ่งมา 9 เดือน ของที่โฆษณาเด่นสุด (skills ~3,043 บรรทัด) ไม่อยู่ใน repo และ README เขียนเกินไฟล์จริงหลายจุด
• ท่าทีเรื่องสิทธิ์ตรงข้ามกับเราโดยสิ้นเชิง: อ่าน .env ได้ไม่ต้องถาม อนุญาต git push และ bash เกือบไม่จำกัด
• สิ่งที่หยิบได้ทันทีคือฟอร์แมต checkpoint/handoff ท่อ debug สู่ prevention และสัญญา iterate แบบมีเกณฑ์คะแนน
• กลับมาดูใหม่เมื่อ repo กลับมาเคลื่อนไหว มี LICENSE ชัดเจน และ plugin รองรับ OpenCode รุ่นปัจจุบัน

repo นี้คืออะไร

opencode-config คือชุดแต่ง OpenCode ส่วนตัวของ Joel Hooks ที่เปิดสาธารณะ ประกอบด้วยไฟล์ตั้งค่า ตัวแทนย่อย 7 ตัว คำสั่งลัด 25 คำสั่ง และปลั๊กอินประสานงาน ตัวเลขภายนอกดูดีคือ public repo มี 59 commits ดาว 525 ดวง และ fork 46 ครั้ง แต่ไส้ในบอกอีกเรื่องคือ commit สุดท้ายอยู่เมื่อ 26 มกราคม 2026 นิ่งมาเกือบ 9 เดือนแล้ว สถานะแบบนี้เรียกว่า snapshot ไม่ใช่โปรเจกต์ที่ยังมีคนดูแล

จุดที่ต้องรู้ก่อนโคลนคือของที่โฆษณาเด่นที่สุดไม่ได้อยู่ใน repo โฟลเดอร์ skill/ ถูก gitignore ใน commit สุดท้ายด้วยเหตุผลเรื่อง sensitive เนื้อ skill จริงมาจาก external CLI ชื่อ swarm ที่อยู่นอก repo สิ่งที่โคลนมาได้จึงเหลือแค่ config บาง ๆ กับ wrapper ที่เรียกเครื่องมือนอก repo เป็นหลัก

โฆษณากับไฟล์จริง

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

ไอเดียเด่นที่น่าหยิบ

ของดีที่สุดของ repo นี้ไม่ใช้โค้ด แต่เป็นวิธีคิดเรื่องการประสานงาน อย่างแรกคือผู้ประสานงาน (coordinator) ห้ามแตะโค้ดเอง แตกงานเป็นชิ้นเล็ก 2–7 ชิ้นที่ไฟล์ไม่ทับกัน แล้วให้ worker จองไฟล์ผ่าน Agent Mail ก่อนลงมือ ปิดท้ายด้วย review loop บังคับคือตรวจ diff ให้ feedback แล้ว respawn ใหม่สูงสุด 3 รอบ ถ้ายังไม่ผ่านส่งต่อมนุษย์

อย่างที่สองคือวินัย context hygiene ที่เข้มแบบน่าเอาเยี่ยงอย่าง researcher ที่ค้นข้อมูลต้องย่อยเหลือ 3–5 bullets ส่งให้ coordinator เท่านั้น กล่องจดหมาย cap ไว้ 5 ฉบับ ไม่รวม body output ถูกตัดที่ 30K และทุกครั้งที่บีบ context จะบันทึกเหตุการณ์เป็น jsonl ไว้

อย่างที่สามคือท่อ debug สู่ prevention ทุกครั้งที่ debug ต้องเปิดงานป้องกันคู่กันและอัปเดต knowledge base เสมอ ไม่มี debug แบบแก้แล้วจบ ส่วนคำสั่ง iterate เป็น evaluator-optimizer คือ reviewer ให้คะแนน งานต่ำกว่า 8 เต็ม 10 วนแก้ใหม่สูงสุด 3 รอบ และมีธง --learn เขียน error pattern กลับเข้าคลัง

คำเตือนเรื่องสิทธิ์

ส่วนที่ต้องกากบาททิ้งทั้งก้อนคือท่าทีเรื่องสิทธิ์ของ repo นี้ เพราะตรงข้ามกับประตูนิรภัยของเราเกือบทุกข้อ config นี้อ่าน .env ได้โดยไม่ต้องถาม เปิด external_directory ให้เข้าถึงนอกโปรเจกต์ อนุญาต git push และ bash เกือบไม่จำกัด (ห้ามแค่ sudo, rm -rf และ fork-bomb) ไม่มีคำว่า "ask" เลยทั้งไฟล์ แถมเปิด autoupdate: true ไว้อีก

มากกว่านั้นคือ supply chain ที่ไม่ pin version เลย MCP และ tools เรียก @latest กับ global CLI ทั้งหมด ปลั๊กอิน spawn binary ชื่อ swarm จาก PATH พร้อม env เต็ม และมีเครื่องมือ repo-autopsy ที่โคลน repo ใดก็ได้แล้วรัน git reset --hard กับสร้างคำสั่ง shell จาก pattern ที่ interpolate ค่าเข้าไปได้ ทีมที่หยิบไอเดียไปใช้ต้องเอาแค่ pattern แล้วเขียนก้อนสิทธิ์ของตัวเอง ไม่ยกไฟล์ permission มาด้วยเด็ดขาด

อีกข้อคือความเข้ากันได้ ปลั๊กอินของ repo นี้เขียนกับ OpenCode API รุ่น v1 ขณะที่มีรายงานจากแหล่งรองว่า OpenCode 2.0 ออกมาแล้วและปลั๊กอิน v1 ใช้กับ 2.0 ไม่ได้ (เรื่องนี้เรายังไม่ได้ทดสอบเอง) ถ้าหยิบส่วนปลั๊กอินมาคือเขียนใหม่ ไม่ใช่อัปเกรด

สรุปชวนใช้

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

สำหรับ repo นี้โดยเฉพาะ แผน cherry-pick เรียงตามคุ้มค่าเริ่มจากฟอร์แมต checkpoint/handoff ที่พกข้าม harness ได้ทันที ตามด้วยท่อ debug สู่ prevention และสัญญา iterate แบบมีเกณฑ์คะแนน ส่วน model routing, agent archetype ทั่วไป และ stack Beads กับ Agent Mail ข้ามได้เลยเพราะของเรามีดีกว่าหรือซ้ำกันอยู่แล้ว

ขอบคุณ Joel Hooks สำหรับงานต้นแบบแบบเปิดเผยใน repo opencode-config และรายงานประเมินฉบับเต็มจาก muse101 Issue #2 ที่เป็นแหล่งหลักให้บทความนี้