チャプター9：鉄の法則とアンチパターン

鉄の法則は、Superpowersを有効にしたエージェントとのすべてのセッションを支配する、交渉の余地のないルールです。これらはガイドライン、デフォルト設定、または提案ではありません。指示、緊急性、または利便性によって上書きできないハード制約です。

これらの法則が存在する理由、そして破られたときに何が起きるかを理解することは、Superpowersを効果的に使用するために不可欠です。

4つの鉄の法則

鉄の法則1：TDD

「失敗するテストなしにプロダクションコードを書いてはならない」

すべての機能、すべてのバグ修正、すべての動作変更の前に、望ましい動作を記述する失敗するテストが必要です。これはTest-Driven Development（TDD）を厳密に適用したものです。

これが交渉の余地がない理由：

先に失敗するテストがなければ、コードが思い通りに動作するという証明がありません。実装して期待するだけです。先に失敗するテストがあれば、実装が満たさなければならない正確な仕様と、永遠に実行できる検証メカニズムが得られます。

これが防ぐもの：

間違ったものを自信を持って実装すること
何もテストしていないため常に通過するテスト
唯一の検証として「動くと思う」という状態
6ヶ月後にコードが変わったときの回帰

適用方法：

1. テストを書く → 失敗する（RED）
2. 通過させる最小限のコードを書く（GREEN）
3. テストを壊さずにリファクタリングする（REFACTOR）

失敗するテストを書けない場合、要件をまだ十分に理解していないため実装できません。停止して明確化してください。

鉄の法則2：検証

「最新の検証証拠なしに完了を主張してはならない」

検証を実行してその出力を目の前に持っていない限り、作業が完了した、修正された、または通過しているとは主張できません。

これが交渉の余地がない理由：

メンタルモデルは信頼できません。「動くはずの」変更はしばしば動きません。「以前は動いていた」コードが、その後の変更によって壊れている可能性があります。唯一の有効な証拠は、今この瞬間に実際の検証コマンドを実行した出力です。

これが防ぐもの：

高い自信を持って壊れたコードをシップすること
「私のマシンでは動いた」という失敗パターン
古いテスト結果を現在の状態として扱うこと
証拠の代わりになる口頭での保証

検証は最新でなければなりません： 5回のcommit前にテストを実行して現在の状態が問題ないと主張することは検証ではありません。現在の状態でテストを実行し、出力を読んでから、主張してください。

鉄の法則3：デバッグ

「根本原因調査なしに修正してはならない」

修正コードを書く前に、チャプター6で説明されている根本原因調査を完了しなければなりません。バグの原因を正確に1文で述べることができなければなりません。

これが交渉の余地がない理由：

原因を理解せずに症状を修正することは、技術的負債の蓄積の主な原因です。各症状修正は複雑さを加え、本当の問題を隠し、後で根本原因を見つけることをより困難にします。コードベースは誰も理解していないパッチの堆積物になります。

これが防ぐもの：

同じバグが別の形で再発すること
各修正が別のものを壊す修正連鎖
アーキテクチャの明確さの喪失
3回の失敗パターン（チャプター6参照）

根本原因の陳述テスト： 修正を実装する前に、この文を迷いなく完成させることができなければなりません：「バグは[特定のもの]によって引き起こされており、その根拠は[証拠]です。」 できない場合、調査は未完了です。

鉄の法則4：スキル

「失敗するテストなしにスキルを作成してはならない」

Superpowersスキルを作成または変更する際にも、同じTDDルールが適用されます。スキルの意図した動作を示すテストを書き、失敗することを確認してから、スキルを実装してください。

これが交渉の余地がない理由：

スキルはコードです。正しいまたは間違っている可能性のある動作があります。テストなしでは、スキル開発は他の未テストのコードと同様に信頼性がありません—動くが動かなくなり、いつ動かなくなったか、なぜかを知る方法がありません。

マスターレッドフラグテーブル

これらは鉄の法則が違反されようとしているときの警告サインです。これらのいずれかを観察したら、現在のアクションを停止して正しいプロトコルに戻ってください。

