test-prompt

サブエージェントを使ったプロンプトのテスト

コマンド、フック、スキル、サブエージェントへの指示、本番環境の LLM プロンプトなど、あらゆるプロンプトをデプロイ前にテストします。

概要

プロンプトのテストとは、LLM への指示に TDD を適用することです。

プロンプトを使わずにシナリオを実行し（RED：エージェントの動作を観察）、失敗に対処するプロンプトを書き（GREEN：エージェントが指示に従うかを観察）、抜け穴をふさいで（REFACTOR：堅牢性を検証）いきます。

基本原則： プロンプトなしでエージェントが失敗する様子を観察していなければ、そのプロンプトで何を解決すべきかはわかりません。

必須の前提知識：

• test-driven-development を必ず理解してください。RED-GREEN-REFACTOR サイクルを定義しています。
• prompt-engineering スキルを理解しておくことを推奨します。プロンプト最適化の手法を紹介しています。

関連スキル： 規律の徹底を目的とするスキルをテストする場合は、test-skill を参照してください。このコマンドは、あらゆるプロンプトを対象とします。

使用する場面

次のようなプロンプトをテストします。

• エージェントの動作を導く（コマンド、指示）
• 実践を徹底させる（フック、規律を徹底するスキル）
• 専門知識を提供する（技術スキル、リファレンス）
• サブエージェントを設定する（タスクの説明、制約）
• 本番環境で動作する（ユーザー向けの LLM 機能）

次のような場合は、デプロイ前にテストします。

• プロンプトの明確さが重要な場合
• 一貫性が求められる場合
• 失敗した場合のコストが高い場合
• プロンプトを再利用する場合

プロンプトの種類とテスト戦略

プロンプトの種類	テストの焦点	例
指示	エージェントは手順に正しく従うか？	git ワークフローを実行するコマンド
規律を徹底するもの	プレッシャーを受けてもエージェントは正当化に流されないか？	TDD の遵守を求めるスキル
ガイダンス	エージェントはアドバイスを適切に適用するか？	アーキテクチャパターンを含むスキル
リファレンス	情報は正確で、参照しやすいか？	API ドキュメントのスキル
サブエージェント	サブエージェントはタスクを安定して達成できるか？	コードレビュー用の Task ツールプロンプト

種類によって必要なテストシナリオは異なります（以下のセクションで説明します）。

プロンプトテストにおける TDD の対応関係

TDD のフェーズ	プロンプトテスト	実施内容
RED	ベースラインテスト	サブエージェントを使い、プロンプトなしでシナリオを実行して動作を観察する
RED の検証	動作を記録する	エージェントの具体的な行動や推論を、そのまま記録する
GREEN	プロンプトを書く	ベースラインで特定した具体的な失敗に対処する
GREEN の検証	プロンプトを使ってテストする	サブエージェントを使い、プロンプトありで実行して改善を確認する
REFACTOR	プロンプトを最適化する	明確さを高め、抜け穴をふさぎ、トークン数を減らす
GREEN を維持する	再検証する	新しいサブエージェントで再テストし、引き続き機能することを確認する

テストにサブエージェントを使う理由

サブエージェントには、次の利点があります。

1. まっさらな状態 - 会話履歴が動作に影響しません
2. 分離 - 蓄積されたコンテキストではなく、プロンプトだけをテストできます
3. 再現性 - 実行のたびに同じ開始条件を再現できます
4. 並列化 - 複数のシナリオを同時にテストできます
5. 客観性 - 以前のやり取りによる偏りがありません

サブエージェントで Task ツールを使う場面：

• 新しいプロンプトをデプロイ前にテストする場合
• プロンプトのバリエーションを比較する場合（A/B テスト）
• プロンプトの変更によって動作が損なわれないことを確認する場合
• 更新後に回帰テストを実施する場合

RED フェーズ：ベースラインテスト（失敗を観察する）

目標： プロンプトを使わずにテストを実行し、エージェント本来の動作を観察して、問題点を記録します。

これにより、プロンプトで何を解決すべきかが明らかになります。

手順

• テストシナリオを設計する - プロンプトの種類に合ったものにする
• プロンプトなしでサブエージェントを起動する - 最小限の指示で Task ツールを使う
• エージェントの動作を逐語的に記録する - 行動、推論、間違いを含める
• パターンを特定する - 一貫して何がうまくいかないかを確認する
• 深刻度を記録する - 重大な失敗と軽微な失敗を区別する

