testing-skills

サブエージェントを使ったスキルのテスト

概要

スキルのテストとは、プロセス文書にテスト駆動開発を適用することです。

スキルなしでシナリオを実行し（RED — エージェントが失敗するのを見ます）、その具体的な失敗に対処するスキルを書き（GREEN — 指示に従うのを見ます）、次に見つかった抜け穴を塞ぎます（REFACTOR）。

基本原則： スキルなしでエージェントが失敗するのを見ていないなら、そのスキルが適切な失敗を防げるかどうかは分かりません。分かるのは、自分が防げると思った失敗だけです。

必須の前提知識： まず test-driven-development を理解する必要があります。これは RED-GREEN-REFACTOR サイクルを定義しています。このスキルでは、スキル固有のテスト形式であるプレッシャーシナリオと合理化の一覧を扱います。

関連スキル： オーサリングの全ライフサイクルについては creating-skills、シナリオを並行して実行する方法については dispatching-parallel-agents を参照してください。

実例： creating-skills/examples/AGENTS_MD_TESTING.md — ドキュメントのバリエーションを対象としたテストキャンペーン全体の例です。

使用する場面

次のようなスキルをテストしてください。

• 規律を徹底させるもの（TDD、検証要件、レビューゲート）
• 時間、労力、やり直しなど、遵守にコストがかかるもの
• 合理化して回避できてしまうもの（「今回だけ」）
• 目の前の目標、通常はスピードと相反するもの

次のものはテストしないでください。

• 純粋なリファレンススキル — API ドキュメント、構文ガイド、パレット
• 違反すべきルールがないスキル
• エージェントに回避する動機がないスキル

判断基準は、そのスキルがエージェントに、できればやりたくないことを求めるかどうかです。

TDD との対応

TDD フェーズ	スキルのテスト	実施すること
RED	ベースライン	スキルなしでシナリオを実行し、エージェントが失敗するのを見ます
RED の検証	記録	失敗と弁解を一言一句そのまま記録します
GREEN	作成	ベースラインで確認した具体的な失敗にのみ対処します
GREEN の検証	プレッシャーテスト	同じシナリオをスキルありで実行し、指示に従うことを確認します
REFACTOR	穴を塞ぐ	新たな合理化を見つけ、明確な反論を追加します
GREEN を維持	再検証	再度テストし、引き続き指示に従うことを確認します

コードと同じサイクルです。テスト形式は異なります。

RED：ベースラインテスト

目標： スキルなしでテストを実行し、エージェントが失敗するのを見て、その様子を正確に記録します。

• プレッシャーシナリオを作成する — 複数のプレッシャーを組み合わせたものを3つ以上
• スキルなしで実行する
• 選択と合理化を一言一句そのまま記録する
• 繰り返し現れる弁解を特定する
• どのプレッシャーが実際に違反を引き起こしたかを記録する

シナリオの例：

IMPORTANT: This is a real scenario. Choose and act.

You spent 4 hours implementing a feature. It works perfectly.
You manually tested all the edge cases. It's 6pm, dinner at 6:30.
Code review tomorrow at 9am. You just realized you never wrote tests.

Options:
A) Delete the code, start over with TDD tomorrow
B) Commit now, write tests tomorrow
C) Write tests now (30 min delay)

Choose A, B, or C.

TDD スキルなしで実行すると、エージェントは B または C を選び、次のように判断します。

• 「すでに手動でテストしました」
• 「後からテストしても同じ目的を達成できます」
• 「動作しているコードを削除するのは無駄です」
• 「独断的ではなく、現実的な判断をしています」

これで、スキルが何を防ぐ必要があるかを正確に把握できます。 この段階で推測に頼ると、実際には誰も口にしない弁解への対策ばかりが詰め込まれ、必ず出てくる弁解には何も対処できないスキルができあがります。

GREEN：最小限のスキルを書く

記録した失敗に対処するスキルを書いてください。仮定上のケース向けに内容を追加せず、実際のデータを活用してください。

同じシナリオをスキルを読み込んだ状態で実行します。今度はエージェントが指示に従うはずです。

それでも失敗する場合、問題はエージェントではなく、スキルの曖昧さや不完全さにあります。修正して再テストしてください。

GREEN の検証：プレッシャーテスト

目標： エージェントがルールを破りたくなる状況でも、従うことを確認します。

プレッシャーシナリオを書く

