การให้ Claude มี Superpowers หมายถึงอะไร?
Claude เก่งอยู่แล้วในการอ่าน code อธิบายระบบ เขียน patch และช่วย developer ทำงานเร็วขึ้น แต่ความฉลาดของ model ไม่เท่ากับ engineering behavior ที่เชื่อถือได้
การให้ Claude มี Superpowers คือการเพิ่ม software development methodology เข้าไปรอบ model แทนที่จะปล่อยให้ agent กระโดดจาก request ไป code ทันที Superpowers ให้ชุด skill ที่บังคับ workflow สำคัญ เช่น brainstorm ก่อน build, plan ก่อน edit, test ก่อน claim, debug ด้วย root cause, review งาน และ finish branch อย่างปลอดภัย
โปรเจกต์ open source อยู่ที่ obra/superpowers README อธิบายว่า Superpowers คือ complete software development methodology สำหรับ coding agents ที่สร้างจาก composable skills และ startup instructions รองรับ Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Kimi Code และ environment อื่นๆ
ประเด็นสำคัญคือ Superpowers ไม่ใช่แค่ plugin แต่มันคือวิธีทำให้ agent ทำงานเหมือน development partner ที่มีวินัยมากขึ้น
ปัญหาที่ Superpowers แก้
Failure ของ coding agent ส่วนใหญ่ไม่ใช่การพิมพ์ code ไม่ได้ แต่คือ process failure
Agent ปกติสามารถสร้าง code ได้เร็วมาก แต่ speed จะอันตรายเมื่อ agent:
- เริ่ม implementation ก่อนเข้าใจ goal
- แก้หลายไฟล์โดยไม่จำกัด scope
- เขียน code ก่อน test
- แก้ symptom โดยไม่หา root cause
- บอกว่าเสร็จโดยไม่มี verification
- drift จาก plan ใน session ยาวๆ
- ลืม preserve user changes
Superpowers แก้ failure modes เหล่านี้โดยตรง ด้วย workflow สำหรับ development cycle ทั้งหมด
Core workflow
Workflow พื้นฐานใน repo คือ:
- `brainstorming`
- `using-git-worktrees`
- `writing-plans`
- `subagent-driven-development` หรือ `executing-plans`
- `test-driven-development`
- `requesting-code-review`
- `finishing-a-development-branch`
ลำดับนี้สำคัญ เพราะมันคล้ายวิธีทำงานของ engineer ที่รอบคอบ
เข้าใจก่อนว่าจะ build อะไร จากนั้น isolate งาน เขียน plan implement ทีละส่วน test review และปิดงานอย่างสะอาด
Feature 1: Brainstorming
`brainstorming` skill ทำงานก่อนเขียน code หน้าที่คือป้องกัน premature implementation
เรื่องนี้สำคัญเพราะ user มักเล่า symptom ไม่ใช่ goal จริง เช่น user บอกว่า “เพิ่ม popup” แต่ goal จริงอาจเป็น monetization, course promotion หรือ conversion tracking ถ้า agent code ทันที อาจสร้างสิ่งที่ผิด
Brainstorming ให้ agent ถามคำถาม สำรวจทางเลือก และนำเสนอ design เป็นส่วนๆ ที่อ่านง่าย ทำให้ agent ไม่ใช่แค่เครื่องเขียน code แต่เป็น design collaborator
ใช้เมื่อ:
- request เกี่ยวกับ product decision
- user ยังตัดสินใจไม่หมด
- มีหลายวิธี implementation
- assumption ที่ผิดจะแพง
Feature 2: Using git worktrees
`using-git-worktrees` สร้าง workspace แยกบน branch เหมาะกับงานที่ agent อาจทำยาว หรือมีหลาย task ที่ทำคู่ขนาน
Isolation สำคัญเพราะ AI session อาจแตะหลายไฟล์ Worktree ช่วยให้ main workspace สะอาด rollback ง่าย และ review ง่ายกว่า
ใช้เมื่อ:
- task ใหญ่กว่า edit เล็กๆ
- น่าจะมี experiment
- มีหลาย branch หรือหลาย agent
- ต้องการ clean test baseline ก่อน implement
Feature 3: Writing plans
`writing-plans` เปลี่ยน approved design ให้เป็น implementation tasks เล็กๆ
นี่คือจุดที่ agent มักพลาด มันอาจเข้าใจ goal ใหญ่ แต่ implement แบบมั่วลำดับ Plan ที่ดีจะระบุ file, expected change, verification และ checkpoint
Planning ทำให้งาน review ง่าย และช่วยให้ resume หลัง compaction หรือ interruption ได้
ใช้เมื่อ:
- ต้องแก้มากกว่าหนึ่งไฟล์
- ลำดับ implementation สำคัญ
- ต้องเพิ่ม tests
- ต้องให้ human review ก่อน coding
Feature 4: Executing plans
`executing-plans` ทำให้ agent ทำงานตาม plan อย่างมีวินัย แทนที่จะแก้ทุกอย่างพร้อมกัน agent จะทำเป็น batch และรายงาน progress
เรื่องนี้สำคัญเพราะ long-running agents drift ได้ง่าย เริ่มจาก plan แล้วค่อยๆ เพิ่ม “improvement เล็กๆ” จนลืม acceptance criteria เดิม
ใช้เมื่อ:
- มี approved plan แล้ว
- tasks มีลำดับ
- ต้องการ human checkpoints
- งานควร trace ได้
Feature 5: Subagent-driven development
`subagent-driven-development` ใช้แยกงานเป็น task อิสระและใช้ context ใหม่ต่อ task ใน environment ที่รองรับ subagents สิ่งนี้ช่วยลด context pollution และเพิ่มความเร็ว
ประเด็นไม่ใช่ “มี agent เยอะๆ” แต่คือ separation of concerns agent หนึ่ง implement อีก agent ตรวจ spec compliance อีก agent review code quality
ใช้เมื่อ:
- tasks อิสระต่อกัน
- context ใหญ่
- parallel work ปลอดภัย
- review quality สำคัญ
Feature 6: Test-driven development
`test-driven-development` บังคับ red-green-refactor เขียน failing test ดูมัน fail เขียน code น้อยที่สุด ดู test pass แล้วค่อย refactor
นี่คือ feature สำคัญมาก เพราะ agent มักเชื่อ code ตัวเองเกินไป TDD ทำให้ correctness มองเห็นได้
ใช้เมื่อ:
- implement behavior ใหม่
- แก้ bug ที่ reproduce ได้
- refactor logic
- ป้องกัน regression
คุณไม่จำเป็นต้องเคร่งแบบศาสนาเรื่อง test style ถึงจะเห็นคุณค่า ประเด็นคือ evidence
Feature 7: Systematic debugging
`systematic-debugging` บังคับให้หา root cause ก่อน fix skill นี้ปฏิเสธ random patching ชัดเจน อ่านได้ที่ systematic-debugging/SKILL.md
เรื่องนี้สำคัญเพราะ agent เก่งในการเสนอ fix ที่ดู plausible เห็น error แล้ว patch code ใกล้ที่สุด บางครั้งได้ผล แต่หลายครั้งกลบปัญหาจริง
Systematic debugging ให้ agent observe, ตั้ง hypothesis เดียว, test แบบ minimal แล้วค่อย fix root cause
ใช้เมื่อ:
- test fail
- production behavior ผิดปกติ
- build fail
- integration พัง
- fix ก่อนหน้าไม่ได้ผล
Feature 8: Verification before completion
`verification-before-completion` แก้ปัญหา agent พูดว่า “done” เร็วเกินไป
ในงานจริง completion ไม่ใช่ความรู้สึก แต่มันคือหลักฐาน Build ผ่านไหม Test fail ก่อนและ pass หลังไหม Route ตอบตามคาดไหม UI render ถูกไหม Deployment live จริงไหม
ใช้ skill นี้ทุกครั้งก่อน agent สรุปงาน
Feature 9: Requesting and receiving code review
Review skills ทำให้ agent ตรวจงานตัวเองและตอบ feedback อย่างถูกต้อง
Code อาจ compile ผ่านแต่ยังผิด product intent, accessibility, security, performance หรือ maintainability Review pass ให้ lens ที่สองกับ agent
ใช้เมื่อ:
- change ไม่ trivial
- จะเปิด PR
- human ให้ review feedback
- quality สำคัญกว่า speed
Feature 10: Finishing a development branch
`finishing-a-development-branch` คือ safe closure มัน verify tests, เสนอ options และ clean up worktree state
งาน AI หลายครั้งจบแค่ “แก้ไฟล์แล้ว” แต่ในงานจริงต้องรู้ว่าควร merge, open PR, keep branch, discard experiment, deploy หรือ wait
ใช้เมื่อ implementation tasks เสร็จและขั้นต่อไปเป็น operational step
Feature 11: Writing skills
`writing-skills` เป็น meta-skill สอนวิธีสร้าง skill ใหม่ Superpowers มองการเขียน skill เหมือน TDD สำหรับ process documentation ไม่ใช่เขียนเพราะฟังดูดี แต่ต้องทดสอบว่า agent fail ถ้าไม่มี skill และดีขึ้นเมื่อมี skill ดู writing-skills/SKILL.md
สิ่งนี้สำคัญกับทีมมาก ถ้าทีมต้องแก้พฤติกรรม agent ซ้ำๆ พฤติกรรมนั้นควรถูกเปลี่ยนเป็น skill
Claude ก่อนและหลัง Superpowers
ถ้าไม่มี Superpowers Claude ก็ยังมีประโยชน์ มันตอบคำถาม patch code และอธิบายระบบได้ แต่ session จะพึ่ง user มากในการบังคับ process
เมื่อมี Superpowers Claude มี path ที่แข็งแรงกว่า:
- clarify ก่อน build
- plan ก่อน edit
- test ก่อนมั่นใจ
- debug ก่อน fix
- review ก่อน handoff
Tradeoff คือช่วงเริ่มต้นอาจรู้สึกช้าลง แต่งานจริงมักคุ้ม เพราะ design ไม่กี่นาทีช่วยลด cleanup หลายชั่วโมง
Project แบบไหนเหมาะกับ Superpowers
Superpowers เหมาะที่สุดกับงานที่มี complexity จริง:
- new product features
- multi-file refactors
- CI failures
- production bugs
- migrations
- SDK integrations
- deployment changes
- codebase modernization
- agent-assisted open-source maintenance
สำหรับ copy edit เล็กๆ หรือ one-line change อาจไม่ต้องใช้เต็ม workflow แต่ verification ยังสำคัญ
คำแนะนำสุดท้าย
ถ้าคุณใช้ Claude ทำ development ให้มอง Superpowers เป็น process upgrade Model มี capability อยู่แล้ว Superpowers เติม discipline
Discipline นี้ทำให้ AI development ปลอดภัยขึ้นสำหรับโปรเจกต์จริง ลดการเดา เพิ่ม traceability และทำให้คำว่า done มีหลักฐาน ไม่ใช่แค่ vibes