Maaaring gabayan ng Superpowers ang gumagamit ng Claude Code sa malaking pagbabago sa isang Git repository na pinamamahalaan niya: pagkasunduan ang disenyo, aprubahan ang plano ng gawain, ipatupad nang may mga test, suriin ang bawat gawain at inspeksiyunin ang natapos na branch. Sinusunod ng gabay na ito ang mga opisyal na manwal ng Superpowers 7.0.0 na sinuri noong 20 Oktubre 2026. Binasa ng BIG CHANGE ang dokumentasyon; hindi namin in-install ang plugin o pinatakbo ang isang proyekto sa proseso nito.

Ang malaking pagbabago

  • Ano ang nagbago: Ang aprubadong disenyo at plano ng implementasyon ay nagbibigay sa mga coding agent ng tiyak na gawain at limitasyon bago nila baguhin ang repository.
  • Bakit mahalaga: Pinagsasama ng dokumentadong daloy ang nakitang pagkabigo at pagpasa ng mga test sa magkahiwalay na hatol ng iisang tagasuri tungkol sa pagtugma sa espesipikasyon at kalidad, bago ang mas malawak na pagsusuri ng buong branch.
  • Ano ang babantayan: Tinitingnan pa rin ng may pananagutan ang buong diff at mga bagong resulta ng pagtanggap at siya ang nagpapasya sa branch. Maaaring may natitirang isiniwalat na problema kahit kumpleto ang daloy ng mga agent.

Bago magsimula

Pumili ng isang awtorisadong pagbabago sa code na may maraming hakbang sa repository na pag-aari mo o maaari mong baguhin. Dapat itong mahati sa mga gawaing kayang suriin at may asal na puwedeng subukan. Isulat ang hinihinging asal, apektadong bahagi, hindi sakop, orihinal na acceptance command at panimulang commit. Patakbuhin ang command at ang mahahalagang umiiral na check bago magsimula. Kung bigo na ang panimulang kalagayan, tukuyin ang kabiguang iyon ngayon; nangangailangan ang susunod na pula o berdeng resulta ng kilalang panimulang batayan.

Kailangan mo ng Git, isang authenticated na Claude Code, pahintulot mag-install ng plugin at gumawa ng branch o worktree, at sapat na plan o API capacity para sa Claude Code at mga subagent. Suriin ang patakaran ng organisasyon tungkol sa pag-access sa source code at paggamit ng plugin. Bago i-activate, basahin ang nilalaman ng plugin, aktuwal na pahintulot, tuntunin ng provider sa datos at kontrol sa paggastos. Nagbababala ang Anthropic na maaaring tumakbo ang mga plugin hook at server process sa iyong user privileges sa labas ng sandbox ng tool call; hindi sakop ng karaniwang paghingi ng pahintulot ng tool ang lahat ng code na iyon. Panatilihin ang mga lihim, dependency, panlabas na pagsusulat, push at release sa awtoridad na talagang mayroon ka. Ang dokumentasyon ng seguridad ng plugin ng Claude Code ay nagpapaliwanag sa hangganang ito.

Ginagamit ng landas sa ibaba ang kasanayan ng Superpowers na subagent-driven-development para sa pagbabagong may maraming gawain. Inilalarawan din ng mga manwal ang direktang landas na executing-plans at pinapayagan ang mas payak na kasunduan sa disenyo para sa maliit na trabaho. Piliin ang landas kasama ang may pananagutan bago magpatupad sa halip na ipagpalagay na kailangan ng lahat ng proyekto ang buong pagkakasunod.

1. I-install ang plugin at beripikahin ang aktibong bersiyon

Sa isang interactive na Claude Code session, ilagay ang command ng opisyal na marketplace:

Text
/plugin install superpowers@claude-plugins-official

