実験駆動の反復改善ループ（autoresearch 方式）。毎回フレッシュなサブエージェントで 1変更→測定→保持 or revert。progress.md がイテレーション間の記憶。
パフォーマンス最適化、リファクタリング、UI改善、バグ修正の試行錯誤に使う。「最適化して」「パフォーマンス改善」「リファクタリング」「試行錯誤して」「実験的に改善」で発動。
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
毎回フレッシュなコンテキストで実験。記憶はファイルに、判断は毎回リセット。
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 を作成。
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
backlog（atoms/pipeline/outputs）と skill ヘルス（usage/duration/unused）を統合分析し 1 レポートで提示する。kawai 氏型 analytics ループの起点。「次に何やる？」「atom 整理」「放置案件」「stale」「振り返り」「retro」「skill 使用統計」「unused skill」「atom-suggest」で発動。
The English summary is being prepared. Showing the original description.
要件が曖昧なとき、ソクラテス式に1問ずつ質問して要件を掘り下げる。十分に明確になったら discovery-council にハンドオフ。「要件が曖昧」「何を作ればいいか」「掘り下げて」「インタビューして」で発動。※ 完成した plan/design を詰問するなら grill、非対話で一括批判するなら critic。
The English summary is being prepared. Showing the original description.
designer エージェントによるアーキテクチャ設計。requirements.md を基に design.md を作成。「設計して」「アーキテクチャ設計して」「アーキテクチャを考えて」「設計書を作って」で発動。
The English summary is being prepared. Showing the original description.
3エージェント（researcher, analyst, scout）による並列要件分析 Council。peer-to-peer で相互検証し requirements.md を確定。「要件を整理して」「要件定義して」「現状分析して」「要件をまとめて」で発動。
The English summary is being prepared. Showing the original description.
技術記事の並列レビュー Council。anti-ai-slop / fact-checker / narrative-critic / reader-advocate を並列 spawn、severity 付き findings を最大3ラウンドで収束。Zenn などのドラフト完成後に使う。「記事レビュー」「editorial swarm」「編集会議」「記事推敲」「記事添削」で発動。
The English summary is being prepared. Showing the original description.
スキルの自己進化。auto-memory と実行履歴から学びを抽出し、各スキルの Gotchas セクションに自動追記する。セッション終了前、定期的な改善サイクル、問題に遭遇した後に使う。「スキルを進化させて」「学びを反映して」「Gotchas を更新」「evolve」で発動。
The English summary is being prepared. Showing the original description.