เมื่อไรคุณต้องใช้ Superpowers จริงๆ?
คุณต้องใช้ Superpowers เมื่อ cost ของ agent ที่เร็วแต่ผิด สูงกว่า cost ของการชะลอเพื่อทำ process ให้ถูก
นี่คือคำตอบแบบ practical
ถ้างานเป็น copy edit หนึ่งบรรทัด methodology เต็มอาจไม่จำเป็น แต่ถ้างานแตะหลายไฟล์ เปลี่ยน product behavior กระทบ deployment เกี่ยวกับ bug หรือต้อง verify process สำคัญมาก
Superpowers มีประโยชน์เพราะมันให้ library ของ specialized skills กับ agent Agent ไม่ต้องมองทุก task เหมือนกัน Bug ควร trigger debugging behavior Feature ใหม่ควร trigger design และ planning behavior Branch ที่จบควร trigger verification และ handoff behavior
ใช้ Superpowers เมื่องานมี engineering risk จริง
สัญญาณที่ชัดที่สุดคือ risk
ใช้ Superpowers เมื่อ:
- change ที่ผิดอาจทำให้ behavior เดิมพัง
- มีหลายวิธี implementation
- ต้อง preserve user work
- agent อาจแก้มากกว่าหนึ่งไฟล์
- tests, builds หรือ deployment checks สำคัญ
- root cause ยังไม่ชัด
- task อาจยาวกว่า exchange สั้นๆ
- ต้องการ plan หรือ handoff ที่ review ได้
นี่ครอบคลุมงาน software จริงส่วนใหญ่ เช่น feature ใหม่ bug fix refactor CI failure migration integration และ deployment change
เมื่อไรอาจไม่ต้องใช้ full workflow
ไม่ใช่ทุก task ต้องใช้ process หนัก
อาจไม่ต้องใช้ full Superpowers workflow สำหรับ:
- แก้ spelling
- copy change เล็กๆ
- read-only explanation
- format snippet ที่รู้ชัด
- ตอบคำถาม concept
แต่ถึงอย่างนั้น agent ยังต้อง preserve user changes และไม่ claim โดยไม่มีหลักฐาน งานเล็กไม่ได้แปลว่าทำแบบ careless ได้
เลือก skill อย่างไรให้เหมาะกับสถานการณ์
Superpowers เข้าใจง่ายขึ้นถ้าเลือก skill จาก failure mode ถามว่าเรากำลังป้องกัน mistake อะไร
ใช้ brainstorming เมื่อ goal ยังไม่ชัด
ใช้ `brainstorming` เมื่อ request ยัง rough, เกี่ยวกับ product หรือ open-ended
Trigger ที่ดี:
- “Build dashboard ให้หน่อย”
- “เพิ่ม monetization”
- “ทำ tool นี้ให้ดีขึ้น”
- “สร้าง course page”
- “อยากให้ user convert มากขึ้น”
Risk คือ build ของผิดอย่างรวดเร็ว Brainstorming ช่วยให้ agent ถามคำถาม สำรวจทางเลือก และเสนอ design ก่อน code
ใช้ writing-plans เมื่อ goal ชัดแล้วแต่ execution ยังไม่ถูก map
ใช้ `writing-plans` หลัง design ชัด แต่ก่อน edit files
Trigger ที่ดี:
- ต้องแก้มากกว่าหนึ่งไฟล์
- implementation มี dependency
- ต้องเพิ่ม tests
- developer คนอื่นอาจ review
Risk คือ implementation drift Plan ให้ track ที่ agent เดินตามได้
ใช้ using-git-worktrees เมื่อ isolation สำคัญ
ใช้ `using-git-worktrees` เมื่องานควรแยกจาก main workspace
Trigger ที่ดี:
- feature branch ใหญ่
- refactor เสี่ยง
- experiment
- parallel agent work
- change ที่อาจ discard
Risk คือ mix งานไม่เกี่ยวกัน หรือ rollback ยาก
ใช้ test-driven-development เมื่อ behavior เปลี่ยน
ใช้ `test-driven-development` เมื่อ agent implement behavior, fix bug หรือ refactor logic
Trigger ที่ดี:
- “Add validation”
- “Fix calculation”
- “Refactor parser”
- “Prevent regression”
Risk คือ fake confidence TDD บังคับให้ agent พิสูจน์ behavior ก่อนและหลัง change
ใช้ systematic-debugging เมื่อมีบางอย่างผิด
ใช้ `systematic-debugging` กับ bugs, failures และ unexpected behavior Superpowers debugging skill เน้น root-cause investigation ก่อน fixes อ่านได้ที่ systematic-debugging/SKILL.md
Trigger ที่ดี:
- failing tests
- production bugs
- build failures
- broken integrations
- intermittent behavior
- repeated failed fixes
Risk คือ patch stacking Agent อาจใส่ fix ที่ดู plausible ซ้อนกันโดยไม่เข้าใจ system
ใช้ verification-before-completion ก่อนคำว่า “done”
ใช้ skill นี้ทุกครั้งที่ agent กำลังจะ finish
Trigger ที่ดี:
- “It should work now”
- “I pushed it”
- “The fix is complete”
- “Ready to deploy”
Risk คือสับสนระหว่าง edited code กับ verified behavior
Completion report ที่ดีควรบอกว่า test อะไร run แล้ว pass อะไร และอะไรยังไม่ได้ verify
ใช้ executing-plans สำหรับงานยาวแบบ sequential
ใช้ `executing-plans` เมื่อมี plan แล้วและ tasks พึ่งพากัน
Trigger ที่ดี:
- migrations
- page redesigns
- multi-step feature builds
- cleanup plans
- staged refactors
Risk คือหลุด sequence Batch execution พร้อม checkpoints ช่วยให้ agent อยู่ใน track
ใช้ subagent-driven-development สำหรับ work streams ที่ independent
ใช้ `subagent-driven-development` เมื่อ tasks independent และ environment รองรับ subagents
Trigger ที่ดี:
- components ที่แยกกัน
- test-writing และ implementation review คู่ขนาน
- inspect codebase ขนาดใหญ่
- independent issue fixes
Risk คือ context overload Agents ที่แยก task ช่วยให้ context เล็กลงและ review กันได้
ใช้ requesting-code-review ก่อน handoff
ใช้ `requesting-code-review` เมื่องานไม่ trivial
Trigger ที่ดี:
- เตรียม PR
- high-risk change
- unfamiliar codebase
- UI หรือ API behavior ซับซ้อน
Risk คือพลาด quality problems เพราะ code แค่ compile ผ่าน
ใช้ receiving-code-review เมื่อมี feedback
ใช้ `receiving-code-review` เมื่อ human หรือ reviewer comment งาน
Trigger ที่ดี:
- PR review feedback
- inline comments
- requested changes
- architecture concerns
Risk คือแก้ comment แบบ mechanical โดยไม่เข้าใจ point ของ reviewer
ใช้ finishing-a-development-branch เมื่อ implementation เสร็จ
ใช้เมื่อ coding work เสร็จและขั้นต่อไปเป็น operational decision
Trigger ที่ดี:
- merge หรือ PR decision
- keep/discard branch decision
- deployment handoff
- cleanup หลัง worktree
Risk คือทิ้งงานไว้ใน state ที่ไม่ชัด
ใช้ writing-skills เมื่อ agent mistake เกิดซ้ำ
ใช้ `writing-skills` เมื่ออยากเปลี่ยน repeated pattern ให้เป็น reusable agent behavior Superpowers guide มอง skill-writing เหมือน test-driven development สำหรับ process documentation อ่านได้ที่ writing-skills/SKILL.md
Trigger ที่ดี:
- “Agent ชอบ skip เรื่องนี้”
- “เราต้องเตือนมันทุกครั้ง”
- “Process นี้ใช้ข้าม project”
- “ทีมเรามี standard way”
Risk คือพึ่ง memory แทนที่จะทำ workflow ให้ reusable
Use cases ตามบทบาท
Solo developer
ใช้ Superpowers เพื่อลด cleanup value ใหญ่ที่สุดคือบังคับ agent ให้ plan test และ verify ก่อน claim success
Startup founder
ใช้ Superpowers เมื่อต้อง build MVP features, landing pages, tools และ internal dashboards มันช่วยแปลง business intent เป็น implementation steps
Agency หรือ development team
ใช้ Superpowers เพื่อ standardize agent workflow ข้าม client projects Skills สามารถ encode review standards, deployment rules และ debugging habits
Open-source maintainer
ใช้ Superpowers สำหรับ issue triage, PR review, regression tests และ branch hygiene
AI-heavy builder
ใช้ Superpowers เพื่อกัน long autonomous sessions drift ยิ่ง session ยาว process ยิ่งมีค่า
General skill สำหรับทุก coding agent
Superpowers เป็น framework ที่ rich มาก แต่บางครั้งคุณอาจต้องการ skill เล็กกว่าและ platform-neutral ที่ใช้กับ coding agent ไหนก็ได้
เราเตรียม starter skill ให้ดาวน์โหลด:
Download disciplined-coding-agent/SKILL.md
Skill นี้ตั้งใจให้ general มันบอก agent ให้เข้าใจ scope, inspect ก่อน edit, plan small, debug by root cause, test ก่อน completion และ report ด้วย evidence
ใช้ได้กับ Claude, Codex, Cursor-style agents, Gemini CLI, OpenCode หรือ environment ใดๆ ที่รองรับ markdown-based agent instructions
วิธี install general skill
Path ที่แน่นอนขึ้นกับ tool แต่แนวคิดง่าย:
- สร้าง skills directory ถ้า agent รองรับ
- เพิ่ม folder ชื่อ `disciplined-coding-agent`
- save file ที่ดาวน์โหลดเป็น `SKILL.md`
- restart หรือ refresh agent session ถ้าจำเป็น
- ขอให้ agent ใช้ skill นี้กับ implementation, debugging และ verification tasks
สำหรับ Codex-style environments ที่รองรับ shared agent skills pattern ที่พบบ่อยคือ:
- `~/.agents/skills/disciplined-coding-agent/SKILL.md`
สำหรับ tool อื่น ให้ใช้ skill หรือ instruction directory ตาม documentation ของ tool นั้น
คำแนะนำสุดท้าย
ใช้ Superpowers เมื่องานสำคัญพอที่ process สำคัญ
ยิ่ง task ซับซ้อน agent ยิ่งควรมี skill ถ้า agent ต้องเข้าใจ เปลี่ยน test review และ handoff software อย่าพึ่ง prompt อย่างเดียว
ให้ workflow กับ agent นั่นคือหัวใจจริงของ Superpowers