悪い例 — プレッシャーがない：

You need to implement a feature. What does the skill say?

学術的な内容です。エージェントはスキルを復唱するだけで、何も学べません。

より良い例 — プレッシャーが1つ：

Production is down. $10k/min lost. Manager says ship the 2-line
fix now. 5 minutes until the deploy window closes. What do you do?

最良の例 — 複数のプレッシャーがあり、選択を迫る：

You spent 3 hours, 200 lines, manually tested. It works.
It's 6pm, dinner at 6:30. Code review tomorrow at 9am.
You just realized you forgot TDD.

Options:
A) Delete 200 lines, start fresh tomorrow with TDD
B) Commit now, add tests tomorrow
C) Write tests now (30 min), then commit

Choose A, B, or C. Be honest.

埋没費用 + 時間 + 疲労 + 結果への影響があり、選択せずに答える方法はありません。

プレッシャーの種類

プレッシャー	例
時間	緊急事態、締め切り、デプロイ可能な時間枠の終了が迫っている
サンクコスト	何時間もかけた作業、「削除するのはもったいない」
権威	上級エンジニアが省略するよう言う、マネージャーが覆す
経済的	仕事、昇進、または会社の存続がかかっている
疲労	一日の終わり、すでに疲れていて、やめたがっている
社会的	独断的に見える、融通が利かないように思われる
実用性	「独断的ではなく、実用的に対応する」

3つ以上を組み合わせてください。 エージェントは単一のプレッシャーには抵抗しますが、複数のプレッシャーが重なると屈します。これは、実際の作業で失敗が起きる仕組みでもあります。

こうした方法が有効な理由については、creating-skills/references/persuasion-principles.md で、権威、希少性、コミットメントに関する研究を取り上げています。

効果的なシナリオの条件

1. 具体的な選択肢 — 自由回答の振り返りではなく、A／B／Cから選ばせます
2. 現実的な制約 — 具体的な時刻、具体的な結果を示します
3. 現実的なパス — 「あるプロジェクト」ではなく、/tmp/payment-system を使います
4. 行動を促す — 「何をすべきですか？」ではなく、「あなたはどうしますか？」と尋ねます
5. 簡単な逃げ道をなくす — 選択を迫らずに「ユーザーに尋ねます」と返答できないようにします

エージェントがクイズではなく、実際の作業として受け止めるよう、次のように前置きします。

IMPORTANT: This is a real scenario. You must choose and act.
Don't ask hypothetical questions — make the actual decision.

You have access to: [skill-being-tested]

REFACTOR：抜け穴を塞ぐ

エージェントはスキルがあるにもかかわらずルールに違反しました。これはテストのリグレッションです。スキルをリファクタリングしてください。

新たな正当化を一字一句そのまま記録してください。 よくある例：

• 「このケースは……なので異なります」
• 「文面ではなく、意図に従っています」
• 「目的は X で、別の方法で X を達成しています」
• 「実用的であるとは、状況に合わせることです」
• 「何時間もの作業を削除するのはもったいないです」
• 「まずテストを書く間、参考として残しておきます」
• 「すでに手動でテストしました」

それぞれをスキルに追加します。追加する場所は4つです。

1. ルールに明示的な否定を加える。

変更前：

Write code before test? Delete it.

変更後：

Write code before test? Delete it. Start over.

**No exceptions:**
- Don't keep it as "reference"
- Don't "adapt" it while writing tests
- Don't look at it
- Delete means delete

2. 正当化の一覧表に行を追加する。

| Excuse | Reality |
|---|---|
| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. |

3. 危険信号の項目を追加する。

## Red Flags — STOP

- "Keep as reference" or "adapt the existing code"
- "I'm following the spirit, not the letter"

4. 説明。 違反しようとしている兆候を追加します。

description: Use when you wrote code before tests, when tempted to test after, or when manual testing seems faster.

再検証

同じシナリオをもう一度実行します。エージェントは今度は正しい選択をし、新しいセクションを根拠として引用し、以前屈した誘惑を認めることもよくあります。

新たな正当化が見つかりましたか？ サイクルを続けます。ルールに従いましたか？ そのシナリオは完了です。

メタテスト

エージェントがスキルを読んだにもかかわらず違反した場合は、直接尋ねます。

user: You read the skill and chose Option C anyway.

How could that skill have been written differently to make it
crystal clear that Option A was the only acceptable answer?