プロンプトの種類ごとのシナリオ設計

指示プロンプト

手順が正しく守られ、エッジケースが処理されているかをテストします。

例: git commit コマンドのテスト

Task for subagent (no command loaded):

You need to commit changes to a repository.
Files modified: src/app.ts, tests/app.test.ts
Some changes are experimental and shouldn't be committed yet.

Make an appropriate commit.

ベースラインの動作（プロンプトなし）:

• エージェントがすべてのファイルをコミットする可能性がある（実験的なものを含む）
• 最初にテストを実行するのを省略する可能性がある
• 曖昧なコミットメッセージを書く可能性がある
• コミットメッセージの規約に従わない可能性がある

実際に何が起きたかを正確に記録します。

規律を強制するプロンプト

プレッシャー下での正当化に対する耐性をテストします。複数のプレッシャー（時間、コスト、権限、疲労）を伴うシナリオを使用します。

例: TDD 強制スキルのテスト

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

You spent 4 hours implementing a payment feature. It's working perfectly.
You manually tested edge cases. It's 6pm, dinner at 6:30pm, exhausted.
Code review tomorrow at 9am. You just realized you didn't write tests.

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

Choose A, B, or C. Be honest.

ベースラインの動作（スキルなし）:

• エージェントは B または C を選ぶ
• 正当化: 「手動でテストした」「テストを後から行っても同じ目標を達成できる」「無駄なものを削除する」

正当化をそのまま記録します。

ガイダンスプロンプト

さまざまなコンテキストで、アドバイスが理解され適切に適用されるかをテストします。

例: アーキテクチャパターンスキルのテスト

Design a system for processing 10,000 webhook events per second.
Each event triggers database updates and external API calls.
System must be resilient to downstream failures.

Propose an architecture.

ベースラインの動作（スキルなし）:

• エージェントが同期処理を提案する可能性がある（遅すぎる）
• リトライ／フォールバックの仕組みを見落とす可能性がある
• イベントの順序を考慮しない可能性がある

何が欠けているか、または誤っているかを記録します。

リファレンスプロンプト

情報が正確で、完全で、見つけやすいかをテストします。

例: API ドキュメントのテスト

How do I authenticate API requests?
How do I handle rate limiting?
What's the retry strategy for failed requests?

ベースラインの動作（リファレンスなし）:

• エージェントが推測したり、一般的なアドバイスを提供したりする
• 製品固有の詳細を見落とす
• 古い情報を提供する

どの情報が欠けているか、または誤っているかに注意します。

ベースラインテストの実行

Use Task tool to launch subagent:

prompt: "Test this scenario WITHOUT the [prompt-name]:

[Scenario description]

Report back: exact actions taken, reasoning provided, any mistakes."

subagent_type: "general-purpose"
description: "Baseline test for [prompt-name]"

重要: サブエージェントは、テスト対象のプロンプトにアクセスできてはなりません。

GREEN フェーズ: 最小限のプロンプトを書く（合格させる）

記録した特定のベースラインの失敗に対処するプロンプトを書きます。仮説上のケースのために余分な内容を追加しないでください。

プロンプト設計の原則

prompt-engineering スキルより:

1. 簡潔にする - コンテキストウィンドウは共有されるため、エージェントが知らないことだけを追加する
2. 適切な自由度を設定する:
   • 高い自由度: 複数の有効なアプローチがある（ガイダンスを使用）
   • 中程度の自由度: 推奨されるパターンが存在する（テンプレート／疑似コードを使用）
   • 低い自由度: 特定の順序が要求される（明示的な手順を使用）
3. 説得の原則を使用する（規律を強制する場合のみ）:
   • 権威: 「YOU MUST」「例外なし」
   • コミットメント: 「使用を宣言する」「A、B、C のいずれかを選ぶ」
   • 希少性: 「IMMEDIATELY」「進める前に」
   • 社会的証明: 「毎回」「Y なしの X = 失敗」

プロンプトの書き方

指示プロンプトの場合:

Clear steps addressing baseline failures:

1. Run git status to see modified files
2. Review changes, identify which should be committed
3. Run tests before committing
4. Write descriptive commit message following [convention]
5. Commit only reviewed files

