obra

Spec first, tests first, then parallel agents: what I changed after months with obra/superpowers I write most of my code with Claude Code these days. For a long time my workflow was built on obra/superpowers, a plugin of skills that steers the agent through brainstorming, planning and test-driven development. It changed how I work, and it's still a great place to start. After a few months I had a list of things I wanted to work differently. That list became pasadena, a Claude Code plugin for spec-driven development. This post explains what it does and why. The problem: context that lives nowhere A spec says what you intend to build. Git history says what you merged. Neither says where the work stopped, what you already verified, or which file to open next. With agents it gets worse: every new session starts cold, and you spend the first ten minutes explaining everything again. Pasadena keeps that context in a journal file on the task branch, .pasadena/journal/<branch>.md. It has three sections: the goal; what's happening now (current phase, blocker, the next concrete step with a verification command); and an append-only timeline. Hooks restore the journal at session start, log new commits, and mark pauses and failures. Before merge, the useful summary moves into the PR description and the file is deleted. Built for worktrees Pasadena is designed around git worktrees: one task, one branch, one worktree. For architectural work, sheldon creates the worktree, the journal and a draft PR right away, so several tasks can run side by side without stepping on each other, and each one keeps its own journal on its own branch. The workflow /pasadena picks up from whatever stage the branch is at. Under the hood it hands off to one of nine skills: | Skill | Job | |---|---| | sheldon | Asks focused questions and writes an agreed spec | | penny | Builds 2–4 browser prototypes for a UI decision | | leonard | Splits the spec into tasks and parallel waves in plan mode | | wolowitz | Runs the waves, verifies and commits each task, reports on the PR | | amy | Failing tests first; proof from a fresh run before "done" | | leslie | Root cause in four phases before any fix | | bernie | End-to-end check in the browser, or a lasting Playwright test | | stuart | Screenshots at several widths and a report of layout defects | | raj | Starts, resumes, hands off and closes the journal | What I changed compared to superpowers 1. Plan mode for the plan. Once the spec is agreed, leonard writes the plan inside Claude Code's native plan mode. I review and approve it like any other plan, and nothing runs before that. 2. Codex as a helper, not a replacement. If the Codex CLI is installed and logged in, skills delegate three kinds of work to codex exec: bulk code lookups that come back as facts with file:line; an extra review of the whole branch; and plan tasks explicitly marked for Codex. Claude stays the orchestrator and only counts findings it has confirmed itself. The main motivation is saving Claude usage on routine work. 3. Spec-driven and test-driven in one pipeline. The spec sets the acceptance criteria. amy turns them into failing tests before any production code, then takes each step through its own failing test. Nothing counts as done without a fresh test run. 4. Parallel subagents without collisions. Every task in the plan declares the files it touches. leonard groups tasks whose file sets don't overlap into waves. wolowitz runs each wave in parallel, with a separate test writer and implementer per task, verifies it, commits every task, and reviews every third wave plus the whole branch at the end. 5. Work happens in the open, on a draft PR. The draft PR is opened at the start and carries the spec. While the work goes on, progress is commented on the PR as commits land, so the PR itself shows what was built, in what order and how it was verified, long before it's ready for review. Trying it /plugin marketplace add dmytro-rudenko/pasadena /plugin install pasadena@pasadena Requirements: bash, git, jq, and Node.js for browser prototypes. The plugin works on its own, but it works best together with the Codex CLI and microsoft/TokenEconomizer: Codex takes over part of the work, and TokenEconomizer helps spend fewer tokens. Wrapping up I use pasadena every day, and it covers everything I need in development. It keeps evolving. But that's one person's view, so I'm genuinely curious how it works for others. Any feedback is welcome, here in the comments or in issues on GitHub.

