obra

How I spec out features with Superpowers How I spec out features with Superpowers I use Superpowers to work through features before handing them to a coding agent to implement. I want the agent to help me figure out what I'm asking for, including the decisions I haven't thought through yet. One feature I've been thinking about is letting a design doc contain additional documents. Take a Redis migration: you've got the spec and implementation plan, but now you want to rehearse it in staging and need a runbook. The initial request is pretty simple: let someone create that runbook inside the design doc. But if they follow the runbook, record a failed rehearsal, and then change the instructions, what happens to the record of that first attempt? Someone looking at it later needs to see the instructions that were actually used. That's already more specific than “let people add documents.” It's also something I'd want decided before an agent starts building it. Start with the problem For this feature, I'd give the agent the migration example and work through what the team needs to do: - Keep the staging runbook with the migration it belongs to. - Have a separate runbook for production. - Record what happened during each rehearsal. - Be able to look back at the instructions used for an earlier attempt. That brings up questions about ownership, permissions, and revisions. Can a runbook be shared across unrelated changes? Does it inherit the design doc's permissions? What happens to old references if someone renames or archives it? For the first version, I'd keep each supporting document attached to one change and use that change's permissions. Sharing a runbook across migrations and automatically executing its commands would be separate work. I want those decisions written down so the agent has a clear scope to work within. Where Superpowers helps Superpowers has a brainstorming skill that works through the request and possible approaches before moving into a design and implementation plan. It also tells the agent to inspect the project before asking questions the code or existing docs already answer. That last part matters to me. I don't want to point the agent at every relevant document or explain something it could find in the codebase. I want it to look first, then ask about what's still unresolved. With the runbook example, an agent could ask whether I want version history. I'd probably say yes, but that answer leaves a lot unspecified. A more useful question would be: > Someone follows revision 1 in staging and records a failed attempt. They change the instructions and try again using revision 2. What should someone reviewing the first attempt be able to see? That question puts me in the position of someone actually using the product. I can think about the engineer reviewing the failed rehearsal, what they're trying to understand, and what they'd need to see. Just asking “Do you want version history?” makes it easy to say yes without thinking through how anyone will use it. From that answer, we can get to a specific requirement: the first attempt has to keep a reference to revision 1. Editing the document can't change what that reference opens. Permissions need the same attention. Inheriting the parent's permissions should cover old revisions, search results, and access through the agent, as well as the page someone opens in their browser. These are the details I want to work through in the conversation. One thing I don't like One of my big gripes with using Superpowers is that I still have to tell the agent to do outside research. I mean searching the web, reading current documentation, and looking at how other people have approached the problem. I think an informed decision needs more than what the model learned during training. Reading my codebase gives it context about the project. I also want it to look for information outside the project that could change its recommendation. For the runbook example, I'd want it to investigate how other systems handle changes to a procedure after someone has used it. What tradeoffs did they make? What problems did they run into? That gives us more to consider when deciding how our version should work. I want the agent to recognize when that research would help and do it without me having to ask. Then show me the sources, explain how they apply to this feature, and make it clear which conclusions are its own. Having to remember to add “go research this” is a part of the workflow I'd like to improve. Keep the spec and implementation plan separate In my workflow, the spec describes what the change needs to accomplish. The implementation plan covers how to build it. Part of the spec for this feature could be: > A supporting document belongs to one design doc and inherits its access permissions. > > A recorded rehearsal can reference the exact document revision used. > > Editing, renaming, or archiving the document preserves that reference for authorized readers. > > Creating a runbook doesn't establish that the migration succeeded. The implementation plan can then work out how to store those references, which UI and agent operations need updating, and how to test them. The agent should also check what it can reuse. If the project already has revision history, I want the plan to explain how this feature fits into it. Introducing another versioning system would need a reason. Make the requirements testable I'd take the revision requirement and turn it into a scenario: 1. Create a staging runbook. 2. Record a failed rehearsal against revision 1. 3. Edit the runbook, producing revision 2. 4. Record another rehearsal against revision 2. 5. Open the first rehearsal's reference and confirm it still shows revision 1. An implementation could have a history page and still get this wrong. The scenario tells the agent exactly which behavior needs to hold up. The runbook describes the procedure. The rehearsal record says what happened when someone followed it. Both need to stay understandable after the instructions change. The same issue comes up elsewhere. If a pricing rule changes after an invoice is issued, you still need to know which rule produced that invoice. Thinking through a sequence like that helps me get more specific about what the feature needs to preserve. A starting prompt If you have Superpowers installed, you could adapt this: Use Superpowers to help me work through this feature before implementation. Problem: [Describe a specific situation and what someone needs to accomplish.] Look through the relevant code, docs, and previous decisions first. Tell me what already exists that affects this change. Identify decisions that would benefit from outside research and research them before recommending an approach. Look for current documentation and relevant examples of how others solved similar problems. Link the sources and explain how they affect your recommendation. Distinguish what the sources establish from your own conclusions. Ask about decisions we still need to make. Explain what the options would mean for the feature and recommend an approach. Make it clear when something is an assumption or your proposal. Write a spec covering the intended behavior, what's in and out of scope, unresolved questions, and concrete acceptance scenarios. Once we've agreed on the spec, create an implementation plan based on the codebase. Include how we'll check that the important behavior works. Give it an actual situation to work through. For a notification feature, for example, explain who needs to be notified, what happened, and what they need to do next. How are other people doing this? Superpowers is what I use, but I'd like to hear from people using other tools. Their docs describe a few approaches: | Tool | Documented workflow | | --- | --- | | GitHub Spec Kit | Takes a feature specification through a technical plan, tasks, and implementation, with project principles captured separately. | | OpenSpec | Keeps a proposal, requirements and scenarios, technical design, and tasks together for a change. The workflow includes archiving changes and updating specs. | | Kiro | Uses requirements, design, and task documents. Feature specs can start from requirements or from a technical design. | I'm also interested in people using their agent's planning mode and a Markdown file. Sometimes I just want to work through a problem without going through a full feature workflow. One thing I'm still thinking about is how to handle changes once implementation starts. The agent finds that an assumption was wrong, the plan changes, and the next session needs to know why. I keep a work log alongside the design doc to record what changed and why. How do you handle that in your setup? Do you update the spec, keep a separate record, or rely on the PR and conversation history? I'd also like to hear about a recent change where planning helped, or where it became more work than it was worth. Which tool were you using, and what did you end up keeping or skipping?

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の原則を重視し、エージェントが計画的に高品質な開発を行えるようにすることを目的としています。