AIDive

Paket video

Superpowers untuk Claude Code: tabel putusan, sumber, checklist, dan panduan lanjutan

9 menit baca

TL;DR

  • Superpowers adalah sebuah proses, bukan kotak perkakas: empat belas skill markdown yang mewajibkan setiap fitur melewati sesi brainstorming, rencana tertulis, dan rantai subagent baru, masing-masing direview.
  • Pasang kalau sesi Claude Code Anda mengerjakan fitur yang memakan waktu berjam-jam. Lewati kalau pemakaian Anda hanya skrip sekali pakai dan perbaikan dua baris: pemeriksaan awal jalan di setiap tugas dan tidak pernah mati.
  • Argumen soal token itu nyata, tetapi hanya datang dari satu bagian di satu skill: Model Selection. Orkestrator memberi tiap peran model termurah yang sanggup memegangnya, jadi model mahal hanya menyentuh arsitektur dan review branch terakhir.
  • Repo-nya sehat: 280,597 bintang, 25,138 fork, 681 commit di main, rilis v6.3.0 pada 2026-08-12, dibuat pada 2025-10-09.
  • Keluhan yang memicu video ini, statistik pemakaian di 1 sampai 3 persen, bukan bug: artinya skill tidak pernah terpicu oleh pekerjaan Anda, jadi Anda membayar gerbangnya tanpa mendapat apa-apa.
  • Jalan tengahnya cukup satu kalimat di prompt: suruh agent melewati proses pada perbaikan kecil, dan biarkan brainstorming saja berjalan beberapa hari sebelum mengadopsi sisanya.

Apa kata sumber

Angka repositori dibaca pada 2026-09-02: 280,597 bintang, 25,138 fork, dan 681 commit di branch main, dengan commit terakhir di main bertanggal 2026-08-12 (v6.3.0) dan push berikutnya pada 2026-08-31 ke branch non-main s1. Tab Issues menampilkan 125 issue terbuka hari itu; angka 350 dari API sudah termasuk 225 pull request terbuka, jadi kutip tab-nya, bukan API, saat membandingkan dengan plugin lain s6. Proyek ini dibuat pada 2025-10-09 dan membawa empat belas skill s2. Postingan peluncuran dari penulisnya menjelaskan taruhannya dalam satu baris: agent coding tidak kekurangan kemampuan, mereka kekurangan disiplin, dan disiplin itu bisa dibagikan sebagai file markdown biasa yang bisa dibaca, di-fork, dan diedit siapa saja s5. Plugin ini terdaftar di marketplace resmi, jadi instalasinya satu perintah dan pembaruan mengikuti marketplace s4.

Titik masuknya adalah sebuah skill yang dimuat hook awal sesi sebelum hal lain. Skill itu memberi tahu agent bahwa jika ada keraguan sekecil apa pun apakah sebuah skill berlaku, ia harus memuatnya dan memeriksa, sebelum menjawab atau menulis kode. Aturan itu sumber dari manfaat sekaligus biaya tetapnya s14.

Brainstorming dibuka dengan HARD-GATE: tidak ada kode, tidak ada scaffolding, tidak ada skill implementasi sampai Anda memvalidasi niat yang eksplisit. Lalu permintaan dipilah ke salah satu dari tiga jalur: spike, ketika hasilnya berupa jawaban dan bukan kode; bounded, untuk perubahan kecil di dalam alur yang sudah ada di repo; architectural, untuk apa pun yang menata ulang proyek. Agent mengumumkan klasifikasinya supaya Anda bisa membantahnya, dan ratchet-nya satu arah: kompleksitas tersembunyi yang ditemukan di tengah tugas menaikkan jalur, tidak pernah menurunkannya s9.