バイブコーディングで機能を継ぎ足していて見えてきたClaudeCodeの実装のクセ 「業務フローがよくわからないんだよね」という状態でも、チャラくバイブコーディングで自力でシステムが作れる時代が来ました。特にエンジニアは、アイディアをすぐに形にできます。普段からClaude CodeなどのAIエージェントに慣れ親しんでいれば、バイブコーディングのハードルは数ミリ程度まで下がっています。その結果、要件定義できるほどの解像度はない、できてからいろいろ意見はしたい、でも人の介在は最小限にしたい、という ガチのシステム屋さんに言ったら殴られそうな 要望を持つことも多いでしょう。 TL;DR 要件が固まらないままClaude Codeでバイブコーディングしたら、テストは通るのに画面ごとに数字や挙動が食い違った AIは依頼された画面の周りしか読まず、全体像や過去の経緯は勝手に把握してくれない 防ぐには、概念台帳・画面一覧・型とフックなどを人間が先に用意する必要がある 生成AI時代こそ、全体を設計して指揮するPMスキルが必須になる 何をどう作っていたか 開発対象 売上計画を立てられる社内システムです。月次の売上と在庫の見込み、売上計画、受注一覧、請求、入金、商品マスタ、顧客を扱います。 受注一覧 → 請求 → 実績 → 入金 → 現預金 → 粗利 といった流れでお金が流れる想定です。取引数や管理対象がまだ少ない段階で、事業計画を立てるためにシミュレーションをしたいという背景で作りました。 開発フロー 小規模なアプリ用に社内でテンプレートを作って、それをベースに開発していました。 工程 人 AI P1 要件整理 → Issue 一言で頼み、5つの質問に答える 5問を聞く → 要件メモ → Issueを起票 P2 実装 - 失敗するテストを書く → 最小の実装 → 整理 P3 品質ゲート → PR - format、lint、型、テスト、ビルド → PR作成 P4 レビュー → merge PRを読んでmerge （任意）AIレビュー P1の要件定義の5つの質問は、誰のためか、どの痛みか、なぜ今か、やらないこと、完成の定義です。superpowersのブレインストーミングを使っていて、質問の選択肢もAIが出してくれるので、適当に選びます。 管理していた文書 置き場 中身 00_process/ 開発フロー、矛盾を防ぐ進め方など 01_product/ デザインの指針、システム自体の細かい方針 02_architecture/adr/ ADR（設計判断とその理由の記録） 要件メモ/ 5問の答えから作ったメモ packages/shared/src の型とコメント 実質の仕様はここ（約1.8万行） 「要件メモ」の中にsuperpowersで作られる要件定義の資料はできあがります。ただ、今回のように「作りながら要件が固まる、変更がある」「最初に業務フロー全体像が見えていない」といった場合、途中で変更すると矛盾が生じます。AIが毎回このメモを更新して、唯一の正（SSOT）として活用してくれるわけではないからです。 大まかな欠点としては、 ドメイン知識や言葉が指示でぶれると、システムの中でもぶれる→概念台帳や用語集が必要 画面単位で改修をすることが多いので、既存実装の全体像を知らないまま重複して実装したり整合性が崩壊したりする→画面一覧などの一覧性のあるドキュメントが必要 といったところでしょうか。 この開発方法でぶちあたった課題 ざっと表にまとめてみました。 画面 何が食い違ったか 売上計画と受注一覧 途中で計画機能を追加した結果、受注の金額を計画でも一覧でも入力できるようになり、システム上で整合性がとれず画面ごとに数字がずれた。 請求 もともと税抜きで計算していたが税込にした。請求だけ税込への変換から漏れて、金額がずれた。AIは税金の扱いをコード上のコメントで管理していたらしい。 請求 入力を小数にするか整数にするか指定しなかったため、小数の入力ができなかった。（外注費はできるが売上はできない、といった挙動だった） 受注一覧 ページ構成を変更した時（入力が2か所あった箇所を、片方読み取り専用にして導線を整理した）、並び替え機能が消された。（ADRには並び替えの実装記録はあった） 画面全体 画面全体の書き出しと読み込みの機能について、実装している画面としていない画面があった（共通ルールになっておらず、途中で付け足した機能だったため）。さらに、実装が別々に書かれており整合性が崩れていた。 画面全体 畳める説明文の部品、記憶の読み書き、CSSのクラス名が重複して、結果的にデザインに統一性がない箇所がちらほらあった。共通部品の置き場までは定まっておらず、作る前に探す手順も定義されていなかった。 ADRで常に決定は残しておいたのですが、それでも矛盾が生じました。テストはそこそこ書いてくれていたのでCIは緑のまま、触ってみて「oh……」となりましたね。 あと細かいところだと、保守性の面で、特にフロントエンドはアーキテクチャを指定しても無視して1ファイルに書き始めたり、UI/UX的な考慮はされず横にたくさんスクロールが必要な表ができたりもしました。 AI（Claude Code）の実装のクセ AIの実装手順はこんな感じであろう 「売上計画に見込みの列を足して」と言った時の挙動は以下のようです（Claude自身が認識している方法ですが）。 必ず読む。CLAUDE.md、AGENTS.md、.claude/rules/ 言葉でgrepして対象のファイルを探す。「売上計画」「見込み」でgrepして、画面のファイルを開く importをたどる。開いたファイルから数段だけたどり、共通の計算関数を読む ADRや別の画面（受注一覧）は読まないことが多いようです。また、読む量が多すぎると、1で読んだはずの規則は華麗に無視してきます。こういうしくみなので、決めてから一気に組み上げるのには強く、運用ややりながら考えるのには弱い、という印象になるんですね。当たり前ですが、使っていると「なんでそんなこともわからんのだ……！」という気持ちになります。 ADRを読んで全体と経緯を把握してくれるわけではない 同僚が使っているClaude DesktopはADRを書いて設計したがり、指示をせずともADRを勝手に書いていました。が、Claude Codeで開発する時はあまりそんな気遣いは望めません。今回はAGENTS.mdに「ADRは必要になったら読む」くらいに書いていたのですが、常に読むわけではなく、読むとしてもgrepした結果の画面と関連がありそうなADRだけのようです。経緯を全部把握してくれる、みたいなことは期待しちゃいけない。さらに、後のADRが前の判断を覆している場合、そこまで読んでくれないこともあります。 IQというか処理能力が高くて知識も豊富だけど、めちゃくちゃおっちょこちょいでせっかちなジュニアの同僚、みたいな感じですね。 AIはシステムの全体像を勝手に把握するわけではない これも勝手にCLAUDE.mdとか何かしらからよしなに読むでしょ、と思っていました。人間でも最初に全体像がわかるようなドキュメントを読むじゃん。読まないんですよ。Claudeちゃんは究極のものぐさなので。 ユースケースなどの全体像がわからないと、業務の流れがわからないまま画面単位で追加の実装をはじめます。さらに、 セッションごとに記憶が切れる。前の画面で決めた流れは、書いていなければ残らない コードは画面単位（〜-board.tsx）に分かれている。読めるのは画面で、流れは読めない 受入条件は依頼された画面の中で閉じてしまい、AIが全体整合性をとらない といった特徴があります。E2Eテストをがんばればいいという話もありますが、結局人間が指示をちゃんと言語化しきらないといけないのは変わりません。 少なくとも要件定義で十分な情報をAIに言語化させて、全体像がわかる形でドキュメントにしておくことが必要です。 フロントのファイル分割ルールは無視するもの 部品の二重実装は、フロントのファイル分割を先に決めていれば防げる……そう思っていた時期が私にもありました。 Feature-Sliced Designを採用して、公開はindex.tsだけ、とルールを作ったのですが、何を思ったのかClaudeちゃんの実装は components/ に19ファイルが平置き（FSDガン無視） 受注一覧の画面が1ファイル2,110行、トップページが1,455行で、1画面を1ファイルで記載 CSSは1ファイルに2,382行で、分割する気0 features/ は2つだけで、共通部品を作れていない というポンコツっぷり。 AIは自らハーネスを作れない AIは自分の癖を把握して事前に防ぐ、といった気遣いはしてくれません。以下のような内容はハーネスとして準備しないと矛盾が起きる可能性があります。AIが苦手とする箇所ですね。 内容 対策 言葉の二重定義 正式な名前とコード上の名前を識別子つきで1か所で定義して、そこに無い識別子をhooksなどで検査する 値の表し方の揺れ 型で1本に縛る。空はnullだけ、単位は別の型にする、種別はunion型と一覧の1か所定義にする 計算の重複、および丸めなどの扱いの揺れ 計算をドメインの1関数に寄せて、画面のファイルからの計算関数のexportを禁止する。（可能ならDDDっぽい設計に寄せれば解決する） 数字の複数箇所での管理。入力口が複数になるとか、画面で再計算して結果がずれるなど 保存先に書き込める画面を1つに制限する。ほかの画面はドメインの結果を表示するだけにする 重複した実装をする 厳密なレイヤーおよび置き場の定義を行い、違反はlintで落とす 文書どうしが食い違う。台帳と実装がずれる 概念を足したら台帳に追記することをフックで強制する。文書の参照関係を検査する 特にアーキテクチャの面では、フロントエンドはかなり弱い印象があります。「自動で適切なものを選んで」ではなく、明示的に方針を指定したり、最初に雛形を用意してコンテキストに含めてあげたりする必要があるでしょう。 どう実装すればよかったか 社内でさくっと開発する、実際に使うまで細かいフローはわからん、といった状況の場合、 概念台帳および用語集 画面一覧と画面遷移 最低限の型とフック 受入条件（AC）をしっかり記載した実装用チケット 可能なら適度な粒度のアーキテクチャを実装したボイラープレート があるといいと思います。特に上の3つについて詳しくみます。 概念台帳と用語集 Spec駆動で開発しているつもりでも、途中で解像度が上がってくるとか、仕様自体が利用者の反応で変わるといったケースはあると思います。そうなるといつの間にかコードが正になり、背景や判断基準はADRを辿る必要がでてきます。また、指示する時の雰囲気で使う用語が変わると、AIはそれらを別物として扱ってしまいます。 とはいえ、がっつり要件定義ドキュメントを作るよりはAIに任せたい、といった場合、最低限「概念台帳」として、どこにどんな概念を置くかを管理しておくとよいです。 概念 正の置き場 表し方 単位 入力か導出か 受注の売上 受注一覧 小数を許す 税込、発生ベース 入力 ユースケースや業務フローから機能一覧を記載できると一番良いですが、結局その文章の整合性をとるには人間の時間と能力、そして経験が一定必要になってしまうので、社内でさくっと開発するには向かない感じがします。 画面一覧と画面遷移 画面と、その画面にある機能の一覧を1つのファイルで記載します。また、画面遷移もファイルにします。がっちがちの画面設計にする必要はなく、画面名、その画面でできること、入力か表示かあたりがあればいいでしょう。画面遷移もテキストの説明で十分です。 AIは依頼された画面のファイルから読み始めて、importを数段たどるだけなので、全体整合性をとるのが苦手です。毎回これらのファイルを読ませれば、全体の流れとしての不整合は防げます。ただし、これだけでは数値の丸め方など細かい規則まではフォローできないので、先の概念台帳と用語集のようなプチドメイン設計を併せてするとよいでしょう。 最低限の型とフック 文章で書いたルールはコードを読んでいるうちに忘れやがるので、静的検査で落とせるタイプのものはなるべくテストで落とすのも大事です。型がしっかりしていれば「ありえない値」などもある程度落とせるので、AIのゆるふわテストでもある程度は動くプロダクトになります。 全体を通して 今回の失敗から、「大規模開発だと生成AIの活用がうまくいかないよね」という話と同じ構造が見えました。大きく以下のような観点があると思います。 全体像が膨大で把握しきれない状況での、チームでの開発（人間のチームなのか、Claudeのセッションやサブエージェントなのかは違いますが） 要件定義フェーズをどう進めると抜け漏れが減るか、さらに抜け漏れがある前提でどう進めると事故が減るか 保守しやすいソフトウェアアーキテクチャなんかも大事ですが、いわゆる優秀なPMが今まで担ってきた内容が、生成AI時代に必須になっているように感じます。並列で動かす時はgit worktreeを使おうね、くらいは個人のエンジニアでもわかりそうですが、こういった全体の進め方についてはまだまだAIに全任せとはいかず、「知見と経験がある人がAIを使って全体をディレクションする」必要があるように思います。私は過激派なので、エンジニア経験のある人がみんなPMスキルを身につけるべき時代がくるぞとよく言います。できないPMの下でもやもやしていた実装経験のある人、今こそ輝くチャンスだぞ。あなたたちの力は絶対に未来に必要だ。 ちなみに 私はうぐいすソリューションズという会社を経営しています。弊社には役員が私含めて2人いて、それぞれ「要件定義からチーム開発をうまくいかせる鬼」と「技術全体像と適切なアーキテクチャ、そして状況整理マニア」という特性をもち、どちらも言語化に異常な執着があります。こういった知見をどんどん伝えてまともにPMができる人を増やそう、ある程度の再現性のある妥当で安心できるシステム開発をしよう、という組織なので、もし興味がある方がいればコーポレートサイトからぜひお問い合わせください。 uguisu-solutions.com カジュアルに話を聞いてみたい、PMやばい話を聞きたい、生成AI時代の愚痴が言いたいなど、なんでも結構です。同じ思いのある人で広く世の中をよくしていけたらな、という気持ちで、連絡をお待ちしています。

