メニュー
実験駆動の反復改善ループ（autoresearch 方式）。毎回フレッシュなサブエージェントで 1変更→測定→保持 or revert。progress.md がイテレーション間の記憶。パフォーマンス最適化、リファクタリング、UI改善、バグ修正の試行錯誤に使う。「最適化して」「パフォーマンス改善」「リファクタリング」「試行錯誤して」「実験的に改善」で発動。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
新機能を実装まで一気通貫で走らせる action skill。Agent Teams で要件・設計・タスク分解・実装・quality-gate を自動実行し、コードがコミット可能な状態になるまで止まらない（Sisyphus Loop）。auto mode でも planning ではなく action として積極発動する。「実装して」「作って」「機能を追加して」「新機能を作りたい」「要件から実装まで一気に」「計画して」「この機能を実装したい」で発動。
完了宣言の前にエビデンスを収集・確認する。証拠なき成功宣言は不正。「完了前チェック」「本当に動く？」「確認して」「検証して」「コミット前に確認」で発動。実装完了時、バグ修正後、テスト通過を宣言する前に使う。
要件が曖昧なとき、ソクラテス式に1問ずつ質問して要件を掘り下げる。十分に明確になったら discovery-council にハンドオフ。「要件が曖昧」「何を作ればいいか」「掘り下げて」「インタビューして」で発動。※ 完成した plan/design を詰問するなら grill、非対話で一括批判するなら critic。
完成した plan/design を対話で容赦なく詰問し、実装前に穴を潰す。決定木を1枝ずつ降り、各質問に推奨回答を添える。コードで答えが出る点は聞かず自分で調べて埋める。「grill して」「叩いて」「この設計で大丈夫?」「plan を詰めて」「設計を対話レビュー」で発動。※ ゼロから要件を掘り下げるなら deep-interview、非対話で一括批判レポートなら critic。
backlog（atoms/pipeline/outputs）と skill ヘルス（usage/duration/unused）を統合分析し 1 レポートで提示する。kawai 氏型 analytics ループの起点。「次に何やる？」「atom 整理」「放置案件」「stale」「振り返り」「retro」「skill 使用統計」「unused skill」「atom-suggest」で発動。
designer エージェントによるアーキテクチャ設計。requirements.md を基に design.md を作成。「設計して」「アーキテクチャ設計して」「アーキテクチャを考えて」「設計書を作って」で発動。
| name | experiment |
| description | 実験駆動の反復改善ループ（autoresearch 方式）。毎回フレッシュなサブエージェントで 1変更→測定→保持 or revert。progress.md がイテレーション間の記憶。パフォーマンス最適化、リファクタリング、UI改善、バグ修正の試行錯誤に使う。「最適化して」「パフォーマンス改善」「リファクタリング」「試行錯誤して」「実験的に改善」で発動。 |
| argument-hint | <optimization goal and measurement method> |
| allowed-tools | ["Read","Write","Edit","Glob","Grep","Bash","Agent","Monitor","AskUserQuestion","PushNotification"] |
| model | opus |
| effort | high |
| paths | ["**/*.py","**/*.ts","**/*.tsx","**/*.js","**/*.jsx","**/*.sh","**/*.rs","**/*.go"] |
毎回フレッシュなコンテキストで実験。記憶はファイルに、判断は毎回リセット。
Sisyphus が計画駆動（要件→設計→実装）なのに対し、Experiment は実験駆動（試す→測る→残す or 戻す）。 autoresearch の原則: コンテキスト劣化を防ぐため、各イテレーションを独立したサブエージェントで実行する。
$ARGUMENTS
!jj diff --stat 2>/dev/null || git diff --stat HEAD 2>/dev/null || echo "変更なし"
!jj log -r 'ancestors(@, 5)' --no-graph 2>/dev/null || git log --oneline -5 2>/dev/null || echo "履歴なし"
ゴール、メトリクス、ベースラインを設定し、progress.md に書き込む。
# Experiment Progress
## Goal
[何を改善するか]
## Metric
[どう測定するか — コマンドを具体的に書く]
## Baseline
[初期測定値]
## Current Best
[現在の最良値 — 初期はベースラインと同じ]
## Iterations
<!-- 各イテレーションの結果が追記される -->
## Failed Hypotheses
<!-- 棄却された仮説のリスト — 次のサブエージェントが同じことを試さないために -->
ベースラインなしに改善は測れない。 最初に必ず測定を実行し、progress.md に記録する。
以下を ゴール達成まで 繰り返す。
┌─────────────────────────────────────────────────────────┐
│ Iteration N │
│ │
│ 1. Agent spawn（毎回フレッシュなコンテキスト） │
│ → サブエージェントは progress.md だけを読んで実行 │
│ → 1つの仮説を立て、1つの変更を実装し、測定して報告 │
│ │
│ 2. メインエージェントが結果を評価 │
│ 改善 → コミットして保持 │
│ jj describe -m "experiment: [仮説] → [結果]" │
│ jj new │
│ progress.md の Current Best を更新 │
│ │
│ 悪化/変化なし → revert │
│ jj abandon │
│ progress.md の Failed Hypotheses に追記 │
│ │
│ 3. 次のイテレーションへ │
└─────────────────────────────────────────────────────────┘
Metric コマンドの実行に 10秒以上かかる場合（フルテストスイート、ベンチマーク等）、Monitor を使って測定を非同期化する。テスト実行中に progress.md の更新や次の仮説の検討を並行できる。
判定基準: Step 1 のベースライン測定で実行時間を確認。10秒以上 → Monitor 方式、10秒未満 → サブエージェント内で直接測定（従来方式）。
┌─ Monitor 方式の Iteration N ───────────────────────────┐
│ │
│ 1. Agent spawn → 変更のみ実装して報告（測定は省略） │
│ │
│ 2. Monitor で測定コマンドを非同期実行 │
│ Monitor: │
│ description: "Experiment iteration N measurement" │
│ timeout_ms: 300000 │
│ persistent: false │
│ command: "<progress.md の Metric コマンド>" │
│ │
│ 3. 測定待ちの間にメインエージェントが: │
│ - progress.md の Iterations セクションに仮説を記録 │
│ - 次のイテレーションの仮説を検討 │
│ │
│ 4. Monitor から結果が到着 → 評価して keep/revert │
└─────────────────────────────────────────────────────────┘
Monitor 方式の場合、サブエージェントの spawn テンプレートから手順 5（測定）を省略する。
Agent:
description: "Experiment iteration N"
prompt: |
あなたは実験の1イテレーションを担当する独立したエージェントです。
## 手順
1. progress.md を Read して、ゴール・メトリクス・過去の結果を把握
2. Failed Hypotheses を確認し、同じアプローチを繰り返さない
3. 新しい仮説を1つ立てる
4. その仮説に基づいて **1つだけ** 変更を実装
5. progress.md に書かれた Metric コマンドを実行して測定
6. 以下のフォーマットで結果を報告:
## Report
- Hypothesis: [仮説]
- Change: [何を変えたか]
- Files: [変更したファイル]
- Before: [変更前の測定値]
- After: [変更後の測定値]
- Verdict: improved / degraded / neutral
# 保持する場合
jj describe -m "experiment: [仮説] → [結果: +XX% 改善]"
jj new
# revert する場合
jj abandon
ゴール達成または停止後、progress.md の内容をもとに結果をまとめる。
## 実験結果
### ゴール: [目標]
### ベースライン: [初期値]
### 最終値: [最終値]（[改善率]）
### イテレーション数: N（成功: X, 棄却: Y）
### 成功した変更
1. [仮説] → [結果]
2. ...
### 棄却した仮説
1. [仮説] → [棄却理由]
2. ...
### 学び
- [次回の実験に活かせること]
完了通知: 実験が 10 分以上走った または バックグラウンド実行が前提だった場合、PushNotification で結果サマリを送る（例: experiment 完了: 7 iter, +12% 改善、revert 3 件）。短時間（数分以内）で収束した場合や、ユーザーが画面を見ている可能性が高い場合は送らない。
Step 1 のゴール設定から開始してください。まずベースラインを測定し、progress.md を作成。