Skill penulisan rencana meminta rencana yang ditulis untuk developer kompeten yang tidak tahu apa-apa soal codebase Anda dan, dalam kata-kata file itu sendiri, berselera meragukan. Pekerjaan dipotong menjadi tugas yang setiap langkahnya makan dua sampai lima menit: tulis tes yang gagal, jalankan sampai terlihat gagal, tulis kode minimal, jalankan tes lagi, commit. Setiap tugas mencantumkan file persis yang dibuat atau diubah, sampai nomor baris, dan rencana dibuka dengan header wajib s10.

Eksekusinya adalah skill subagent-driven development: satu subagent baru per tugas, review setelah setiap tugas, review seluruh branch di akhir. Sesi utama berhenti menulis kode dan hanya mendelegasikan. Setiap subagent hanya menerima konteks tugasnya, tidak pernah riwayat sesi Anda, sehingga jendela konteks Anda tetap bebas untuk koordinasi. Setelah subagent mengimplementasi, menguji, commit, dan mereview dirinya sendiri, orkestrator menjalankan review dua bagian, kepatuhan terhadap spesifikasi lebih dulu, kualitas kode kemudian, dengan satu kursi reviewer disiapkan untuk setiap tugas. File itu membatasi loop paling banyak lima putaran per tugas s11. Isolasi pekerjaannya sendiri diserahkan ke skill worktree, jadi rencana tidak pernah berjalan di checkout Anda saat ini s13.

Bagian Model Selection dimulai dengan satu aturan: pakai model paling tidak mampu yang sanggup memegang peran itu. Tugas mekanis yang terspesifikasi baik dan menyentuh satu atau dua file diberikan ke model kecil; ketika rencana sudah memuat kode yang harus ditulis, implementasi hanyalah transkripsi plus tes, jadi tingkat termurah sudah cukup. Koordinasi banyak file dan debugging masuk ke model standar. Arsitektur dan review branch terakhir meminta model paling mampu yang tersedia. Dua detail penting dalam praktik: selalu sebut model secara eksplisit saat dispatch, dan biarkan orkestrator menilai tingkat kesulitan tiap tugas sebelum memilih s12. Inilah mekanisme yang membuat model mahal terjangkau di paket Pro dua puluh dolar: ia hanya bekerja pada keputusan yang pantas mendapatkannya.

Manfaat dokumentasi adalah efek samping dari prosesnya. Spesifikasi dan rencana bukan pesan chat yang hilang; keduanya file markdown yang disimpan di repo dan di-commit bersama pekerjaannya, jadi reviewer nanti membaca mengapa sebuah perubahan dibuat, bukan hanya apa yang berubah s3.

Biayanya adalah yang tidak diiklankan repo. Thread yang memicu video ini melaporkan statistik pemakaian 1 sampai 3 persen dan menanyakan apa kekurangannya selain tidak dipakai s7. Jawaban di dalam file adalah bahwa brainstorming menyesuaikan upacaranya dengan ukuran tugas tetapi tidak pernah melewati validasi manusia s9. Pada perbaikan dua baris, Anda tetap menjawab pertanyaan framing, menyetujui desain dua kalimat, dan menunggu siklus penuh. Brief dispatch, dua review per tugas, dan ledger pelacakan adalah token yang Anda bayar setiap kali, dan itu terlihat pada tugas terkecil. Statistik pemakaian rendah berarti skill tidak cocok dengan pekerjaan Anda, dan itulah sinyal sebenarnya yang perlu dibaca.

Putusan menurut pemakaian

Pemakaian Claude Code Anda Pasang? Alasan
Fitur yang memakan waktu berjam-jam, beberapa file, sebuah branch Ya Framing mencegah membangun hal yang salah, tugas pendek menjauhkan agent dari konteks yang jenuh, pemilihan model memperpanjang kuota, dokumentasi lahir dari prosesnya
Campuran: fitur di hari tertentu, perbaikan di kebanyakan hari Ya, dengan aturan lewati Pertahankan gerbang untuk fitur, suruh agent di prompt untuk melewati proses pada perbaikan kecil
Skrip sekali pakai, typo konfigurasi, perbaikan dua baris Tidak Biaya tetap gerbang berjalan pada tugas yang tidak membutuhkannya
Penasaran tetapi belum siap mengadopsi seluruh metode Brainstorming saja Ia membawa sebagian besar manfaat; skill lain menyambung secara alami sesudahnya

