構造があるとすごく助かるよね。似たようなプロンプトのスキャフォールドを使ったことがあるけど、違いがすごく分かる。もう一つの良いテクニックは、リポジトリにこれらの構造を使って、AIにターゲットプロジェクトのベストプラクティスを使ってフレームワークを見直させること。創作、ヒューマナイジング、作曲、技術・科学分野などにすごく役立つよ。エージェントと組み合わせると、これらは本当にいい感じ。これは一時的なものになると思うけど、いくつかのモデルリリースまでの便利さを高めるハックだね。十分な成功事例がトレーニングデータに入れば、モデルはこういうことを余計なプロンプトなしでうまくやれるようになると思う。使うのが楽しいよ。

両方使ったことがあるけど、私の経験では、gsdは過剰に設計されたソフトウェアで、残念ながら何も進まないし、時間がかかる。クイックモードはあまり役に立たないし、gsdのポイントを殺しちゃう。アドホックでフルソフトウェアを構築するのは無理だよ。以前はプレーンなマークダウンプランを使ってたけど、制限があってあまり安定してなかった。superpowersはいい中間地点に見えるね。

両方試したことがあるけど、それぞれに長所と短所があるね。superpowersの嫌なところは、すべてのコードを実装プランに書き込んで、サブエージェントがそのコードをファイルに戻すだけってところ。それに、複数のセッションで作業したい場合、進捗を追うためにClaudeにprogress.mdファイルを作成させなきゃいけない。GSDはこれらの問題をほぼ解決してくれたけど、GSDの欠点は、何かを終わらせるのに時間がかかりすぎることだね。

なんで人々がこれにCLIラッパーを必要としてるのか分からない。Claudeのスキルを使って、必要なものを全部作れないの？

そうそう、個人的にはSuperpowersの方が「やるべきことをちゃんとやる」には向いてると思う。「やるべきことを片付ける」は、インフルエンサーが明日のTikTok投稿のために一晩でPotemkin SaaSを作る時には最適だけど。

現在のプロジェクトでSuperpowersを試してみたよ。ブログをHugoからAstro（AstroPaperテーマ）に移行する作業ね。メインの仕様書は2つの方法で書いたんだ。1) 新しいブログに何が欲しいかの小さなリストから始めて、エージェントと一緒にそれを広げていく方法（いわゆるコラボレーション仕様）と、2) Superpowersに仕様書と計画を作成してもらう方法。どちらもブログのリポジトリの作業ディレクトリから行ったから、エージェントはコードとコンテンツに完全にアクセスできた。結果はこうだった：1. Superpowersが作成した仕様書はすごく詳細で（特定のフォントやカラーパレットが記載されてた）、設定ファイルやコミットメッセージの正確な内容も含まれてた。でも、分析やRSSフィードなど、いくつかの重要な要素が抜けてた。2. Superpowersは仕様書と計画を2つの別々の文書として書いたから、コラボレーション方式よりも良かった。コラボレーション方式は両方を1つの文書にまとめてたから。3. Superpowersはブログのインプレース移行を推奨したけど、コラボレーション仕様はHugoとAstroが共存できるように並行ブランチを提案した。その他の違いについては[0]に書いてあるよ。全体的には、仕様を議論を通じて発展させるという点が気に入った。一発で決めるんじゃなくて、思い出したことを追加できる感じが良かった。初めての時に全てを正しくする必要がない、より反復的な発見プロセスのように感じた。ただの個人的な好みかもしれないけど。この作業の最後に、Claudeに両方の仕様書を詳しくレビューしてもらったら、両方の仕様書が見落としてた点（SEOやロールバックプランなど）をいくつか見つけて、全てを統合した最終仕様書を作成してくれた。[0] https://annjose.com/redesign/#two-specs-one-project

openspecも好きだな。こういうシステム（gsd/superpowers）はちょっと意見が強すぎると思う。機能しないわけじゃないけど、変化の速い時代に本当に対応するには、こういう超意見的なワークフローに縛られない方がいいと思う。だからopenspecの上にオーケストレーターライブラリを作ってるんだ。

最近、純粋なプランモードからsuperpowersにシフトしたんだ。最新バージョンの発表で思い出した。私の確認バイアスかもしれないけど、似たような問題に対してプランモードよりも良い結果が出てる気がする。これは多層のクロスチェックと自己レビューのおかげだと思ってる。もちろん手作業でもできるけど、superpowersが私がやろうとしてたことを自動化してくれてる感じがする。

なんでClaude Codeを使ってるのにCLIラッパーを使ってるの？Codexみたいなものが必要なのは分かるけど、今日サブエージェントがリリースされたから、もしかしたらそれも必要ないかもね。Claude Codeには余計なラッパーだと思う。

プラグインをちょっと触ってみたけど、言った通り、プランモードは大体うまくやってくれるね。Claudeでいろんなワークフローを試してみたけど、CCがカスタムスキルやエージェントを作ってくれるおかげで、80%はうまくいってる。Claudeファイルがそれらを参照するだけで、全体のワークフローを定義しようとするよりもずっと楽だし。たまに忘れちゃうこともあるけど、そんなに大きな問題じゃない。少なくとも、手動でスラッシュコマンドを覚えるよりは自然に使えるから、十分だよ。

他の90%はどうなってるの？

Gryphの開発にはしばらくの間、スーパーパワーを使ってるよ。ブレインストーミングや探求が楽しいんだ。トークンの使い方はあんまり比べてないけど、何かしら役に立ってるよ。

結局、スーパーパワーからブレインストーム、デザイン、実装計画のスキルを取り入れて、実装計画が完成したら自分の入力を求めないRalphベースの実装レイヤーに移植したよ。危険な権限設定のせいでDockerサンドボックスで動かさなきゃいけないけど、それはそれでいいアイデアだと思う。うまく動いてるし、生産性も高くて楽しんでるけど、実際の目的地というよりは旅の一歩って感じ。これからこの旅がどこに行くのか楽しみだよ。

GitHubのプロフィールを5秒見ただけで、音楽関連のものがたくさんあって、私たちには何かわからないプライベートリポジトリへの貢献もたくさんあるのが見えた。生産性の達人のアンチパターンは理解できるけど、正直言って、あなたがこの反射的な個人攻撃をするほどの何を見ているのかがわからない。

メンテナンスしなくても大丈夫だよ。特にAIの時代では、人にインスピレーションを与えたり、何か感じてもらうだけで十分だし、感謝されるよ。