衝突: どちらか一方だけを入れる

両方を読み込ませると、1 つの仕事に対して手順が 2 つ渡ります。その調整はエージェントの文脈の中で起き、外からは見えず、結果はたまたま強く効いたほうの指示になります。

組み合わせ	理由
test-driven-development tdd	同じ仕事に対するテスト駆動開発の完成した手順が 2 つあります。同時に読み込むと、周期の大きさとリファクタの時機について矛盾した指示が渡ります。どちらか一方にしてください。
systematic-debugging diagnosing-bugs	どちらも当て推量の修正を段階的な診断に置き換えますが、段階の切り方が違います。両方を有効にすると、手順をめぐる衝突がエージェントの文脈の中で起き、外からは見えません。
superpowers tdd	superpowers の方法論にはすでに独自のテスト駆動開発スキルが含まれます。もう 1 つ足すのは冗長化ではなく、エージェントが自力で解決するしかない矛盾です。
superpowers diagnosing-bugs	デバッグ側でも同じ衝突が起きます。superpowers には systematic-debugging が含まれるため、2 つ目のデバッグ方法論は追加ではなく競合になります。

組み合わせ: 互いの穴を埋める

単に相性がよいという意味ではありません。どの組でも、片方の欠けている部分をもう片方が埋めます。だから片方だけを入れると、予測できる形で期待外れになります。

組み合わせ	理由
verification-before-completion webapp-testing	カタログ中で最も強い組み合わせです。片方が完了宣言の前に証拠を必須にし、もう片方がブラウザで実際にその証拠を作ります。
writing-plans subagent-driven-development	作業を複数エージェントへ分けるやり方は、先に書かれた計画が境界を決めている場合にだけ現実に耐えます。順序を逆にすると、同じ誤解が並列に複製されます。
brainstorming grill-me	brainstorming は選択肢を広げ、grill-me は選んだ案を突きます。この順序で使うと、抜けていた代替案と、決めていない分岐という別々の失敗を拾えます。
frontend-design theme-factory	frontend-design は 1 ページの見え方を決め、theme-factory はその判断を再利用可能にします。後者がないと、10 ページ目は 1 ページ目と似ても似つきません。
brand-guidelines theme-factory	ガイドラインはブランドの規則を宣言し、テーマはその規則が生む実装です。前者だけを入れたチームは、同じパレットを何度も説明し続けることになります。
doc-coauthoring docx	片方が執筆を構造化し、もう片方がファイルを作ります。単体では、レビュー不能な草案か、誰も合意していない体裁のよい文書のどちらかになります。
brand-guidelines pptx	資料はビジュアルのぶれが最初に表面化する場所です。資料側のスキルが構成を作り、ブランド側のスキルが各資料の独自の余白づくりを止めます。
skill-creator find-skills	書く前に探すこと。先に発見側のスキルを入れておくと、すでに存在するものを skill-creator で作り直す事態を防げます。
mcp-builder claude-api	サーバーを作ることとモデルを呼ぶことは、同じ統合の両輪です。API リファレンスは、サーバーを設計している間も識別子と呼び出しパターンを最新に保ちます。
web-artifacts-builder frontend-design	成果物側のスキルはページが単体で動くことを担い、デザイン側のスキルは他の生成物と同じ見た目にならないことを担います。互いの守備範囲は重なりません。

調査方法

衝突として記録するのは、両方のスキルが同じ判断についてエージェントに指示する場合だけで、単に主題が近いだけでは記録しません。組み合わせとして記録するのは、片方が残す穴をもう片方が埋める場合です。以下の記述はすべて両方のスキルを読んだうえでのもので、確認日は各項目に表示されているものと同じです。