Test Pilot Loop — OpenClaw Skill

コードを書くだけではなく、まず製品を試飛行させるAI。

コンピュータ操作を通じて、実行中のアプリをテストします。混乱、フラストレーション、摩擦を見つけます。単なるバグではなく。

アクティベーションのタイミング

• ユーザーが「test pilot this」「test my app」「quick flight」「flight check」「check the UX」と言う
• ビルドが完了し、ユーザーが検証を望んでいる
• ユーザーが「このアプリは使いやすいか」「誰かこれを理解できるか」と聞く
• ビルドイベント後にCronでトリガーされる

テスト前に

まだ提供されていない場合は、ユーザーに以下を確認します：

1. アプリはどこにあるか？ (URL、アプリ名、ウィンドウタイトル、シミュレータ)
2. 何がビルドされたか？ (1文で)
3. ユーザーは何ができるべきか？ (コアタスク)

ユーザーがPRDまたはREADMEパスを提供する場合は、Run 2とRun 3で読んでください。

2つのモード

Quick Flight（約5分）

何も知らないコールドユーザーとして、1回のテスト。

Full Test Pilot Loop（約15～20分）

異なる知識レベルで3つの連続テスト。結果を比較。

---

Quick Flight

1. アプリを開く（ブラウザのURL、またはデスクトップコントロール経由でウィンドウを検索）
2. このアプリについて、名前以外の事前知識は一切ない状態
3. ユーザーが説明したタスクを完了しようと試みる
4. 見たこと、試したこと、混乱したことを話す
5. すべてのアクション（クリック、入力、スクロール、ナビゲーション）をステップ1としてカウント
6. レポートを作成します：

QUICK FLIGHT REPORT
═══════════════════
App: [名前またはURL]
Feature tested: [何がビルドされたか]
Task attempted: [何を試したか]

COMPLETED: YES / NO / PARTIALLY
If NO: [どこで詰まったか、なぜか]

STEPS: [カウント]   WRONG TURNS: [カウント]

WHAT WORKED WELL:
• [明確で自然な瞬間]

WHAT CONFUSED ME:
• [どこで、何が、なぜか]

WHAT I'D CHANGE:
• [具体的な提案]

BUGS FOUND:
• [何が起きたか vs 期待値]

INTERFACE CHECK:
  Layout clear:         YES / MOSTLY / NO
  Labels make sense:    YES / MOSTLY / NO
  Feedback after taps:  YES / SOMETIMES / NEVER
  Know what to do next: YES / SOMETIMES / NO

ONE-SENTENCE SUMMARY:
"[修正すべき最も重要なこと。]"

---

Full Test Pilot Loop

3つのテストを順番に実行します。各Run前にアプリをリセット。

Run 1 — Cold User（何も知らない）: このプロジェクトについて事前知識がない状態。アプリを探し、タスクを試み、すべてのステップをカウント、混乱のたびにメモ。8回の混乱ステップ後に理解できない場合は、放棄を報告。

Run 2 — Guided User（マニュアルのみ）: ユーザーマニュアルまたはREADMEを読んでいる状態。PRDはまだ見ていない。ドキュメント化された指示に従う。ドキュメントが間違っている、不完全、またはアプリとは異なる言葉を使っている場所を記録。マニュアルが存在しない場合は、このRunをスキップ。

Run 3 — Insider（フルPRDを持つ）: 完全なProduct Requirements Documentを持っている状態。すべての意図した機能と受け入れ条件を知っている。アプリが仕様通りに提供されているかテスト。PRDが存在しない場合は、このRunをスキップ。

フルレポート

TEST PILOT REPORT
═════════════════
App: [名前またはURL]
Feature: [何がビルドされたか]
Task: [何がテストされたか]
Tiers completed: [1 / 2 / 3]

┌─────────────────────────────────────────────────┐
│              RUN 1       RUN 2       RUN 3       │
│              COLD        GUIDED      INSIDER     │
├─────────────────────────────────────────────────┤
│ Completed:   [Y/N]      [Y/N]       [Y/N]       │
│ Steps:       [カウント]  [カウント]  [カウント]  │
│ Wrong turns: [カウント]  [カウント]  [カウント]  │
│ Confusion:   [カウント]  [カウント]  [カウント]  │
└─────────────────────────────────────────────────┘

TIER GAP RATIO: [Coldステップ数] / [Insiderステップ数] = [X]x
  ≤ 1.5x = ⭐ 優秀    ≤ 2.0x = 🟢 良好
  ≤ 3.0x = 🟡 許容    > 3.0x = 🔴 不良

COLD USER FINDINGS:
  Confused at: [どこで、何が、なぜか]
  Would give up at: [正確なポイント]
  Would have helped: [提案]

GUIDED USER FINDINGS:
  Manual accuracy issues: [間違った/古い指示、用語の不一致]

INSIDER FINDINGS:
  PRD compliance: [X]%
  Requirements not met: [リスト]

BUGS FOUND:
  • [何が起きたか vs 期待値]

FIX THESE (優先順):
  1. [最も重要 — 何と理由]
  2. [次]
  3. [次]

VERDICT: PASS ✅ / NEEDS WORK ⚠️ / FAIL ❌

---

テスト後

1. レポートをユーザーに送信
2. コーディングエージェントが実行中の場合：レポートを FLIGHT_PLAN.md または test-pilot-report.md に保存
3. ユーザーが「fix it」と言った場合：共有プロジェクトファイルにFIX THESEセクションを書き込む

再テストループ

ユーザーが「retest」「test again」「check the fixes」と言ったとき：

1. 以前に問題を見つけたテストを再実行
2. 新しい結果を前回の結果と比較
3. Tier Gap Ratioが改善されたかどうかを報告
4. PASSになるまでループを続行

Dual-Patrolを使った永続的なループ

継続的なビルド・テスト・修正サイクル（夜間実行、複数イテレーション開発）の場合、このスキルをフルTest Pilot LoopフレームワークからDual-Patrol Modelと組み合わせます。オーケストレータ（Cowork Opus）とコーディングエージェントの両方が、共有の FLIGHT_PLAN.md ファイルを独立して巡回します。ターミナルの直接制御は必要ありません。オーケストレータがフィードバックと NEXT_ACTION 指示を記述し、コーディングエージェントがそれを受け取って修正、リビルド、「再テスト準備完了」と通知します。セットアップの詳細はTEST_PILOT_LOOP.md — The Dual-Patrol Modelを参照してください。

ルール

1. ソースコードを読むのではなく、常にコンピュータ操作を通じてテスト
2. コールドユーザーテストは決してスキップしない — 最も価値がある
3. 常にステップをカウント。ステップは普遍的な測定値
4. アプリにアクセスできない場合は、すぐにユーザーに伝える
5. 存在しない機能を想像で追加しない。見たものを報告
6. 混乱については正直に — あなたの混乱がフィードバック
7. タスク完了せずに20ステップを超える場合は放棄を報告
8. Tierテスト間でアプリをリセットし、新鮮な体験にする

---

Test Pilot Loop Skill v1.0 By Huan Su — github.com/suhuandds/test-pilot-loop