obra/superpowers and ovid/paad together work well for me flow is sp:brainstorm paad:pushback sp:write-plan paad:alignment sp:subagent-implementation - both have other useful skills in them but that is main flow

Make Claude Code design, plan and test before it writes code Ask Claude Code for a feature and it usually starts typing code in the first reply. Sometimes that works. Often you get a half-guessed design, no tests, and an hour of rework. Superpowers fixes that by giving your coding agent a full development method as a set of skills: it asks what you want first, writes a design you sign off on, turns that into a plan, then builds it task by task with tests and a review after each task. Here is the setup and the workflow, with the real commands from the README. The short version lives on the Deduped use-case page. What Superpowers is Superpowers is a set of composable skills plus some starting instructions that make sure your agent uses them. The skills trigger on their own, so you do not call them by hand. When the agent sees you are building something, it steps back and asks what you are really trying to do before it writes anything. It works with Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot CLI, OpenCode and several other agents. If you use more than one, install it separately for each. Install it In Claude Code, install from Anthropic's official plugin marketplace: /plugin install superpowers@claude-plugins-official Or register the Superpowers marketplace and install from there: /plugin marketplace add obra/superpowers-marketplace /plugin install superpowers@superpowers-marketplace Other agents, from the same README: # Gemini CLI gemini extensions install https://github.com/obra/superpowers # GitHub Copilot CLI copilot plugin marketplace add obra/superpowers-marketplace copilot plugin install superpowers@superpowers-marketplace In Cursor Agent chat, run /add-plugin superpowers. In Codex CLI, open /plugins, search for Superpowers and select Install Plugin. A quick check from the README: start a fresh session and send "Let's make a react todo list". A working install triggers brainstorming before any code is written. The workflow, step by step You describe a feature in a few sentences, in a git project. Then the skills take over in this order: 1. brainstorming draws out what you actually want through questions, then plays its understanding back for correction. Small changes get agreed in chat; bigger projects get a written design document. 2. using-git-worktrees activates after you approve the design. It creates an isolated workspace on a new branch, runs project setup and checks that tests pass before anything changes. 3. writing-plans breaks the work into bite-sized tasks of 2 to 5 minutes each. Every task has exact file paths, complete code and verification steps. 4. subagent-driven-development (or executing-plans) runs the plan. The first dispatches a fresh subagent per task with a review after each, which is the most thorough. The second implements every task inline in the current session with one review of the whole branch at the end, which is the cheapest. 5. test-driven-development enforces red, green, refactor: write a failing test, watch it fail, write minimal code, watch it pass, commit. It deletes code written before tests. 6. requesting-code-review runs between tasks, reviews against the plan and reports issues by severity. Critical issues block progress. 7. finishing-a-development-branch verifies tests and gives you the choice to merge, open a PR, keep or discard, then cleans up the worktree. What you actually do Your job shrinks to three checkpoints: - Answer the brainstorming questions honestly. This is where vague features turn into a clear spec. - Read the design in the short chunks the agent shows you, and sign off only when it matches what you want. - Check the plan. Every task should list exact file paths and how it will be verified. If one does not, ask for it before you say "go". Then say "go" and read each code review as it comes back. A prompt you can paste into any supported agent: Using the Superpowers skills, take this feature: <feature description>. Run brainstorming, then writing-plans, then subagent-driven-development in this project. Show me the design and the plan before any code. Every plan task must list exact file paths and a verification step. Caveats The README says it is not uncommon for the agent to work autonomously for a couple of hours without deviating from the plan. That is the point, and also the risk: whatever is in the approved plan is what gets built. Spend your attention on the design and plan, not on watching the code scroll. If a session misbehaves (a skill fires when it should not, or the agent ignores its plan), ask the agent to "figure out what went wrong with superpowers in this session". That invokes the diagnosing-superpowers skill, which reads the transcript and reports what happened with evidence. One more thing worth knowing: the optional visual companion in brainstorming loads a logo from the maintainers' site that includes the Superpowers version. To turn that off, set SUPERPOWERS_DISABLE_TELEMETRY to any true value. It also honors Claude Code's DISABLE_TELEMETRY setting. More like this Superpowers is one of several skill packs that change how a coding agent works. Compare it with the others on best coding agent skills, or see every Superpowers use case, including root-cause debugging. Want the setup commands for 50 AI repos people actually ship with? Get the free AI Repos That Actually Ship pack: dedupedai.com

