Superpowers, BMAD, Spec Kitty: framework จัดทีม agent ใช้จริงหนักแค่ไหน?

่ 3 คือผลิตภัณฑ์ที่ขายประสบการณ์สำเร็จรูป ตอนนี้คือของกลางทาง คือ ชุดวิธีทำงานที่ติดตั้งเป็นสกิลให้ agent แล้วบังคับให้มันทำงานเป็นขั้นตอน คล้ายมีหัวหน้าทีมคอยสั่ง ความต่างที่สำคัญคือมันไม่ได้ให้แค่แม่แบบ spec แต่กำหนดว่าใครทำอะไร เมื่อไร และรีวิวกันแบบไหน ผลคือถ้าทีมคุณยังไม่มีกระบวนการ framework จะกลายเป็นกระบวนการแทนคุณ ซึ่งดีหรือไม่ดีขึ้นกับขนาดงาน Superpowers เป็นโครงการที่โตที่สุดในกลุ่มนี้ 304,296 ดาว ใบอนุญาต MIT และ push ล่าสุด 23 ต.ค. 2026 [1] แนวคิดคือแทนที่จะให้ agent ลงมือเขียนโค้ดทันที มันจะถามกลับก่อนว่าคุณกำลังทำอะไรจริง ๆ แล้วค่อย ๆ สกัดข้อกำหนดออกมาเป็นท่อนสั้นพอให้อ่านไหว [2] จากนั้นจึงสร้างแผนงานที่ละเอียดพอให้วิศวกรจูเนียร์ที่ไม่มีบริบทของโปรเจกต์ทำตามได้ และแบ่งงานให้ subagent ทำงานแบบเขียนเทสต์ก่อน แล้วมีคนรีวิว [2] จุดที่ผมประทับใจคือมันรองรับ host เยอะมาก ตั้งแต่ Claude Code, Codex, Cursor, Gemini CLI ไปจนถึง Hermes Agent และ Kimi Code [2] ต้องตอบคำถามเยอะในตอนเริ่ม ซึ่งช้าสำหรับงานเล็ก มี issue ค้างราว 354 รายการ [1] แปลว่าชุมชนใหญ่จนคำขอฟีเจอร์ วิ่งเร็วกว่าคนดูแล ถ้าทีมมีกระบวนการอยู่แล้ว การเอา framework เข้ามาทับจะทำให้เกิดสองระบบที่ขัดกัน BMAD Method หรือชื่อเต็มคือ BMad Method วางตัวเป็นวิธีทำ agile ที่ขับด้วย AI โดยแบ่งงานเป็นวงจร Clarify, Plan, Build and verify แล้วย้อนกลับมา Learn and adjust [3] จุดขายคือมันปรับขนาดตามงาน งานเล็กเข้า Build ตรง ๆ งานใหญ่ได้ความลึกตามที่ต้องการ และมีบทบาทสมมติอย่างนักวิเคราะห์ผลิตภัณฑ์ สถาปนิก และผู้ตรวจสอบคุณภาพ เวอร์ชันที่หน้า repo ระบุคือ v6.12 เป็นรุ่นเสถียร ส่วน v7 อยู่ระหว่างพรีวิวและประกาศกรอบเวลาไว้ว่าประมาณ 16 ต.ค. 2026 [3] ซึ่ง ณ วันที่ผมเขียน บล็อกนั้นยังไม่ปรากฏรุ่น v7 ในหน้า release จึงควรถือว่ายังไม่พร้อมใช้ README ของ BMAD ติดป้ายว่า MIT แต่ GitHub API รายงานใบอนุญาตเป็น NOASSERTION [1] ซึ่งหมายถึงระบบตรวจไม่พบไฟล์ใบอนุญาตที่ตรงมาตรฐาน ผมเปิดไฟล์ LICENSE ใน repo แล้วพบว่าข้อความข้างในเป็น MIT License ของ BMad Code, LLC [3] แปลว่า NOASSERTION น่าจะมาจากระบบตรวจที่ไม่รู้จักรูปแบบไฟล์ ไม่ใช่การละเมิดสัญญาอนุญาต ถึงอย่างนั้นถ้าจะใช้ในองค์กร ก็ควรให้ฝ่ายกฎหมายเปิดอ่านเองอีกรอบ เพราะความรับผิดชอบอยู่ที่ผู้นำไปใช้ ไม่ใช่ที่ป้ายบนหน้า repo ทีมที่มีคนอยากได้บทบาทชัดเจน และยอมให้ framework กำหนดลำดับงาน ต้องติดตั้ง uv และสคริปต์ Python เพิ่ม [3] บทบาทสมมติหลายบททำให้มีเอกสารหลายชั้น ซึ่งทีมเล็กอาจรู้สึกหนักเกินงาน การอยู่ในช่วงเปลี่ยนรุ่นใหญ่ ทำให้เอกสารสองชุดปนกันได้ง่าย Spec Kitty นิยามตัวเองว่าเป็น CLI สำหรับสร้างโรงงานซอฟต์แวร์ คือมีลำดับ spec, plan, tasks, next, review, accept, merge และเก็บสถานะทั้งหมดไว้ใน repo [4] จุดเด่นคือ worktree แยกต่อหนึ่งงาน ทำให้ agent หลายตัวทำงานขนานได้โดยไม่ชนกันใน branch เดียว และมีประตูอนุมัติให้คนตัดสินก่อน merge [4] รองรับ agent หลายค่าย ทั้ง Claude Code, Codex, Cursor, Gemini, GitHub Copilot, Windsurf และ OpenCode [4] 1,700 ดาว และมี issue เปิดค้าง 1,030 รายการ [1] ซึ่งเป็นอัตราส่วนที่สูงมาก ตัวเลขนี้ไม่ได้แปลว่าเครื่องมือไม่ดี แต่มันบอกว่าคำถามและข้อบกพร่องเข้ามาเร็วกว่ากำลังคนดูแล และรุ่น 4.0 ยังเป็น release candidate [4] ถ้าทีมคุณไม่มีคนรับผิดชอบเรื่องเครื่องมือโดยเฉพาะ การเจอ issue ที่ยังไม่มีคำตอบจะเป็นประสบการณ์ปกติ ไม่ใช่ข้อยกเว้น ในตอนที่ 2 ผมพูดถึง get-shit-done ซึ่งมี 64,236 ดาวแต่ถูก archive ไปแล้ว [1] ผมยกมาซ้ำเพราะมันเป็นภาพที่คนทำ SDD ควรเห็นบ่อย ๆ คือเครื่องมือที่ดูยิ่งใหญ่ที่สุดอาจหยุดพัฒนาไปแล้ว โดยที่บทความและวิดีโอเก่ายังแนะนำอยู่ ก่อนติดตั้งอะไรทุกครั้ง ให้เปิดหน้านั้นดูสามอย่าง คือ archived หรือไม่ push ล่าสุดเมื่อไร และ issue ค้างเท่าไร [1] จุดเริ่มที่ถนัด: Superpowers ถนัดงานใหม่ที่ยังไม่มีข้อกำหนด · BMAD ครอบทั้งงานเล็กและใหญ่ · Spec Kitty ถนัดงานที่ต้องรันขนานหลายชิ้น สิ่งที่ถูกบังคับใช้จริง: ทั้งสามบังคับผ่านสกิลและประตูอนุมัติ แต่ Spec Kitty บังคับถึงระดับ merge การเชื่อมกับ agent: Superpowers กว้างที่สุด · BMAD และ Spec Kitty รองรับหลายตัวแต่เน้น Claude Code ร่องรอยตรวจสอบ: Spec Kitty เก็บสถานะครบที่สุด เพราะออกแบบมาเพื่อ audit ภาระที่เพิ่มให้ทีม: สูงทั้งสามตัว บทความนี้จึงไม่แนะนำให้เริ่มจากที่นี่ถ้าทีมยังไม่เคยเขียน spec สุขภาพของโครงการ: Superpowers แข็งแรงที่สุด · BMAD กำลังเปลี่ยนรุ่นใหญ่ · Spec Kitty มี issue ค้างมาก สำหรับทีมที่ยังไม่เคยทำ SDD ผมไม่แนะนำให้เริ่มจาก framework เพราะคุณจะสับสนว่าปัญหาอยู่ที่กระบวนการหรือที่เครื่องมือ ลำดับที่ผมคิดว่าได้ผลกว่าคือ เขียน spec ด้วยเครื่องมือเบาจากตอนที่ 2 สองถึงสามสัปดาห์ แล้วค่อยถามว่าอะไรที่ยังเจ็บ ถ้าเจ็บที่ agent ไม่ทำตามแผน → framework ช่วยได้ ถ้าเจ็บที่งานขนานชนกัน → Spec Kitty หรือ Conductor ถ้าเจ็บที่ข้อกำหนดไม่ชัด → ปัญหาอยู่ที่การเขียน ไม่ใช่เครื่องมือ ทีมมีคนรับผิดชอบดูแลเครื่องมือนี้หรือยัง งานส่วนใหญ่เป็นงานเดี่ยวหรือขนานกันหลายสาย ถ้า framework กำหนดบทบาทของทีมใหม่ คุณยอมเปลี่ยนวิธีทำงานหรือไม่ ถ้าข้อสามตอบว่าไม่ คุ้มกว่าที่จะหยิบแค่บางสกิลมาใช้ ไม่ต้องยกทั้งชุด ยกตัวอย่างให้เห็นภาพ คือทีมช่างห้าคนที่ทำงานในโรงงานเดียวกัน ถ้าไม่มีใครกำหนดว่าใครทำอะไร ทั้งห้าคนจะหยิบเครื่องมือเดียวกันพร้อมกัน และชนกันที่โต๊ะตัวเดียว framework คือคนที่กำหนดว่าใครยืนตรงไหนและส่งงานต่อให้ใคร แต่ถ้าโรงงานของคุณมีงานชิ้นเดียว การจ้างคนมาคุมห้าคนจะกลายเป็นต้นทุนที่ไม่ได้ช่วยอะไร เหมือนซื้อระบบจัดการคลังสินค้าสำหรับของสามชิ้น ตอนที่ 5 คือตอนที่ผมรวบทุกอย่างมาเป็นแผนตัดสินใจ พร้อม checklist สองสัปดาห์และกับดักที่ทำให้โครงการ SDD ล้ม ซึ่งเป็นส่วนที่ผมคิดว่ามีค่าที่สุดในซีรีส์นี้ [1] GitHub REST API, ข้อมูล repository ของ obra/superpowers, bmad-code-org/BMAD-METHOD, spec-kitty/spec-kitty, gsd-build/get-shit-done, สืบค้น 24 ต.ค. 2026 (ดาว ใบอนุญาต วันที่ push และจำนวน issue).

https://api.github.com/repos/obra/superpowers [2] obra, "Superpowers README", สืบค้น 24 ต.ค. 2026 (วิธีทำงาน ตั้งแต่ถามความต้องการจนถึง subagent และรายชื่อ host ที่รองรับ). https://github.com/obra/superpowers [3] bmad-code-org, "BMAD-METHOD README", สืบค้น 24 ต.ค. 2026 (วงจร Clarify, Plan, Build, Learn · v6.12 · v7 preview · ต้องใช้ uv).

https://github.com/bmad-code-org/BMAD-METHOD [4] spec-kitty, "Spec Kitty README", สืบค้น 24 ต.ค. 2026 (ลำดับ spec ถึง merge · worktree แยกต่องาน · รายชื่อ agent ที่รองรับ · สถานะ 4.0 RC). https://github.com/spec-kitty/spec-kitty