#	レッドフラグ	何を示しているか	STOP アクション
1	「これは動くはずだ」	検証がスキップされた	今すぐ検証コマンドを実行する
2	「おそらく問題ない」	証拠なしの仮定	証拠を見つけるか不確実性を認める
3	「テストは通過するはずだ」	テストが実行されていない	テストを実行する
4	「この修正を試してみよう」	根本原因調査なし	まずデバッグのフェーズ1を完了する
5	「後でテストを追加する」	TDD違反が進行中	今すぐ失敗するテストを書く
6	「これは小さな変更なのでテストは不要」	TDD例外が発明されている	例外なし。テストを書く。
7	「おっしゃる通りです！」（即座に）	パフォーマンス的な同意	まずRead → Understand → Verify → Evaluate
8	壊れた動作に合わせてテストを修正すること	バグを隠蔽している	テストではなくコードを修正する
9	mainに直接commitすること	分離プロトコルを回避している	worktreeとブランチを作成する
10	同じバグへの4回目の修正試み	アーキテクチャの問題が隠蔽されている	停止。再設計する。パッチを続けない。
11	テスト出力を表示せず要約すること	可能性のあるハルシネーションまたは選択的な読み取り	実際の出力を表示する
12	新しいworktreeでのベースラインテストをスキップすること	開始状態が不明	コードを書く前に完全なテストスイートを実行する

アンチパターンサマリー

以下のアンチパターンはこのガイドのすべてのチャプターに渡って見られます。参照としてここに集めています。

チャプター1から：基盤

ツールの設定ミス： CLAUDE.mdやセットアップドキュメントを読まずにSuperpowersを使用すること。スキルは正しく起動するために適切な設定が必要です。
スキルの回避： 適切なスキルを呼び出さずにエージェントに「ただやって」と依頼すること。スキルには理由があります；それらを回避すると品質が低下した出力になります。

チャプター2から：計画の作成

計画なしの実装： 計画が作成されレビューされる前にコードを書き始めること。計画はアーキテクチャの問題を安価に発見します；コードはそうではありません。
曖昧な計画： 具体的なステップではなく成果の観点で計画を書くこと。「認証を実装する」は計画ではありません。具体的なアクションの番号付きシーケンスが計画です。

チャプター3から：計画の実行

独立したタスクの逐次実行： 並列化できるのにタスクを1つずつ実行すること。これは実際の経過時間を不必要に増やします。
並列タスク間での状態共有： 同じファイルや状態を変更する並列タスクを実行すること。これはmerge conflictとrace conditionを生み出します。

チャプター4から：TDD

実装後のテスト： コードが書かれた後にテストを書くこと。これらのテストは要件ではなく実装に合わせて形成される可能性が高いです。
実装詳細のテスト： 動作が変わっていないのにコードがリファクタリングされるたびに壊れるテストを書くこと。実装ではなく動作をテストしてください。

チャプター5から：ブレインストーミング

実装前のブレインストームをスキップ： 問題空間を探索せずに直接コーディングに進むこと。ブレインストームはすべてのクリエイティブな作業の前に必要です。
ブレインストームを形式的なものとして扱うこと： 本当に代替案を探索せずにブレインストームの形式をこなすこと。価値は探索にあり、儀式にはありません。

チャプター6から：デバッグ

推測と確認： 根本原因調査なしに修正を試みること。これは3回の失敗パターンの主な原因です。
複数のものを同時に修正： バグに対処するために複数の変更を行い、どの変更が機能したかを知ることを不可能にすること。
早まった完了の主張： 検証を実行する前に「修正した」と言うこと。

チャプター7から：コードレビュー

パフォーマンス的な同意： レビューのフィードバックを評価せずに即座に同意すること。これは動作しているコードに悪い提案を適用します。
重大度レベルの無視： すべてのフィードバックを同等に緊急なものとして扱うこと。Criticalの問題はブロックします；Minorの問題はログに記録されます。

チャプター8から：Git Worktree

mainへの直接commit： mergeまたはPR以外でのmainへの変更。mainは常にデプロイ可能な状態です。
ベースラインテストなしの作業： ベースブランチですべてのテストが通過することを最初に確認せずに機能作業を開始すること。

適用

鉄の法則はツールではなくエージェントの動作によって適用されます。違反を観察したとき—エージェントによるものであれ、違反を引き起こす指示によるものであれ—正しい対応は違反されている法則を名指しして正しいプロトコルに戻ることです。

これは妨害ではありません。これが品質を維持する方法です。鉄の法則に対するすべての例外は、この特定のケースがそれを正当化するほど特別であるという賭けです。その賭けはほとんど常に間違っています。