Simmer はあなたが書いたもの — 売り込みメール、設計仕様、システムプロンプト、API契約書 — を繰り返しの構造化されたパスで改善します。「より良い」とする2〜3の基準を定義すると、成果物が改善しなくなるかあなたが止めるまで、生成-評価-振り返りのループを実行します。
インストール
/plugin install simmer@2389-research
できること
各イテレーションは3ステップです:
生成は評価者のフィードバックをもとに成果物の改善版を作ります。生成者はスコアを見ません — 直前のベスト候補と次に何を直すかという単一の指示だけを見ます。
評価は新しい候補を各基準で1〜10でスコアリングし、次に直すべき最も重要な1つを選びます。この集中したフィードバックをASI (Actionable Side Information) と呼びます。評価者は常に元のシードとそのスコアをキャリブレーションアンカーとして持つため、イテレーション間でスコアの一貫性が保たれます。
振り返りは軌跡を記録します — 全イテレーションのスコアテーブル — とここまでのベスト候補を追跡します。イテレーションが退行した場合、次の生成者は悪い方ではなくベスト版を受け取ります。
実行中のスコアテーブルはこのようになります:
| Iter | Criterion A | Criterion B | Criterion C | Composite | Key Change |
|---|---|---|---|---|---|
| 0 | 4 | 5 | 3 | 4.0 | seed |
| 1 | 7 | 5 | 4 | 5.3 | specific problem statement |
| 2 | 7 | 6 | 6 | 6.3 | low-friction CTA |
| 3 | 7 | 7 | 8 | 7.3 | peer-sharing tone |
各バッチのイテレーション後、続けるかどうかを確認します。
仕組み
4つのサブスキル (setup、generator、judge、reflect) はお互いのコンテキストから意図的に分離されています:
- 生成者はスコアを見ない — 品質ではなく数字を最適化することを防ぐため
- 評価者は前のイテレーションのスコアを見ない — アンカリングバイアスを防ぐため
- Reflect だけが全体像を持つ — 何を引き継ぐかを決めるのはこの役割だけ
この分離が主な設計の賭けです。「全部直して」という分散したフィードバックは横移動を生みがちです。1ラウンドに1つの集中した修正が積み重なると本当の改善になります。
Claudeが読んで作れるものなら何でも対応: ドキュメント、メール、プロンプト、仕様書、創作文章、API設計。成果物のタイプに合わせて基準を選んでください。
必要要件
プラグインシステムが有効なClaude Code。2389プラグインマーケットプレイスの一部 — test-kitchenファミリーから独立してインストール可能。