Nagbubukas ang Claude Code ng panel ng detalye ng plugin bago i-install. Suriin ang laman at pumili ng pinahihintulutang scope. Ina-activate ito ng local scope para sa iyo sa repository na ito; naaapektuhan ng project scope ang mga setting ng repository ng mga katuwang. Basahin ang buod ng pag-install at tab na Errors. Sundin ang tagubilin ng session sa pag-activate o mag-restart, suriin ang tab na Installed at patakbuhin sa shell ang claude plugin list. Itala ang nakikitang Version, Scope at Status, at kumpirmahing magagamit ang mga kasanayan ng Superpowers sa aktibong session. Hindi ipinipirmi ng marketplace command ang research commit ng gabay na ito. Kung iba ang naka-install na bersiyon o teksto ng kasanayan sa 7.0.0, itugma muna ang proseso sa bersiyong iyon bago magpatuloy. Huminto kapag bigo o disabled ang pag-install; hindi iyon patunay na na-load ang workflow. Ang gabay sa pag-install ng Claude Code ay nagdodokumento ng mga check na ito.

2. Aprubahan ang disenyo, pagkatapos ang plano

Sabihin sa Claude Code ang totoong pagbabago, acceptance criteria, panimulang resulta at mga ipinagbabawal na pagbabago. Gamitin ang proseso ng Superpowers na brainstorming upang linawin ang layunin, mga pasya sa disenyo at mga limitasyon. Para sa pagbabagong ito na maraming hakbang, suriin ang nakasulat na disenyo at mga natuklasan ng builder check, lutasin ang mga tanong para sa may pananagutan at aprubahan ang buong paglalarawan. Dapat tukuyin ng pag-apruba ang asal na itatayo; hindi ito ipinahihiwatig ng patuloy na pagsasalita ng agent. Pinapayagan ng manwal ng disenyo ang mas simpleng kasunduan o tahasang pag-opt out para sa maliliit na gawain, kaya sadyang pagpili ito ng buong landas para sa malaking gawain.

Pagkatapos, hilingin sa prosesong writing-plans na gawing mga gawain ang disenyo. Suriin ang mga hangganan ng file, interface, pangkalahatang limitasyon, test command at Review Focus ng plano. Dapat sapat ang liit ng bawat gawain para ma-inspeksiyon, at dapat sukatin ng test ang napagkasunduang asal. Aprubahan ang plano at paraan ng pagpapatakbo ng subagent bago baguhin ang code. Ang manwal ng pagpaplano ay nagtatakda ng pagpasa ng trabaho. Ang kapani-paniwalang plano ay hindi pahintulot magdagdag ng dependency o baguhin ang mga file na walang kaugnayan.

Sa pagpapatakbo, ang using-git-worktrees ay naghahanap ng angkop na umiiral na workspace o naghahanda ng nakahiwalay na lugar nang may kinakailangang pahintulot. Itala ang aktuwal na branch, base commit at malinis na panimulang kalagayan. Gamitin ang katutubong suporta ng Claude Code para sa worktree kung mayroon. Kung may hindi kaugnay na pagbabago sa workspace, linawin muna kung sino ang may pananagutan. Ang manwal ng worktree ay naglalarawan sa pag-check at paggawa.

3. Obserbahan ang bawat test at pagrepaso sa gawain

Gamit ang aprubadong plano, gamitin ang subagent-driven-development para sa mga gawaing masusuri nang magkakahiwalay. Nagtatalaga ang kasalukuyang manwal ng implementer sa isang gawain, pagkatapos ay ipinapasa ang implementasyon at diff nito sa iisang tagasuri ng gawain. Nagbabalik ang tagasuring iyon ng dalawang hatol: kung tugma ang gawain sa espesipikasyon at kung katanggap-tanggap ang kalidad ng implementasyon. Dalawang hatol ito mula sa isang pagsusuri, hindi dalawang sunod na reviewer agent. Maaaring pagsamahin ang maliliit na gawaing magkakatulad ayon sa mga tuntunin ng manwal. Ang workflow ng gawain at ang prompt ng tagasuri ay nagtatakda ng pagkakasunod na ito.

Para sa bawat asal na angkop sa pagsubok muna, hingin ang nakikitang pulang-berdeng siklo: idagdag ang behavioral test, patakbuhin at makita ang inaasahang kabiguan; gawin ang pinakamaliit na implementasyon, ulitin at makitang pumasa; pagkatapos ay i-refactor habang pumapasa pa rin ang mga check. Ang import error o sirang test harness ay hindi ang inaasahang pulang resulta. Itabi ang command, output at kaugnay na commit o diff ng bawat gawain. Inilalarawan ng manwal ng development na ginagabayan ng test ang mga eksepsiyong nangangailangan ng kasunduan ng tao; ipinagpapalagay ng gabay na ito ang gawaing angkop sa karaniwang test-first na landas.

