Superpowers คืออะไร — เมโธดอโลยีที่ทำให้ agent ทำงานเป็นระบบ
ถ้าคุณเคยสั่ง Claude Code หรือ agent ตัวไหนก็ตามให้ "เขียนฟีเจอร์นี้ให้หน่อย" แล้วมันกระโดดเขียนโค้ดทันทีโดยไม่ถามอะไรเลย — บทนี้จะพาไปรู้จัก Superpowers ชุดเมโธดอโลยี (methodology) ที่เปลี่ยนพฤติกรรมนั้น ให้ agent "หยุดคิดก่อนลงมือ" และทำงานเป็นวงจรที่มีวินัยเหมือนทีมวิศวกรที่ดี บทนี้เป็นบทเปิดของแทร็ก จะพาดูภาพรวมทั้งหมดก่อน แล้วค่อยเจาะลึกทีละส่วนในบทถัดไป
Superpowers คืออะไรกันแน่
ตามคำนิยามใน README ของโปรเจกต์เอง Superpowers คือ
"a complete software development methodology for your coding agents, built on top of a set of composable skills and some initial instructions that make sure your agent uses them."
แปลเป็นไทย: มันคือ เมโธดอโลยีการพัฒนาซอฟต์แวร์แบบครบวงจร สำหรับ coding agent ที่คุณใช้ (Claude Code, Cursor, Codex ฯลฯ) สร้างจากสองส่วนประกอบ:
- composable skills — ชุด "skill" (ทักษะ/คู่มือการทำงาน) ที่แต่ละอันโฟกัสเรื่องเดียว แต่ออกแบบให้ต่อกันเป็นวงจรได้ เช่น brainstorming ต่อกับ writing-plans ต่อกับ test-driven-development ได้อย่างลื่นไหล
-
instruction ชุดแรกเริ่ม ที่ฝังไว้ตั้งแต่ session เริ่มต้น
(ผ่าน skill ชื่อ
using-superpowers) คอยบังคับว่า "ถ้ามี skill ที่เข้ากับงานนี้ ต้องใช้ ไม่ใช่ทางเลือก"
พูดง่าย ๆ Superpowers ไม่ใช่แค่ prompt เทพ ๆ อันเดียว แต่เป็น ระบบ (system) ที่ทำให้ agent มีวินัยในการทำงานเหมือน senior engineer ที่ผ่านสนามจริงมาเยอะ — ไม่ใช่ junior ที่กระโดดเขียนโค้ดทันที
ปัญหาที่มันแก้: agent ที่ "กระโดดเขียนโค้ด" ก่อนคิด
ปัญหาที่ทุกคนที่ใช้ AI ช่วยเขียนโค้ดเคยเจอ: บอกโจทย์คร่าว ๆ ไปหนึ่งประโยค agent ก็เขียนโค้ดออกมาทันที ทั้งที่โจทย์ยังไม่ชัด สเปกยังไม่นิ่ง พอโค้ดออกมาผิดทาง ต้องไล่แก้ย้อนหลัง เสียเวลามากกว่าคุยกันก่อนตั้งแต่แรก
README อธิบายพฤติกรรมที่ Superpowers ทำแทนไว้ชัดเจนว่า:
"As soon as it sees that you're building something, it doesn't just jump into trying to write code. Instead, it steps back and asks you what you're really trying to do."
นี่คือหัวใจของทั้งระบบ: ถอยมาหนึ่งก้าวก่อนเสมอ ถามให้ชัดว่า "จริง ๆ แล้วต้องการอะไร" ก่อนจะแตะโค้ดบรรทัดแรก แล้วทุกอย่างที่ตามมา (แผน, การเขียนโค้ด, การรีวิว) จะเดินตามสเปกที่ตกลงกันไว้ ไม่ใช่การเดาไปเรื่อย ๆ
| พฤติกรรม agent ปกติ | พฤติกรรมกับ Superpowers |
|---|---|
| รับโจทย์คร่าว ๆ แล้วเขียนโค้ดทันที | ถามคำถามให้สเปกชัดก่อน (brainstorming) แล้วเขียนสรุปให้ approve |
| เขียนโค้ดยาว ๆ ก้อนเดียว ตรวจยาก | แตกเป็นแผนงานทีละชิ้นเล็ก (2-5 นาที/ชิ้น) มีจุด verify ชัดเจน |
| เขียนเทสต์ทีหลัง หรือไม่เขียนเลย | บังคับ RED-GREEN-REFACTOR (เขียนเทสต์ก่อนเสมอ) |
| บอกว่า "เสร็จแล้ว" โดยไม่ได้ตรวจซ้ำ | มีขั้นตอน verification-before-completion ก่อนปิดงานทุกครั้ง |
วงจรหลัก (core loop) ของ Superpowers
เมื่อคุณเริ่มบทสนทนาว่า "อยากสร้าง X" วงจรที่ Superpowers พาเดินคือ:
สังเกตว่าตัว agent เอง ไม่ได้เขียนโค้ดทันทีที่ขั้นตอนที่ 1 เลย กว่าจะแตะโค้ดจริงคือขั้นตอนที่ 3 และแม้ในขั้น 3 ก็ยังบังคับ TDD (เขียนเทสต์ก่อน ดูมัน fail ก่อน ค่อยเขียน code ให้ผ่าน) README บอกว่า เมื่อคุณพิมพ์ "go" หลังอนุมัติแผน agent จะเข้าสู่โหมด subagent-driven development ทำงานทีละ task ในแผนต่อเนื่องได้เป็นชั่วโมงโดยไม่หลุดออกนอกแผนที่วางไว้
Auto-trigger: ทำไม skill ถึง "โผล่มาเอง" โดยไม่ต้องสั่ง
จุดที่ทำให้ Superpowers ต่างจากการแปะ prompt ยาว ๆ ในแชทคือกลไก
auto-trigger
— skill แต่ละตัวมี description กำกับไว้ว่า "ใช้เมื่อไหร่"
พอ agent เจอสถานการณ์ที่ตรงเงื่อนไข มันจะหยิบ skill มาใช้เองทันที
ไม่ต้องรอให้คุณพิมพ์ชื่อ skill เป๊ะ ๆ
ตัว skill using-superpowers เองคือ "กติกาแม่" ที่ฝังกฎนี้ไว้ตั้งแต่ต้น session
ใจความสำคัญที่สุดในไฟล์ SKILL.md ของมันคือ:
"If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill."
พูดง่าย ๆ คือ agent ต้อง "เช็คก่อนเสมอ" แม้กระทั่งก่อนจะถามคำถามชี้แจงกลับ (clarifying question) — เพราะบางที skill เองก็สอนวิธีถามคำถามที่ถูกต้องอยู่แล้ว skill.md ยังมีตาราง "Red Flags" (สัญญาณเตือนว่ากำลังหาข้ออ้างเลี่ยง skill) กำกับไว้ เช่น:
| ความคิดที่โผล่มา | ความจริงที่ skill บังคับ |
|---|---|
| "นี่แค่คำถามง่าย ๆ" | คำถามก็คือ task หนึ่ง ต้องเช็ค skill ก่อนเสมอ |
| "ขอสำรวจโค้ดในโปรเจกต์ก่อน" | skill สอนวิธีสำรวจที่ถูกอยู่แล้ว เช็คก่อนสำรวจ |
| "ฉันรู้จัก skill นี้อยู่แล้ว" | รู้ concept ≠ เรียกใช้จริง ต้อง invoke ทุกครั้ง |
แนวคิดนี้คือรูปแบบหนึ่งของ progressive disclosure — agent ไม่ต้องรู้รายละเอียดทั้ง 14 skill ตั้งแต่ต้น มันแค่รู้ "กติกาว่าต้องเช็ค" แล้วค่อยไปอ่านเนื้อหาเต็มของ skill ที่ตรงกับงานตอนนั้นจริง ๆ ประหยัด context และทำให้ agent โฟกัสงานตรงหน้าได้แม่นกว่า
ตัวอย่างสิ่งที่คุณจะเห็นในแชทเมื่อ auto-trigger ทำงาน — agent จะประกาศชื่อ skill ก่อนเริ่มลงมือเสมอ:
// ตัวอย่างข้อความที่ agent จะพิมพ์ก่อนเริ่มทำงานจริง
"Using brainstorming to explore the todo list feature design"
// หรือกรณีแก้บั๊ก
"Using systematic-debugging to find the root cause"
รวม 14 skills ทั้งหมด แบ่งเป็น 5 กลุ่ม
Superpowers มี skill ทั้งหมด 14 ตัว แบ่งตามหน้าที่ได้ดังนี้ (บทถัด ๆ ไปในแทร็กนี้ จะพาเจาะลึกทีละกลุ่ม):
| กลุ่ม | Skill | ทำหน้าที่อะไร | เจาะลึกที่ |
|---|---|---|---|
| Core loop (วงจรหลัก) | brainstorming | ตั้งคำถามแบบ Socratic ขัดเกลาไอเดียให้เป็นสเปกที่นิ่ง | SP-1 / SP-2 |
using-git-worktrees | สร้าง workspace แยกสาขา (branch) เพื่อทำงานแบบ isolate | ||
writing-plans | แตกงานเป็น task ย่อยขนาด 2-5 นาที มี path ไฟล์และวิธี verify ชัดเจน | ||
executing-plans | ทำแผนเป็นชุด (batch) พร้อมจุดหยุดให้คนเช็ค (checkpoint) | ||
finishing-a-development-branch | เช็คเทสต์ผ่านหมด แล้วเสนอทางเลือก merge/PR/เก็บ/ทิ้ง branch | ||
| TDD & Debugging | test-driven-development | บังคับ RED-GREEN-REFACTOR ลบโค้ดที่เขียนก่อนมีเทสต์ทิ้ง | SP-3 |
systematic-debugging | ไล่หา root cause เป็น 4 เฟส แทนการเดาสุ่ม | ||
verification-before-completion | ยืนยันว่า "แก้จริง" ก่อนประกาศว่าเสร็จ | ||
| Multi-agent | subagent-driven-development | ส่ง subagent ใหม่ทำทีละ task พร้อมรีวิว 2 ชั้น (ตรงสเปก + คุณภาพโค้ด) | SP-4 |
dispatching-parallel-agents | กระจายงานให้หลาย subagent ทำพร้อมกัน (concurrent) | ||
| Code Review | requesting-code-review | เช็กลิสต์ก่อนขอรีวิว จัดลำดับความรุนแรงของปัญหา | SP-5 |
receiving-code-review | วิธีตอบสนองต่อ feedback ที่ได้รับอย่างเป็นระบบ | ||
| Meta | writing-skills | คู่มือสร้าง skill ใหม่ตาม best practice (รวมวิธีเทสต์ skill) | SP-6 |
using-superpowers | กติกาแม่ที่บังคับให้ agent เช็ค/เรียกใช้ skill ก่อนทำอะไรก็ตาม (บทนี้แหละ) |
ปรัชญาที่ยึดร่วมกันทั้ง 14 skill (จาก README): Test-Driven Development เขียนเทสต์ก่อนเสมอ, Systematic over ad-hoc ทำตามกระบวนการ ไม่เดาสุ่ม, Complexity reduction เรียบง่ายไว้ก่อน, และ Evidence over claims ต้องพิสูจน์ก่อนอ้างว่าสำเร็จ
ติดตั้งใน Claude Code
Superpowers แจกจ่ายเป็น plugin ผ่าน official marketplace ของ Claude ติดตั้งง่าย ๆ ด้วยคำสั่งเดียวในแชท Claude Code:
# ติดตั้งผ่าน official marketplace (วิธีหลักที่ README แนะนำ)
/plugin install superpowers@claude-plugins-official
หรือถ้าอยากได้ปลั๊กอินเสริมอื่น ๆ ที่เกี่ยวข้องด้วย ใช้ Superpowers Marketplace แทน:
# ทางเลือก: ลงทะเบียน marketplace ของ Superpowers เอง
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
หลังติดตั้งเสร็จ skill using-superpowers จะถูกโหลดตั้งแต่ session
เริ่มต้น (และโหลดซ้ำหลัง compaction — ตอนที่ Claude สรุปบทสนทนาเก่าทิ้ง)
คุณไม่ต้องพิมพ์อะไรพิเศษเพิ่มอีกเลย — coding agent ของคุณจะ "มี Superpowers"
ทันที ตาม README ที่บอกไว้ตรง ๆ ว่า
"because the skills trigger automatically, you don't need to do anything special."
README ยังรองรับ harness อื่นด้วย เช่น Antigravity, Codex App/CLI, Cursor, Factory Droid, GitHub Copilot CLI, Kimi Code, OpenCode, Pi — แต่ละตัวมีคำสั่ง ติดตั้งของตัวเอง ถ้าคุณใช้มากกว่า 1 ตัว ต้องติดตั้งแยกกันในแต่ละ harness
ทำไมเรื่องนี้สำคัญกับงาน NestJS/Go ของคุณจริง ๆ
ลองนึกภาพงานที่คุณคุ้นเคย: เพิ่ม module ใหม่ใน NestJS ที่ต้องต่อกับ MongoDB, หรือเขียน service ใน Go ที่ต้องคุยกับ PostgreSQL หลายตาราง งานแบบนี้ถ้าปล่อยให้ agent เขียนรวดเดียวจบมักจะพลาดจุดสำคัญ เช่น validation, transaction, edge case ของข้อมูล — เพราะ agent ไม่เคยหยุดถามสเปกให้ชัดตั้งแต่แรก
- agent ไม่หลุด spec: เพราะขั้นตอน brainstorming + writing-plans บังคับให้สเปกนิ่งก่อนเขียนโค้ด แผนที่ได้จะระบุ path ไฟล์และ โค้ดที่ต้องเขียนไว้ชัดเจนจนแม้ agent ตัวใหม่ (ไม่มี context เดิม) ก็ทำต่อได้
- ทำงานยาวได้เองโดยไม่ต้องคุมทุกบรรทัด: subagent-driven-development ทำให้ agent ทำงานต่อเนื่อง "เป็นชั่วโมง" ได้ โดยไม่หลุดแผน เหมาะกับงานที่ต้องแก้หลายไฟล์พร้อมกัน เช่น เพิ่ม field ใหม่ แล้วต้องอัปเดตทั้ง DTO, entity, migration, controller ใน NestJS
- TDD บังคับจริง ไม่ใช่แค่พูด: เทสต์ unit สำหรับ service/repository ของคุณจะถูกเขียนก่อนโค้ดจริงเสมอ ลดโอกาสที่ agent จะ "เขียนโค้ดสวยแต่ลืมเทสต์"
ข้อควรระวัง: Superpowers ออกแบบมาให้ agent "เชื่อฟังกฎ" มากกว่าปกติมาก ถ้าคุณรีบและอยากได้โค้ดชิ้นเล็ก ๆ เร็ว ๆ มันอาจรู้สึกช้ากว่าที่คุ้นเคย (ต้องผ่าน brainstorm → plan ก่อนถึงจะได้โค้ด) — เหมาะกับงานที่มีความซับซ้อนจริงจัง ไม่ใช่ทุกงานเล็ก ๆ จำเป็นต้องผ่านวงจรเต็มรูปแบบ ให้อ่าน context ของงานก่อนตัดสินใจว่าคุ้มจะให้ agent เดินวงจรเต็มหรือไม่
-
เปิด
Learn/sources/superpowers/sp-0-overview/index.htmlเทียบกับsources/superpowers/README.mdต้นทางจริง แล้วลองสรุปด้วยคำพูดตัวเอง (ไม่เปิดดูบทนี้) ว่า "วงจรหลัก 5 ขั้นของ Superpowers มีอะไรบ้าง เรียงลำดับยังไง" -
เปิดไฟล์
sources/superpowers/skills/using-superpowers/SKILL.mdแล้วหาให้เจอว่า skill ตัวนี้บอกว่า "ต้องเช็ค skill ก่อนทำอะไรเป็นอันดับแรก" จริงไหม พร้อมยกประโยคที่เป็นหลักฐาน - ลองนึกงานจริงในโปรเจกต์ NestJS หรือ Go ของคุณ 1 อย่างที่เหมาะจะให้ agent เดินวงจรเต็มแบบ Superpowers (ซับซ้อนพอ คุ้มจะ brainstorm+plan ก่อน) แล้วเขียนเป็นประโยคสั้น ๆ ว่าทำไมงานนี้เหมาะ
เมื่อทำเสร็จ พิมพ์ /quiz SP-0 เพื่อทดสอบความเข้าใจ