Superpowersを工程の設計として読む

SuperPowerという呼び名は、ここではobra/superpowersを対象として扱う。

学習時間の目安: 45 分.

1. 1観測した失敗
2. 2デバッグの仮説
3. 31つの確認
4. 4再現または仮説の修正

独自の学習図。矢印は読み進める順序や判断の流れを表し、実測した実行traceではない。

前提となる章

• カタログを、人気順ではなく用途で読む

根拠と演習の状態

本章は編集された学習ガイドです。出典を読んだこととSkillを実行して効果を測ったことを分けます。演習は未実施：not-run。実験ログやモデル出力はありません。

学習目標

• 単一Skillとフレームワークを区別できる
• 方法論の遵守と成果の改善を別に測れる

仕事の役割

• 学習者：仮説と採点基準を決める
• AI：承認された範囲の読取りと成果物作成を補助する
• レビュー担当：成果とログを分けて確認する

入力

• この章で指定した入力例
• 確認する公式資料と版

一つの必殺プロンプトではない

obra/superpowersは複数のSkillと導入時の指示を組み合わせたソフトウェア開発の方法論である。READMEでは、要求を明確にし、設計し、実装計画を作り、実装とレビューを進める流れが示される。したがってSuperpowersを有効化して比較すると、単なる文章追加以外に、作業分割やフックなども変わる可能性がある。これは「一つのSkillの効果」ではなく「ワークフロー全体の効果」として設計する必要がある。

obra/superpowers

systematic-debuggingの読みどころ

このSkillは修正を急ぐ前に原因を調べ、再現条件や差分を確かめ、仮説を小さく検証することを強く求める。読むときは文面の強さより、どの行動を変えたいのかに注目する。本講座の評価例では「根拠なしの変更回数」「再現手順の明瞭さ」「回帰テストの有無」を観測する。手順を長く説明しただけでは加点せず、実際のログや成果物を根拠にする。

Superpowers systematic-debugging: 固定版

test-driven-developmentの読みどころ

このSkillは、先にテストを書いて意図した理由で失敗を確認し、最小の実装で通し、その後で整理する順序を重視する。評価ではテストファイルの存在だけでなく、実装前に失敗を観測したかをログで見る。本講座が提案する独立の成果基準は、未知の入力に対して仕様どおり動くこと、既存機能を壊さないこと、変更が理解可能であることだ。工程の遵守率と欠陥率は別の列に残す。

Superpowers test-driven-development: 固定版

方法論にもコストと境界がある

要求の曖昧な中規模開発では設計確認が役立つかもしれない。一方、学習用の小さな修正では確認や分割の固定費が大きいかもしれない。これらは本講座の仮説であり、実測結果ではない。Skillが削除や大規模変更を強く命じても、利用者の依頼範囲や安全確認を越えてよい根拠にはならない。比較では自動フック、呼び出した下位Skill、サブエージェント数まで記録し、単体テストと全体テストを混同しない。

制作・検証の工程

1. 既知の小さなバグを含む練習用コードと、正解を露出しない依頼を準備する
2. systematic-debugging単体と無効条件の差分だけを定義する
3. 原因の証拠・修正・回帰テストを独立に採点する

出力

• 未実行の比較計画書

品質チェック

• 対象をobra/superpowersと明示した
• 方法論の宣伝文を成績として引用しない
• 固定版と可変版を区別した

失敗の切り分け

• 症状: 効果を観測していないのに成功と記録する
• 原因: 期待判定と実際の出力を混同した
• 対処: 未実施はnot-run、実測欄は空欄に戻し、原出力とログを取得してから採点する

演習: デバッグ比較を設計する

上の工程を順に行い、上記の成果物を作ります。

完了条件: フレームワーク全体の有効化と個別Skillの読込を区別している

Status: not-run.

出典が支える範囲

出典は本文やカタログの機能・配布元表示を支えます。実測効果や人気順位の根拠ではありません。確認日は公開資料を読んだ日で、公開日・更新日とは異なります。main 等の可変参照は厳密な実験用固定版ではありません。

手元の実験記録テンプレート