Basahin ang dalawang hatol at aktuwal na diff. Bago tanggapin ang gawain, lutasin ang anumang “hindi mabeberipika mula sa diff” gamit ang plano at repository. Suriin ang mga pagkukumpuni at kanilang nakatuong muling pagrepaso; ang panibagong pahayag ng tagumpay ay hindi bagong resulta ng test. Nililimitahan ng workflow 7.0.0 ang ikot ng pagkukumpuni at maaaring ipagpaliban ang mga natuklasan na may nakasulat na pasya. Itabi ang mga iyon para sa susunod na pagsusuri. Ang gawaing minarkahang kumpleto ay hindi nangangahulugang malinis ang pagrepaso.

Pagkatapos ng mga gawain, inspeksiyunin ang hiwalay na pagrepaso ng buong branch. Maaari nitong makita ang ugnayan ng mga gawain at balikan ang mga ipinagpalibang isyung hindi nalutas ng tagasuri mula sa isang diff lamang. Hingin ang ebidensiya at pasya sa bawat bukas na isyu. Itabi ang disenyo, plano, test output, ulat ng pagrepaso at buong diff bago linisin ang pansamantalang workspace ng plugin. Kung hindi na-trigger ang inaasahang kasanayan, suriin ang aktibong status at bersiyon ng plugin at ang dokumentadong paraan ng pag-diagnose; ang pag-install ay hindi patunay na ipinatupad ang daloy.

4. Suriin ang branch at piliin ang kahihinatnan nito

Patakbuhin muli ang orihinal na acceptance command sa huling code, kasama ang buong test suite ng proyekto. Inspeksiyunin ang bagong output, buong branch diff at lahat ng natitirang isyu. Ang manwal ng beripikasyon ng Superpowers ay nangangailangan ng ebidensiya mula sa kasalukuyang kalagayan bago sabihing kumpleto. Kung bigo ang suite, tukuyin ang eksaktong pagkabigo at kumpunihin o iwan ang branch para sa pagrepaso; hindi naaabot ang dokumentadong branch-finish menu kapag bigo ang suite.

Sa isang branch na may pangalan, ang finishing-a-development-branch ay nag-aalok ng local merge, push at paggawa ng pull request, o pag-iwan sa branch na hindi binabago. May mga pagpipiliang pull request at keep ang detached HEAD. Ang pagtatapon ay hiwalay na ginagawa pagkatapos lamang ng tahasang hiling ng may pananagutan at pag-type ng kumpirmasyon; hindi ito karaniwang ikaapat na opsiyon. Ang manwal ng pagtatapos ng branch ay nagpapaliwanag sa mga pagpipiliang ito. Ipakita sa may pananagutan ang mga check, diff at natitirang isyu bago siya magpasya. Kailangan ng naaangkop na awtoridad para sa merge, push, pagtanggal o release.

Ang kapaki-pakinabang na output ay isang branch na puwedeng suriin at nakaugnay sa orihinal na pangangailangan: aprubadong disenyo at plano, nakitang mga resulta ng test, parehong hatol sa gawain, pagsusuri ng buong branch, kumpletong diff at bagong resulta ng pagtanggap. Kung pinahinto ng pag-install, access, badyet o check ang pagtakbo, itabi ang napatunayang mga artifact at sabihin ang huling natapos na yugto. Inilalarawan ng dokumentasyon ang proseso; hindi nito pinatutunayang mas mabilis, mas mura o mas kaunti ang depekto ng pagbabagong hindi pinatakbo sa gabay na ito.

Mga sanggunian at karagdagang babasahin

Para sa mas makitid na pag-aayos ng isang acceptance check, tingnan ang gabay ng BIG CHANGE sa pagberipika ng isang bigong repository check. Nagsisimula nang mas maaga ang prosesong ito, sa disenyo at plano ng pagbabagong may maraming gawain.