Test Results: we manually tried test-first + fresh verification on synthetic URL deduplication: 3 cases red before the fix, 4/4 green after. No native skill triggering, model comparison or measured time savings. mattpocock/skills obra/superpowers #OpenSource

فيه مهارة لكلود كود اسمها Superpowers، نزل لها تحديث جديد. صار يقرأ ملفات مشروعك ويفهم السياق قبل ما يبدأ يسألك، ويساعدك ترتب المتطلبات قبل التنفيذ. مفيدة للي يبني مشاريع كبيرة. obra/superpowers #ClaudeCode #AI

1- Superpowers : Superpowers, kodlama ajanlarınız için tam bir yazılım geliştirme metodolojisidir; bir dizi kompozisyon becerisi ve ajanınızın bunları kullanmasını sağlayan bazı ilk talimatlar üzerine kuruludur. obra/superpowers

Aklında bir fikir var. Yazılımcısın ya da değilsin, fark etmez. Kaliteli bir şey ortaya çıkarmak istiyorsan Superpowers'ı kullan. obra/superpowers t.co

今日のGitHubトレンド obra/superpowers Superpowersは、コーディングエージェント向けのソフトウェア開発手法を提供するリポジトリです。 仕様の明確化、設計の承認、詳細な実装計画の策定、そしてサブエージェントによる自律的な開発プロセスを導入します。 TDD、YAGNI、DRYの原則を重視し、エージェントが計画的に高品質な開発を行えるようにすることを目的としています。

