Plugin dengan 280.000 star
Superpowers adalah plugin untuk Claude Code yang ditulis oleh Jesse Vincent, yang sudah merilis tool open source untuk developer sejak tahun 1990-an. Dia merilisnya pada bulan Oktober, dan kurang dari setahun kemudian repo-nya sudah mengumpulkan 280.000 star dan 25.000 fork, dengan push terakhir masuk dua hari sebelum kami merekam. Proyeknya sudah berada di versi mayor keenam dengan 681 commit di branch main, jadi ini bukan kumpulan prompt yang ditinggalkan seseorang begitu hype peluncuran reda.
| Sinyal | Nilai |
|---|---|
| Star GitHub | 280.000 |
| Fork | 25.000 |
| Versi mayor | 6 |
| Commit di main | 681 |
| Issue terbuka | 125 |
Taruhan Vincent muat dalam satu kalimat: yang kurang dari coding agent bukan kemampuan, tapi disiplin. Disiplin itu dikirim sebagai file markdown biasa yang bisa siapa pun baca, fork, dan adaptasi. Kami menginstall plugin ini, membaca semua 14 skill-nya baris demi baris, dan melihat apa yang berubah di empat aspek: produktivitas, keandalan kode, konsumsi token, dan dokumentasi.
Apa itu Superpowers sebenarnya
Superpowers adalah plugin open source gratis untuk Claude Code. Dia tersedia di marketplace plugin resmi Anthropic dan install-nya cukup satu perintah. Metodologi yang sama tersedia untuk lebih dari selusin harness lain, termasuk Cursor, Codex, dan Gemini, masing-masing dengan cara install sendiri.
Intinya adalah 14 skill: file instruksi markdown yang dimuat agent setiap kali situasinya cocok. Brainstorming, penulisan plan, pengembangan lewat subagent, test-driven development, dan debugging sistematis masing-masing memuat satu cara kerja yang lengkap, dengan checklist dan pagar pengamannya sendiri. Skill debugging melarang mengusulkan perbaikan sebelum akar masalahnya terisolasi. Skill verifikasi memaksa agent membuktikan bahwa tugasnya selesai, bukan sekadar mengklaimnya. Tiap skill mengumumkan diri saat dimuat, jadi kamu selalu tahu agent sedang bekerja di mode apa.
Sebuah hook di awal sesi memaksa Claude mengecek, sebelum tiap tugas, apakah salah satu skill ini berlaku. Aturannya tertulis di skill pintu masuk: kalau ada peluang satu persen saja skill itu relevan, agent wajib memuatnya. Hasilnya berperilaku bukan seperti kotak peralatan, tapi lebih seperti metodologi pengembangan yang disuntikkan ke agent.
Vincent menceritakan asal-usulnya di blognya. Dia membangun skill-skill ini dengan menggali 2.249 file markdown berisi pelajaran yang dipetik agent-agentnya sendiri, lalu menguji draf-drafnya terhadap arsip yang sama. Metodologinya disarikan dari kegagalan agent yang nyata, bukan ditulis dari teori.
Brainstorming: gerbang sebelum ada kode
Brainstorming adalah skill yang dilewati semuanya. Begitu kamu meminta sebuah fitur, Claude memuatnya dan berperan sebagai pakar requirement selama percakapan pembingkaian berlangsung. Seluruh metodenya muat dalam satu file yang enak dibaca.
File itu dibuka dengan gerbang keras: tanpa kode, tanpa scaffolding, tanpa skill implementasi apa pun sampai kamu menyetujui niat yang eksplisit. Tidak ada yang dibangun berdasarkan firasat, dan gerbang itu berlaku untuk tiap tugas, sekecil apa pun kelihatannya. Skill ini lalu memilah tiap permintaan ke salah satu dari tiga jalur.
| Jalur | Definisi | Keluaran |
|---|---|---|
| Spike | Pertanyaan kelayakan | Sebuah jawaban, bukan kode yang kamu simpan |
| Bounded | Perubahan kecil pada alur yang sudah ada di repo | Perubahan dengan cakupan terbatas |
| Arsitektural | Apa pun yang menata ulang cara proyek tersusun | Spec yang kamu validasi, lalu plan implementasi |
Agent menyebutkan klasifikasinya secara terbuka supaya kamu bisa mengoreksinya, dan tuasnya hanya bergerak satu arah: kompleksitas tersembunyi yang ditemukan di tengah tugas menaikkan jalurnya, tidak pernah sebaliknya. File itu menyertakan tabel tanda bahaya, pikiran seperti "ini terlalu sederhana untuk butuh desain", dengan bantahannya tepat di sebelahnya: tugas sederhana justru tempat asumsi yang tidak diperiksa paling merugikan. Bahkan spike tetap punya pagar pengaman. Apa pun yang dibangun agent untuk menjawab pertanyaannya tetap berlabel sekali pakai, dan menyimpan kode itu menjadi permintaan baru yang harus diklasifikasi.
Selama dialog, agent mengajukan pertanyaan yang akan ditanyakan seorang lead engineer dan menyajikan desainnya dalam bagian-bagian yang mudah dicerna. Di pipeline kami sendiri, fase ini sudah mematikan fitur yang akan kami bangun dengan sia-sia.
Plan berisi tugas yang terlalu kecil untuk dihalusinasi
Skill penulisan plan dibuka dengan instruksi yang menentukan nadanya: tulis plan untuk developer mahir yang nol konteks soal codebase-mu dan, menurut kata-kata file itu sendiri, punya selera yang meragukan.
Konkretnya, pekerjaan dipotong menjadi tugas-tugas yang tiap langkahnya makan dua sampai lima menit: tulis test yang gagal, jalankan untuk memastikan dia gagal, tulis kode minimal yang meloloskannya, jalankan test lagi, commit. Satu aksi, satu verifikasi, dan pekerjaan maju lewat commit yang sering. Itu siklus test-driven development, yang dipaksakan oleh skill lain di plugin ini, jadi tiap tugas membawa siklus test-nya sendiri.
Tiap tugas mencantumkan file persis yang harus dibuat atau disentuh, sampai nomor baris. Plan dibuka dengan header wajib: tujuan dalam satu kalimat, arsitektur dalam dua atau tiga kalimat, tech stack, tautan ke spec, dan batasan global proyek yang disalin kata demi kata. Kalau spec mencakup beberapa subsistem independen, skill ini menuntut plan terpisah, satu per subsistem, masing-masing menghasilkan software yang bisa diuji sendiri.
Ukuran tugas adalah inti argumen keandalannya. Tugas yang pendek berarti agent menyelesaikan pekerjaannya dengan context window yang masih hampir kosong. Dia tidak pernah sampai ke momen saat sesi meluap, agent kehilangan benang merah, dan mulai mengarang fungsi yang tidak ada. Tidak ada demo lima menit yang memperlihatkan masalah ini, tapi dia menentukan segalanya di proyek sungguhan: kualitas agent di akhir sesi tidak ada hubungannya dengan kualitasnya di prompt pertama. Konteks yang kurang jenuh berarti halusinasi yang secara mekanis lebih sedikit, dan kode yang melakukan apa yang plan katakan.
Satu subagent per tugas, satu review setiap kali
Saat eksekusi, skill khusus mengisolasi pekerjaan di dalam git worktree, salinan kerja terpisah dari repo, jadi plan berjalan tanpa mengganggu apa pun yang kamu kerjakan di sebelahnya.
Skill eksekusi menggerakkan pengembangan lewat subagent. Prinsipnya muat dalam satu baris file itu: satu subagent baru per tugas, satu review setelah tiap tugas, dan review menyeluruh atas seluruh branch di akhir. Sesi utamamu menjadi orkestrator. Dia tidak lagi menulis kode, dia mendelegasikan. Tiap subagent mendapat persis konteks yang dibutuhkan tugasnya dan tidak pernah riwayat sesimu, yang menghindari polusi konteks dan menjaga window-mu sendiri tetap lega untuk koordinasi.
Subagent boleh bertanya sebelum mulai, lalu mengimplementasi, menguji, commit, dan me-review kerjanya sendiri. Setelah selesai, orkestrator menjalankan review dua bagian, kepatuhan pada spec dulu dan kualitas kode kemudian, dengan kursi reviewer khusus untuk tiap tugas. Tidak ada yang diimprovisasi: skill ini menyertakan template prompt untuk tiap peran (implementer, reviewer tugas, dan reviewer yang mengecek ulang perbaikan) yang diisi orkestrator dengan konteks tugasnya.
| Hasil review | Yang terjadi |
|---|---|
| Lolos | Orkestrator mencatat penyelesaiannya di ledger dan lanjut menyusuri plan |
| Gagal, ronde 1 sampai 3 | Implementer asli melanjutkan, karena dia sudah kenal kodenya dan pilihannya sendiri |
| Gagal, ronde 4 | Implementer baru dikirim di model yang lebih mampu |
| Gagal, ronde 5 | Pemutus arus menyala dan orkestrator sendiri yang memutuskan tiap temuan yang masih terbuka |
Skill ini juga menghindari ekses sebaliknya: rentetan tugas mekanis kecil dikirim sebagai satu grup dispatch, di-review sebagai satu unit. Tidak ada yang di-merge tanpa lolos reviewer. Hasilnya adalah apa yang tim manusia sebut proses code review, hanya saja berjalan sendiri, tugas demi tugas.
Model yang tepat untuk tiap tugas
Sistem dispatch membuka pintu ke kemenangan ketiga: ekonomi token. Skill ini punya bagian pemilihan model yang dibuka dengan satu aturan: pakai model paling lemah yang sanggup menangani tiap peran. Orkestrator menakar kesulitan tiap tugas dalam plan dan menetapkan model yang sepadan.
| Tugas | Tier model |
|---|---|
| Tugas mekanis yang terdefinisi jelas dan menyentuh satu atau dua file, atau plan yang sudah memuat kode yang harus ditulis | Tier termurah (implementasi menjadi sekadar salin plus uji) |
| Koordinasi lintas beberapa file, debugging | Model standar |
| Arsitektur, review branch terakhir | Model paling mampu yang tersedia |
File itu menambahkan dua detail halus. Pertama, selalu sebut modelnya secara eksplisit saat dispatch: subagent tanpa model mewarisi model sesimu, sering kali yang termahal, yang diam-diam mematahkan seluruh bagian ini. Kedua, jumlah giliran mengalahkan harga token. Model termurah butuh lebih banyak giliran pada pekerjaan berlangkah banyak dan akhirnya lebih mahal secara keseluruhan, itulah kenapa reviewer dan implementer yang bekerja dari prosa mendapat minimum satu tier di atas, bukan tier paling murah.
Setup ini membuat sesuatu yang kontra-intuitif menjadi layak: menjalankan Opus atau Fable, model termahal di katalog, di paket Pro seharga 20 dolar. Model mahal hanya mengerjakan sedikit keputusan yang layak untuknya, dan sisa plan berjalan di model yang memakan sepersekian kuotamu.
Plan yang di-commit: dokumentasi gratis
Kemenangan terakhir adalah yang tidak dipikirkan siapa pun saat menginstall plugin ini. Spec dan plan bukan pesan chat yang hilang begitu sesi berakhir. Mereka adalah file markdown yang tersimpan di dalam repo dan di-commit bersama pekerjaannya. Skill ini menetapkan lokasinya: folder plans bertanggal, satu file per fitur, dengan tujuan, arsitektur, dan tautan ke spec di header-nya.
Spec ikut bersama plan, dan konflik antara keduanya diputuskan berdasarkan spec: dokumen yang menjadi otoritas, bukan ingatan agent. Riwayat git tidak lagi sekadar memberi tahu apa yang berubah. Dia memberi tahu kenapa, dan apa yang agent putuskan waktu itu. Enam bulan kemudian, menyebut file plan itu di prompt membuat agent langsung memungut kembali konteks fitur aslinya, dan fitur baru yang menyentuh subsistem yang sama dibangun di atas spec yang sudah ada, bukan menjelajahi medan dari nol.
Tidak ada lagi yang namanya tugas tanpa jejak: semua yang agent lakukan di codebase meninggalkan dokumen, dari brainstorm pertama sampai commit terakhir. Proyek ini merangkum filosofinya dalam dua prinsip, sistematis di atas ad hoc dan bukti di atas klaim. Dokumentasi lahir dari prosesnya dengan sendirinya.
Biaya sebenarnya untukmu
Batasannya nyata dan repo-nya tidak mengiklankannya: semua disiplin ini punya biaya tetap, dan biaya itu tidak pernah padam. Skill pintu masuknya blak-blakan. Ada sedikit ragu saja, agent wajib memuat skill, dan file brainstorming menyatakan bahwa seremoninya menyesuaikan ukuran tugas, tapi persetujuan manusianya tidak pernah.
Untuk perbaikan dua baris, itu berarti menjawab pertanyaan pembingkaian, menyetujui desain dua kalimat, lalu menunggu siklus penuh sebelum kamu melihat perbaikannya. Untuk typo di file config, proses lengkapnya jelas lebih lambat daripada memperbaikinya sendiri. Orkestrasinya sendiri memakan token: brief dispatch, dua review per tugas, dan ledger dibayar setiap kali, dan paling terasa di tugas-tugas terkecil.
Ada gejala kebalikannya juga, dan ini menjawab langsung pertanyaan di Reddit. Kalau statistik pemakaianmu menunjukkan plugin ini di beberapa persen saja, permintaanmu hampir tidak pernah memicu skill-skill itu, jadi kamu membayar cek pintu masuk tiap sesi tanpa pernah menyentuh keuntungannya. Loop perbaikan yang berjalan lima ronde penuh berarti lima diff, lima review tambahan, dan satu arbitrase, untuk tugas yang seharusnya selesai dalam hitungan menit. Proyeknya juga tidak pernah diam: dia melompat dari versi pertama ke keenam dalam waktu kurang dari setahun dan masih punya 125 issue terbuka, jadi skill yang kamu baca hari ini akan berubah di update berikutnya.
Plugin ini merencanakan jalan keluarnya sendiri. Instruksinya menempatkan arahanmu di atas skill-skill itu, jadi kamu bisa bilang secara eksplisit ke agent untuk melewati prosesnya. Aturan kami: Superpowers aktif secara default untuk semua pekerjaan fitur, dan skip yang disengaja untuk perbaikan-perbaikan kecil.
Vonis kami
| Pemakaian Claude Code-mu | Vonis |
|---|---|
| Fitur yang makan berjam-jam | Install: pembingkaiannya mencegahmu mengimplementasi hal yang salah, tugas pendek menjauhkan agent dari kejenuhan konteks, pemilihan model meregangkan kuotamu, dan kamu mewarisi dokumentasi yang tidak akan pernah kamu tulis sendiri |
| Skrip sekali pakai dan perbaikan kecil | Lewati saja: kamu akan membayar biaya tetap proses untuk tugas yang tidak membutuhkannya |
| Di antaranya | Install dan belajar bilang skip: satu kalimat di prompt-mu mengembalikan kendali ke tanganmu |
Kalau kamu mau mencobanya tanpa mengadopsi semuanya, biarkan skill brainstorming saja yang berjalan selama beberapa hari. Dia membawa sebagian besar manfaatnya, dan skill lain menyusul dengan alami setelahnya. Plugin ini menepati empat janjinya selama kamu memberinya fitur yang layak untuk seremoninya. Sekarang dia berjalan di proyek-proyek kami sendiri, dan fase brainstorming adalah yang tidak akan kami matikan lagi. Repo-nya gratis dan open source, dengan 280.000 orang mengantre di depanmu.
AIDive