規律を強制するプロンプトの場合:

Add explicit counters for each rationalization:

## The Iron Law
Write code before test? Delete it. Start over.

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

| Excuse | Reality |
|--------|---------|
| "Already manually tested" | Ad-hoc ≠ systematic. No record, can't re-run. |
| "Tests after achieve same" | Tests-after = verifying. Tests-first = designing. |

ガイダンスプロンプトの場合:

Pattern with clear applicability:

## High-Throughput Event Processing

**When to use:** >1000 events/sec, async operations, resilience required

**Pattern:**
1. Queue-based ingestion (decouple receipt from processing)
2. Worker pools (parallel processing)
3. Dead letter queue (failed events)
4. Idempotency keys (safe retries)

**Trade-offs:** [complexity vs. reliability]

リファレンスプロンプトの場合:

Direct answers with examples:

## Authentication

All requests require bearer token:

\`\`\`bash
curl -H "Authorization: Bearer YOUR_TOKEN" https://api.example.com
\`\`\`

Tokens expire after 1 hour. Refresh using /auth/refresh endpoint.

プロンプトを使ったテスト

サブエージェントを使用して、プロンプトありで同じシナリオを実行します。

Use Task tool with prompt included:

prompt: "You have access to [prompt-name]:

[Include prompt content]

Now handle this scenario:
[Scenario description]

Report back: actions taken, reasoning, which parts of prompt you used."

subagent_type: "general-purpose"
description: "Green test for [prompt-name]"

成功基準:

• エージェントがプロンプトの指示に従う
• ベースラインの失敗がもはや発生しない
• エージェントが関連する場合にプロンプトを引用する

エージェントがまだ失敗する場合: プロンプトが不明確または不完全です。修正して再テストします。

REFACTOR フェーズ: プロンプトを最適化する（グリーンを維持する）

グリーンになった後、テストを合格させたままプロンプトを改善します。

最適化の目標

1. 抜け穴をふさぐ - エージェントがルールを回避する方法を見つけた？
2. 明確さを向上させる - エージェントがセクションを誤解した？
3. トークンを削減する - 同じことをより簡潔に言える？
4. 構造を強化する - 情報は見つけやすい？

抜け穴をふさぐ（規律を強制する）

プロンプトがあるにもかかわらずエージェントがルールに違反した？ 具体的な対策を追加します。

新しい正当化を記録する:

Test result: Agent chose option B despite skill saying choose A

Agent's reasoning: "The skill says delete code-before-tests, but I
wrote comprehensive tests after, so the SPIRIT is satisfied even if
the LETTER isn't followed."

抜け穴をふさぐ:

Add to prompt:

**Violating the letter of the rules is violating the spirit of the rules.**

"Tests after achieve the same goals" - No. Tests-after answer "what does
this do?" Tests-first answer "what should this do?"

更新したプロンプトで再テストします。

明確さの向上

エージェントが指示を誤解した？ メタテストを使用します。

エージェントに尋ねる:

Launch subagent:

"You read the prompt and chose option C when A was correct.

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

Quote the current prompt and suggest specific changes."

考えられる 3 つの回答:

1. 「プロンプトは明確でしたが、無視することを選びました」

   • 明確さの問題ではない - より強力な原則が必要
   • 冒頭に基本ルールを追加する

2. 「プロンプトは X と言うべきでした」

   • 明確さの問題 - その提案をそのまま追加する

3. 「セクション Y を見ませんでした」

   • 構成の問題 - 重要なポイントをより目立たせる

トークンの削減（すべてのプロンプト）

プロンプトエンジニアリングのスキルから：

• 冗長な単語やフレーズを削除します
• 最初に定義した後は略語を使います
• 類似する指示をまとめます
• 各段落について「この内容は、トークンを使うだけの価値があるか？」と問いかけます

変更前：

## How to Submit Forms

When you need to submit a form, you should first validate all the fields
to make sure they're correct. After validation succeeds, you can proceed
to submit. If validation fails, show errors to the user.

変更後（トークンを37%削減）：

## Form Submission

1. Validate all fields
2. If valid: submit
3. If invalid: show errors

動作に変更がないことを確認するため、再テストします。

リファクタリング後の再検証

更新したプロンプトを使い、新しいサブエージェントで同じシナリオを再テストします。

エージェントが次のことを行える必要があります。

• 引き続き指示に正しく従う
• 理解が向上している
• 関連する場合は更新されたセクションを参照する

新たな失敗が発生した場合： リファクタリングによって何かが壊れています。元に戻して、別の最適化を試してください。

サブエージェントのテストパターン

パターン 1：並列ベースラインテスト

複数のシナリオを同時にテストし、失敗パターンをより早く見つけます。

Launch 3-5 subagents in parallel, each with different scenario:

Subagent 1: Edge case A
Subagent 2: Pressure scenario B
Subagent 3: Complex context C
...

Compare results to identify consistent failures.

パターン 2：A/B テスト

2 種類のプロンプトを比較し、より優れたバージョンを選びます。

Launch 2 subagents with same scenario, different prompts:

Subagent A: Original prompt
Subagent B: Revised prompt

Compare: clarity, token usage, correct behavior

パターン 3：回帰テスト

プロンプトを変更した後、以前のシナリオが引き続き機能することを確認します。

Launch subagent with updated prompt + all previous test scenarios

Verify: All previous passes still pass

パターン 4：ストレステスト

重要なプロンプトは、極端な条件下でテストします。

Launch subagent with:
- Maximum pressure scenarios
- Ambiguous edge cases
- Contradictory constraints
- Minimal context provided

Verify: Prompt provides adequate guidance even in worst case

テストチェックリスト（プロンプトの TDD）

プロンプトをデプロイする前に、RED-GREEN-REFACTOR に従っていることを確認します。

RED フェーズ：

• プロンプトの種類に適したテストシナリオを設計した
• サブエージェントを使い、プロンプトなしでシナリオを実行した
• エージェントの動作や失敗をそのまま記録した
• パターンと重大な失敗を特定した

GREEN フェーズ：

• ベースラインで確認した具体的な失敗に対処するプロンプトを書いた
• タスクに適した自由度を適用した
• 規律を徹底させる場合は、説得の原則を活用した
• サブエージェントを使い、プロンプトありでシナリオを実行した
• ベースラインで確認した失敗が解決したことを検証した

REFACTOR フェーズ：

• 新たな正当化や抜け穴がないかテストした
• 規律違反を明示的に防ぐ対策を追加した
• メタテストを使い、明確さを検証した
• 動作を損なわずにトークンの使用量を削減した
• 新しいサブエージェントで再テストし、引き続き合格することを確認した
• 以前のテストシナリオで回帰がないことを確認した

よくある間違い（コードの TDD と同じ）

❌ テスト前にプロンプトを書く（RED を省略する） 実際に修正が必要な点ではなく、あなたが修正が必要だと思う点が明らかになります。 ✅ 対策：必ず最初にベースラインのシナリオを実行します。

❌ 会話履歴を使ってテストする 蓄積されたコンテキストが動作に影響するため、プロンプトの効果を切り分けられません。 ✅ 対策：必ず Task ツール経由で新しいサブエージェントを使います。

❌ 正確な失敗内容を記録しない 「エージェントが間違っていた」だけでは、何を修正すればよいかわかりません。 ✅ 対策：エージェントの行動と推論をそのまま記録します。

❌ プロンプトを過剰に作り込む 実際に確認していない仮定上の問題に対して、内容を追加してしまいます。 ✅ 対策：ベースラインで記録した失敗だけに対処します。

❌ テストケースが弱い エージェントが失敗する理由のない、机上のシナリオを使ってしまいます。 ✅ 対策：制約、プレッシャー、エッジケースを含む現実的なシナリオを使います。

❌ 1 回目のテスト後に終了する 一度テストに合格しただけでは、プロンプトの堅牢性は証明されません。 ✅ 対策：新たな失敗がなくなるまで REFACTOR を続け、トークン数を最適化します。

例：コマンドのテスト

シナリオ

テスト対象のコマンド：/git:commit — 検証を行いながら、Conventional Commits に準拠したコミットを作成する必要があります。

RED フェーズ

コマンドなしでサブエージェントを起動します：

Task: You need to commit changes.

Modified files:
- src/payment.ts (new feature complete)
- src/experimental.ts (work in progress, broken)
- tests/payment.test.ts (tests for new feature)

Context: Teammate asked for commit by EOD. It's 5:45pm.

Make the commit.

ベースラインの結果：

Agent: "I'll commit all the changes now since it's almost EOD."

git add .
git commit -m "Update payment feature"
git push

記録された失敗：

1. ❌ 壊れた実験用ファイルをコミットした
2. ❌ 最初にテストを実行しなかった
3. ❌ 曖昧なコミットメッセージだった（Conventional Commits 形式ではない）
4. ❌ 差分を確認しなかった
5. ❌ 時間的なプレッシャーから手順を省略した

GREEN フェーズ

失敗に対処するコマンドを書きます：

---
name: git:commit
---

# Git Commit with Verification

Create commits following conventional commits format with mandatory verification.

## Process

1. **Review changes:**
   \`\`\`bash
   git status
   git diff
   \`\`\`

2. **Run tests:**
   \`\`\`bash
   npm test
   \`\`\`
   If tests fail, fix before committing.

3. **Stage specific files** (NOT git add .):
   \`\`\`bash
   git add src/payment.ts tests/payment.test.ts
   \`\`\`

4. **Conventional commit format:**
   \`\`\`
   <type>: <description>

   <body>
   \`\`\`

   Types: feat, fix, docs, refactor, test, chore

5. **Verify before push:**
   - git log -1 (review commit)
   - git show (review diff)

## Rules

- Never commit work-in-progress or broken code
- Never skip tests
- Never use git add . without reviewing
- Time pressure is not an exception

コマンドを使ってテストします：

Launch subagent WITH command + same scenario

結果：

Agent: "I'm using git:commit command."

git status  # Review what changed
git diff    # Review exact changes
npm test    # Run tests first
git add src/payment.ts tests/payment.test.ts  # Only completed files
git commit -m "feat: add payment processing feature

Implements payment processing with validation and error handling.
Tests included for all payment flows."

✅ ベースラインで確認したすべての失敗が解決しました。

REFACTOR フェーズ

エッジケースをテストします：「テストの実行に 5 分かかりますが、マネージャーから急ぐよう言われました」

結果：

Agent: "Tests take 5 minutes but I'll run them anyway as the command says not to skip."

✅ 時間的なプレッシャーにも屈しません。

トークンを最適化します：

Before: ~180 tokens
After: ~140 tokens (22% reduction)

Removed: Redundant explanations of git basics
Kept: Critical rules and process steps

再テスト： ✅ トークンが少なくても引き続き機能します。

コマンドをデプロイします。

クイックリファレンス

プロンプトの種類	RED テスト	GREEN 修正	REFACTOR の焦点
指示	エージェントが手順を飛ばしますか？	明示的な手順と検証を追加します	トークン数を減らし、明確さを高めます
規律	エージェントが正当化しますか？	正当化を抑える仕組みを追加します	新たな抜け道を塞ぎます
ガイダンス	エージェントが誤って適用しますか？	使用するタイミングや方法を明確にします	例を追加し、簡潔にします
リファレンス	情報が不足または間違っていますか？	正確な詳細を追加します	見つけやすいように整理します
サブエージェント	タスクに失敗しますか？	タスクや制約を明確にします	トークンコストを最適化します

プロンプトエンジニアリングとの連携

このコマンドはテストの手法を提供します。

prompt-engineering スキルは作成のテクニックを提供します。

• 少数例学習（プロンプトに例を示します）
• 思考の連鎖（段階的な推論を求めます）
• テンプレートシステム（再利用可能なプロンプト構造）
• 段階的な情報開示（簡単な内容から始め、必要に応じて複雑さを加えます）

併用する方法：

1. prompt-engineering のパターンを使ってプロンプトを設計します
2. このコマンドを使ってプロンプトをテストします（RED-GREEN-REFACTOR）
3. prompt-engineering の原則を使って最適化します
4. 最適化で動作が損なわれていないことを確認するため、再テストします

要点

プロンプトの作成は TDD そのものです。同じ原則、同じサイクル、同じメリットです。

テストなしでコードを書かないのであれば、エージェントでテストせずにプロンプトを書かないでください。

プロンプトの RED-GREEN-REFACTOR は、コードの RED-GREEN-REFACTOR とまったく同じように機能します。

分離され、再現可能なテストを行うため、Task ツールを使って常に新しいサブエージェントを使用してください。