Lakukan ini hari Senin

  • Pasang dari marketplace resmi dan buka cache plugin: baca keempat belas file SKILL.md sekali, isinya pendek dan itulah seluruh produknya.
  • Jalankan satu fitur nyata melewati gerbang dari awal sampai akhir: brainstorming, rencana, dispatch subagent, review branch. Nilai prosesnya dari situ, bukan dari sebuah perbaikan kecil.
  • Cek statistik pemakaian Anda setelah seminggu. Di bawah beberapa persen, skill tidak cocok dengan pekerjaan Anda: entah tugas Anda terlalu kecil atau Anda perlu merumuskan permintaan sebagai fitur.
  • Tambahkan aturan lewati ke instruksi proyek Anda: pada perbaikan satu file di bawah beberapa baris, langsung ke perubahannya, tanpa brainstorming.
  • Salin tangga Model Selection ke prompt subagent Anda sendiri meski Anda membuang plugin-nya: sebut model secara eksplisit di setiap dispatch.
  • Commit spesifikasi dan rencana yang ditulis plugin alih-alih menghapusnya; itu catatan desain Anda.
  • Hitung issue terbuka di tab Issues, bukan dari angka API, sebelum membandingkan proyek ini dengan plugin lain.

Lanjutkan lebih jauh

  • Baca postingan peluncuran untuk maksud desainnya sebelum file skill: ia menjelaskan mengapa disiplin dibagikan sebagai markdown dan bukan sebagai kode s5.
  • Bagian filosofi di README adalah versi singkat metodenya dan tempat untuk memeriksa apakah cocok dengan cara kerja Anda s3.
  • Bagian pustaka skill mendaftar keempat belas skill dengan satu baris tujuan masing-masing; lebih cepat daripada menjelajah direktori s16.
  • Batas lima putaran per tugas di skill subagent adalah penghenti keras yang layak disalin ke orkestrasi apa pun yang Anda tulis tangan s11.
  • Sebuah thread menanyakan apakah plugin semacam ini bertahan di hadapan model yang lebih kuat; bagian yang bertahan adalah gerbang framing dan rencana yang di-commit, bagian yang diserap model adalah mekanikanya s19.
  • Laporan batas pemakaian mingguan yang terbakar oleh upacara orkestrasi adalah kasus tandingan yang perlu dibaca sebelum mengadopsinya untuk pekerjaan kecil s20.
  • Perbandingan dengan seperangkat instruksi pesaing menunjukkan pertukarannya: skill yang lebih sedikit dan lebih ketat versus katalog aturan yang besar s18.
  • Daftar issue terbuka adalah bacaan tercepat tentang apa yang rusak bagi pengguna lain hari ini s6.

Sumber

FAQ

Apakah Superpowers menghemat token atau membakarnya?

Keduanya. Pada fitur, pemilihan model mengirim tugas mekanis ke model kecil dan menyimpan model mahal untuk arsitektur dan review branch, sehingga kuota memanjang. Pada perbaikan kecil, brief, dua review per tugas, dan ledger murni overhead.

Apa arti statistik pemakaian 1 sampai 3 persen?

Skill hanya terpicu ketika sebuah situasi cocok dengannya. Angka rendah berarti tugas Anda bukan fitur dalam pengertian plugin ini, jadi Anda membayar pemeriksaan awal dan tidak pernah sampai ke bagian yang balik modal.

Bisakah saya mengambil sebagian saja?

Bisa. Brainstorming saja membawa sebagian besar manfaat, dan tangga Model Selection berfungsi di prompt subagent tulisan tangan mana pun. Suruh agent melewati proses pada perbaikan kecil dan kendali tetap di tangan Anda.