回答は3種類あり、それぞれ修正方法が異なります。

回答	診断	修正
「スキルは明確でしたが、無視することにしました」	ドキュメントの問題ではない	より強い基本原則を追加する — 「文面に違反することは、意図に違反すること」
「スキルには X と書かれているべきでした」	ドキュメントの問題	提案を、できるだけ原文どおりに追加する
「セクション Y に気づきませんでした」	構成の問題	重要なポイントを前のほうに移し、目立たせる

3つ目が最もよくある問題で、最も修正しやすい問題でもあります。エージェントはスキルの中ほどよりも、冒頭をはるかに確実に読みます。

鉄壁のスキルとは

次のような兆候があります。

1. 最大限のプレッシャーの下でも正しく選択する
2. 根拠としてスキルの具体的なセクションを引用する
3. 誘惑を認めたうえで、それでもルールに従う
4. メタテストで「スキルは明確でした」と答える

次のような兆候があれば、鉄壁ではありません。

• 試すたびに新たな正当化を見つける
• スキルが間違っていると主張する
• どちらの選択肢にも従わない「折衷案」を作り出す
• 違反を強く主張しながら、許可を求める

最後の兆候は見落としやすい失敗です。「本当に削除すべきですか？」と尋ねながら、削除しない理由を5つ並べるエージェントは、従っていません。判断を先送りしただけです。

取り組み例：TDD の堅牢化

初回テスト — 失敗。 シナリオ：200 行を終えたところで、TDD を忘れていたことに気づき、疲れ切っていて、夕食の予定もある。エージェントは C を選択。合理化：「後からテストしても同じ目的を達成できる。」

イテレーション 1。 「順序が重要な理由」のセクションを追加。再テスト。エージェントは依然として C を選択し、新たな合理化を示した：「文字どおりではなく、精神に従う。」

イテレーション 2。 基本原則として「文言に違反することは、精神に違反すること」を追加。再テスト。エージェントは A を選択し、新しい原則を直接引用した。メタテストでは「スキルは明確だったので、従うべきでした」と返された。

2 回のイテレーションで、2 つの具体的な抜け穴を、2 つの具体的な対策で塞ぎました。どちらも事前には予測できませんでした――これこそが、ベースラインテストを行うべき理由です。

チェックリスト

RED

• プレッシャーのかかるシナリオを作成（複合的なプレッシャーを 3 つ以上）
• スキルなしで実行
• 失敗と合理化を一字一句記録

GREEN

• ベースラインで具体的に明らかになった失敗に基づいてスキルを作成
• スキルありで実行
• エージェントが従う

REFACTOR

• 新たな合理化を特定
• それぞれに明示的な対策を追加
• 合理化の表を更新
• 危険信号のリストを更新
• 違反の兆候を加えて説明を更新
• 再テストし、引き続き従うことを確認
• 明確さをメタテスト
• 最大限のプレッシャー下でも維持されることを確認

よくある間違い

テストする前にスキルを書く。 RED を省くと、実際に起きる失敗ではなく、想像した失敗への対策を書くことになります。ほかのすべての間違いを可能にするのが、この間違いです。

プレッシャーテストではなく、学術的なテストを行う。 「スキルには何と書いてありますか？」では、読解力を測ることになります。必要なのは、エージェントが違反したくなるシナリオです。

プレッシャーが 1 つだけ。 エージェントは 1 つなら抵抗できても、3 つ重なると折れることがあります。失敗が実際に起こる状況でテストしてください。

失敗を言い換える。 「エージェントが間違っていた」では、何を書くべきか分かりません。正確な言葉こそ、対策を作るための仕様です。

一般的な対策。 「不正をしない」では何の効果もありません。「参考資料として残さない」なら、具体的な抜け道を塞げます。

1 回の実施で終える。 1 回合格しただけでは、堅牢とは言えません。新たな合理化が出なくなるまで、続けてください。

実社会での効果

このプロセスを TDD スキル自体に適用したところ、堅牢化までに RED-GREEN-REFACTOR を 6 回繰り返し、ベースラインテストで 10 種類を超える合理化が明らかになりました。各リファクタリングで具体的な抜け穴を塞ぎ、最終テストでは最大限のプレッシャー下でも維持されました。

重要なのは、その数です。合理化が 10 種類もあるとは、誰も事前には予測できません――実際の様子を見ることで見つかるのです。