superpowers: a Chinese translation of the 307,936-star agent skills framework Most coding agents have the same failure mode. You describe a feature, and before you finish the second sentence, the agent is already editing files. No clarifying questions, no spec, no plan. You get code that compiles and solves the wrong problem. obra/superpowers exists to interrupt that reflex. It is a software development methodology packaged as a set of composable skills plus bootstrap instructions, written for coding agents. The original repository has 307,936 stars, is primarily Shell, and ships under the MIT license. A Chinese translation was published today: yangshun2005/superpowers-cn. It has zero stars at the time of writing and no track record. What it does have is a translated README plus a short Chinese quick-start guide that the original doesn't include. What the project actually does The core behavior is a forced pause. When the agent detects you're building something, it does not start writing code. It steps back and asks what you're really trying to accomplish. From that conversation it produces a spec, presented in chunks small enough to actually read and digest. After you confirm the design, it writes an implementation plan — detailed enough, in the project's own framing, for an enthusiastic junior engineer with poor taste, no judgment, no context on the project, and a dislike of tests to follow. The plan emphasizes real red/green TDD, YAGNI, and DRY. Then, on your go-ahead, it runs a subagent-driven development loop: the agent works through each engineering task one at a time, checks and reviews the work, then moves on. The project claims agents can often work autonomously for hours without drifting from the plan. Skills trigger automatically. There is no special command to invoke them; the premise is that your agent simply has these capabilities once installed. The Chinese version: what's different The translation date listed in the repo is 2026-10-29. The structure is deliberately split in two: - A Chinese quick-start guide at the top, explicitly labeled as supplementary material, not part of the original README. It covers what the project is, the shortest install path, environment requirements, and common pitfalls. - A faithful translation of the original README body below it, with README_en.md kept alongside for reference. That split matters. Translated READMEs often bury the practical part — install commands, harness differences, update procedures — under a long conceptual preamble. Here the practical part comes first and is marked as an addition, so you can tell what's original and what's editorial. The maintainer asks for issues or PRs where the translation is inaccurate. That's the right posture for a translation of a fast-moving project: the English source will drift, and the Chinese copy will need to follow. Installation, and why it's the main friction point Superpowers installs differently depending on your harness. If you use more than one, you install it separately for each. The original says this explicitly, and it's the first thing people get wrong. For Claude Code, via the official Anthropic plugin marketplace: /plugin install superpowers@claude-plugins-official Or register the Superpowers marketplace first, then install from it: /plugin marketplace add obra/superpowers-marketplace /plugin install superpowers@superpowers-marketplace After that, start your coding agent normally. Skills fire on their own. The README lists per-harness instructions for Antigravity, Codex App, Codex CLI, Cursor, Devin CLI, Factory Droid, Gemini CLI, GitHub Copilot CLI, Grok Build CLI, Kimi Code, OpenCode, Pi, Qwen Code, Hermes Agent, and Muse. Do not copy a command from one harness into another; several use entirely different mechanisms, some going through a plugin marketplace and others installing from the repository. Pitfalls worth knowing before you start The Chinese quick-start collects these, and they're the ones that cost people time: - Install per harness. Multiple harnesses means multiple installs. There is no shared installation. - OpenCode is separate. Even if Superpowers is already running in another harness, OpenCode needs its own install. - Update procedures differ. Some harnesses have dedicated update commands, such as devin plugins update superpowers and gemini extensions update superpowers. Antigravity updates by re-running the same install command. For the rest, the original doesn't specify. - Network access. Install commands pull from GitHub or from each harness's plugin marketplace. In mainland China this may require a mirror or accelerated download. The Chinese guide flags this; the original does not, for obvious reasons. On requirements, the original is silent about operating system, hardware, and version. The only hard dependency is a supported harness. package.json lists the project version as 7.0.1. Why a Chinese translation is worth the effort The barrier here isn't the English language in the abstract. It's that this project's value is concentrated in behavioral nuance. "The agent steps back and asks what you're really trying to accomplish" is easy to translate. The reasoning behind it — why the spec is chunked, why the plan is written for a specific caricature of a junior engineer, why subagents review each other — is where readers decide whether to trust the methodology. Chinese-speaking developers are a large share of the audience for coding agents, and the harness list already includes Qwen Code and Kimi Code. A translated README with a practical entry point lowers the cost of evaluating the project from "read a long English document and hope the install section makes sense" to "run two commands and see what happens." That's the honest value proposition. Not that the translation is better than the original, but that it removes a step between curiosity and a working install. A reasonable way to evaluate it Don't judge Superpowers by whether the agent writes code faster. Judge it by whether the agent asks better questions before writing anything. A small experiment: give your agent a feature request with a deliberate ambiguity in it — an unstated constraint, an unclear scope boundary. Run it once without Superpowers and once with. Watch whether the second run surfaces the ambiguity or silently picks an interpretation. My sample here is one project, so this may not hold for you, but the difference tends to be visible on the first try. If the agent does pause and ask, the methodology is doing its job. If it doesn't, check that the skills actually loaded for your harness — the per-harness install requirement is the usual culprit. Links - Chinese version: yangshun2005/superpowers-cn - Original: obra/superpowers - License: MIT - Original stars: 307,936 --- *Chinese documentation: yangshun2005/superpowers-cn* I'm an independent enterprise AI delivery consultant — private LLM deployment, RAG, agent workflows, AIOps. If your team is stuck somewhere in that stack, my inbox is open.