시리즈 마지막입니다. 두 저자는 README 에서 같은 논점에 정반대로 답합니다. 한쪽은 프로세스 소유를 기능이라 부르고 다른 쪽은 결함이라 부릅니다. 외부에서 제기된 의식 비용 비판과 이 블로그의 기존 4부작이 같은 지점을 짚었다는 사실까지 정리하고, 언제 무엇을 쓸지 판단 기준을 제시합니다.

두 스킬셋은 TDD 에서 같은 말을 하지 않습니다. superpowers 는 리팩터링을 루프 3단계로 넣고 테스트 없이 쓴 코드를 삭제하라고 명령하며, mattpocock 은 리팩터링이 루프의 일부가 아니라고 못박고 테스트 지점을 사전 합의하라고 요구합니다. 구현·리뷰·디버깅·검증 단계를 원문으로 대조했습니다.

코드를 쓰기 전 생각을 정리하는 단계를 정면 비교합니다. superpowers 의 brainstorming 은 한 번에 한 질문씩 묻고 설계 문서를 커밋하며, mattpocock 은 같은 자리에 문을 세 개 두고 프론티어 단위로 묻고 아무것도 남기지 않습니다. 그리고 superpowers 에는 prototype 이 없습니다.

두 스킬셋의 가장 큰 차이는 스킬 내용이 아니라 발동 방식입니다. superpowers 는 SessionStart 훅으로 진입점 스킬 전문을 매 세션 강제 주입하고, mattpocock 은 훅이 0개에 25개 중 14개가 수동 전용입니다. 훅 스크립트를 해부하고 상시 토큰 비용을 실측했습니다.

코딩 에이전트 스킬셋 양대 산맥을 5부작으로 비교합니다. 1편은 지형도입니다. 두 저장소를 실제로 설치해 재 보니 총 분량이 2,949줄과 2,945줄로 거의 같았고, 차이는 크기가 아니라 배치였습니다. 단계별 대응표와 양쪽이 비워 둔 자리를 정리합니다.

Superpowers 의 스킬들은 대부분 자동 트리거되지만, 의도적으로 명시 호출(/superpowers:xxx)해야 더 잘 작동하는 케이스도 있습니다. 4편에서는 두 모드의 비교, 트러블슈팅, CLAUDE.md 로 동작을 조절하는 방법, Java/Go 백엔드 개발 현장의 실용 팁과 한계를 정리합니다.

Superpowers 의 가장 강력한 부분은 “규율을 강제하는” 품질 보증 스킬들입니다. 3편에서는 TDD Iron Law, 4단계 systematic debugging, verification-before-completion, code review 흐름을 Java 프로덕션 버그 시나리오와 함께 분석합니다.

Superpowers 의 핵심은 “기능을 만들자"는 한 마디로 시작되는 자동 워크플로우입니다. 2편에서는 brainstorming → writing-plans → subagent-driven-development 의 흐름을 Go 백엔드 API 추가 시나리오와 함께 따라가 봅니다.

Claude Code, Codex 등 코딩 에이전트에 “바로 쓸 수 있는 개발 방법론"을 주입하는 Superpowers 플러그인. 1편에서는 무엇이고 왜 만들어졌는지, 어떻게 자동 트리거되는지, 그리고 어떤 환경에 어떻게 설치하는지를 정리합니다.