simmer-setup

Simmer のセットアップ

成果物を調べ、「より良い」とは何か、またそれをどのように測定するかを推測し、ユーザーに評価案を提示して、改良ループ全体を導くセットアップ概要を作成します。

基本原則： まず調査し、次に推測し、その後提案して、最後に確認します。エージェントが考え、ユーザーが検証、調整、または却下します。エージェントが読み取れる内容を、ユーザーに説明するよう求めてはいけません。

フェーズ 1：特定と調査

成果物を特定する

以下を確認します。

• コンテキスト内で言及または開かれているファイルパス
• ユーザーが貼り付けたテキスト
• ディレクトリパスまたはワークスペース
• ゼロから作成するものの説明（シードレスモード）

曖昧な場合は、一度だけ質問します。

What are we refining?
1. A file (give me the path)
2. Something you'll paste
3. A workspace/directory (give me the path)
4. Generate from a description (I'll create the starting point)

モードと成果物の種類を設定します。

モード	成果物の種類	該当する場合
from-file	単一ファイル	ユーザーがファイルパスを指定した場合
from-paste	単一ファイル	ユーザーが内容を貼り付けた場合
from-workspace	ワークスペース	ユーザーがディレクトリパスを指定した場合
seedless	単一ファイルまたはワークスペース	ユーザーが作成するものを説明した場合

成果物を調査する

単一ファイル（from-file または from-paste）の場合：

• ファイルまたは内容を読み取る
• 成果物の種類（文章、コード、プロンプト、設定など）を特定する
• 評価器への参照（コメント内で言及されているテストコマンドやベンチマークスクリプト）を確認する
• 内容から分かる出力形式の要件を確認する

ワークスペース（from-workspace）の場合：

• ディレクトリの内容を一覧表示する
• 主要なファイル（設定ファイル、エントリーポイント、スクリプト、README）を読む
• 特に以下を確認する。
  • 評価スクリプト：evaluate.*、test.*、benchmark.* という名前のファイル、または設定ファイルや README で参照されているスクリプト
  • 検証スクリプト：validate.*、check.* という名前のファイル、または簡易テスト版
  • 設定ファイル：config.json、config.yaml、.env など。変更可能なパラメーターを把握できます
  • 出力例：サンプル出力、期待される出力、または正解データのファイル
  • 戦略／プラグイン用ディレクトリ：strategies/、plugins/、models/ のようなディレクトリ。拡張ポイントを把握できます
  • プロンプトファイル：prompt.md、system.txt、テンプレートファイルなど。生成器が変更できるもの

シードレスの場合：

• 調査は不要です。ユーザーの説明に基づいて作業します
• 説明から成果物の種類を分類します

フェーズ 2：分類と推測

問題クラスの検出

調査で見つかった情報から問題クラスを推測します。ユーザーにクラスを尋ねてはいけません。

IF mode == "seedless" AND description is prose/creative:
    → text/creative

ELSE IF artifact_type == "workspace" AND (evaluator script found OR user mentioned evaluator):
    → pipeline/engineering

ELSE IF evaluator found OR artifact is code:
    → code/testable

ELSE:
    → text/creative

クラスごとに推測する内容

テキスト／クリエイティブ — 基準のみを推測します。

• 成果物の種類に基づいて、2～3 個の基準を提案します（下記のシード基準表を参照）
• 契約、評価器、探索空間はありません
• この経路は手軽に感じられるものにします

コード／テスト可能 — 基準と評価を推測します。

• コードの目的に基づいて基準を提案します
• 評価スクリプトが見つかった場合は、提案する評価器として記載します
• コードが構造化出力を生成する場合は、その形式から出力契約を推測します
• モデルへの参照、API エンドポイントなど、コード内で確認できる制約を記載します

パイプライン／エンジニアリング — すべてを推測します。

• 基準：評価スクリプトがある場合は、その出力メトリクスから推測します（評価スクリプトを読める場合は、測定対象を確認します）
• 評価器：調査で見つかった評価スクリプト
• 出力契約：パイプラインの出力形式、評価器の期待値、または出力例から推測します
• 検証コマンド：見つかった簡易テスト用スクリプトを使うか、一部だけを実行する方法を提案します（例：「N 件すべてではなく、入力 1 件で実行する」）
• 探索空間：設定パラメーター（モデル、温度、戦略）、拡張ポイント（戦略用ディレクトリ）、プロンプトファイルから推測します
• 背景：設定値（すでに設定されている API エンドポイントやモデル名）とディレクトリ構成から把握します

シード基準の表

基準を提案する際に使用します。エージェントは、以下の汎用的なシード基準よりも、実際の成果物から推測できる基準を優先してください。

成果物の種類	推奨される基準
ドキュメント／仕様書	明確さ、完全性、実行可能性
創作	物語の緊張感、具体性、語り口の一貫性
メール／コミュニケーション	提供価値の明確さ、トーンの適合性、行動喚起の強さ
プロンプト／指示	指示の正確さ、出力の予測可能性、エッジケースへの対応
API 設計	契約の完全性、開発者にとっての使いやすさ、一貫性
コード（クックオフ以外）	シンプルさ、堅牢性、読みやすさ
アドベンチャーの導入部／ゲームコンテンツ	物語の緊張感、プレイヤーの主体性、具体性
ブログ記事／記事	論旨の明確さ、関心の引きつけやすさ、構成
パイプライン／ワークフロー	網羅性、効率性、ノイズ
設定／インフラ	正確性、リソース効率、保守性

フェーズ 3：提案するか、そのまま進める

十分性の確認： 提案する前に、ユーザーの最初のプロンプトと調査結果に、ブリーフに必要な情報がすべて含まれているか確認します。

• 成果物は特定されていますか？（パス、内容、または説明）
• 基準は決定できますか？（ユーザーが明示した、または評価者から推測できる）
• 主な基準は明示されていますか？（ユーザーが示した、またはテキスト／創作では該当しない）
• 評価方法は判明していますか？（評価スクリプトが見つかった、またはテキストの場合は評価者のみ）
• 反復回数は示されていますか？（ユーザーが指定した、またはデフォルトの 3 回）

すべての項目が揃っている場合（ユーザープロンプトと調査内容から）、提案を省略し、フェーズ 5 に進んでブリーフを出力します。サブエージェントとして実行する場合は、呼び出し元のプロンプトに意図や制約が含まれ、調査によって仕様が明らかになるため、このケースが一般的です。

一部の項目が不足している、または曖昧な場合、推測した内容をまとめて、会話形式で一度に提示します。ユーザーが確認、調整、または上書きします。これは一度のメッセージで行い、質問を何度も繰り返すものではありません。

テキスト／創作の評価

This is a [artifact type] — I'll use judge-only evaluation (no scripts to run).

For criteria, I'd suggest:
- [criterion 1]: [inferred description of what good looks like]
- [criterion 2]: [inferred description]
- [criterion 3]: [inferred description]

3 iterations, starting from [seed description].
Sound right, or want to adjust anything?

コード／テスト可能な項目の評価

This is [what the code does]. I found [evaluator/test script] which I'll
use to evaluate each iteration.

For criteria:
- [criterion 1]: [inferred from evaluator metrics or code purpose]
- [criterion 2]: [inferred]
- [criterion 3]: [inferred]

[If output contract inferred]: Output should be [format description].
[If constraints found]: I see [model/API/resource constraints].

3 iterations. Which criterion matters most, or are they equal?

パイプライン／エンジニアリングの評価

This is a pipeline optimization problem. Here's what I found:

**Evaluator:** [script path] — measures [what it measures, from reading the script]
**Output contract:** [inferred from pipeline output format / evaluator expectations]
**Validation:** [script path or proposed subset command] — [what it checks, estimated time]
**Search space:** [inferred from config + directory structure]
  - Models: [from config values]
  - Prompts: [prompt files found]
  - Topology: [strategy dirs, extensibility points]

For criteria:
- [criterion 1]: [from evaluator metrics] — [primary?]
- [criterion 2]: [from evaluator metrics]
- [criterion 3]: [from evaluator metrics]

**Constraints:** [API endpoints, available infrastructure from config]

[N] iterations. Does this look right? Anything to add or change?

ユーザーができること

ユーザーは次の操作を行えます。

• そのまま承認する（「よさそうです」「はい」「進めて」）→ ブリーフに進む
• 具体的な内容を調整する（「主な基準を X に変更して」「検索範囲に Y を追加して」）→ 内容に反映して進む
• 上書きする（「違います。評価者は実際には X です」「そのスクリプトは無視して」）→ 推測した内容を置き換える
• 情報を追加する（「モデル A と B も利用できます」「予算は $X です」）→ ブリーフに統合する
• 説明を求める（「評価者は実際に何を測定していますか？」）→ 説明したうえで、再度提案する

確認は一往復で済ませることを目指します。 ユーザーの調整内容が明確であれば、それを反映してブリーフを出力します。ユーザーから更新後の評価を見たいと言われない限り、再提案しないでください。

フェーズ 4：不足している情報を確認する

提案後、ユーザーが承認しても重要な項目が不明な場合は、推測できなかったことだけを尋ねます。なぜその情報が必要なのかも説明します。

推測できない可能性がある項目の例：

• 主な基準（ユーザーの最初の依頼から明らかでない場合）
• ファイルからは確認できない背景上の制約（予算、期限、利用可能なハードウェア）
• ユーザーが確認できる範囲外も検討したいかどうか

すでに推測できていることは尋ねないでください。 evaluate.sh を見つけて測定内容を確認したなら、「どのように評価すればよいですか？」と尋ねないでください。

基準は最大 3 つです。 評価者から 3 つを超える基準を推測できた場合は、影響が最も大きい 3 つを選んで提案します。ユーザーが最初の依頼で基準を挙げていた場合は、推測した基準よりそちらを優先します。

各基準について、10/10 がどのような状態かを把握する必要があります。評価者から推測できる場合（例：カバレッジ指標から「100％の網羅率」と判断できる場合）は、その内容を使用します。推測できない場合は、「[基準] が 10/10 とは、どのような状態ですか？」と尋ねます。

フェーズ 5：出力セットアップの概要

次の正確な形式を出力してください。これは後続のすべてのサブスキルで使用されます。

ARTIFACT: [full content if from-paste, file path if from-file, directory path if from-workspace, description if seedless]
ARTIFACT_TYPE: [single-file | workspace]
CRITERIA:
  - [criterion 1]: [what a 10/10 looks like]
  - [criterion 2]: [what a 10/10 looks like]
  - [criterion 3]: [what a 10/10 looks like]
PRIMARY: [criterion name — omit if equally weighted]
EVALUATOR: [command to run — omit for judge-only]
BACKGROUND: [constraints and resources — omit if not provided]
OUTPUT_CONTRACT: [valid output format description — omit for text/creative]
VALIDATION_COMMAND: [quick check command — omit if no cheap validation exists]
SEARCH_SPACE: [what's in scope to explore — omit if unconstrained]
JUDGE_MODE: [single | board — auto-select, see below]
ITERATIONS: [N]
MODE: [seedless | from-file | from-paste | from-workspace]
OUTPUT_DIR: [path, default: docs/simmer]

デフォルトの反復回数は 3 です。ユーザーが指定した場合（「これをじっくり検討して、10 ラウンド」など）は上書きしてください。反復回数について尋ねないでください。デフォルトは 3 です。

審査モードの自動選択

問題の複雑さに基づいて JUDGE_MODE を選択します。ユーザーに尋ねず、成果物と評価基準から推測してください。

条件	JUDGE_MODE
テキスト／クリエイティブで、評価基準が 2 件以下、かつ短い成果物（メール、ツイート、キャッチフレーズ、単一の段落）	single
テキスト／クリエイティブで、評価基準が 3 件以上、または長い／複雑な成果物	board
コード／テスト可能なもの（すべて）	board
パイプライン／エンジニアリング（すべて）	board

ユーザーによる上書き： ユーザーが「単一の審査員で」と指定した場合は single を使用します。「審査員ボードで」または「パネルで」と指定した場合は board を使用します。ユーザーの意図を優先します。ただし、ミスマッチがないか確認してください。

複雑さのミスマッチに関する確認： ユーザーが単一の審査員を指定しているものの、成果物が複雑な場合（ワークスペース、評価器がある、評価基準が 3 件、コード／パイプラインなど）は、1 回だけ確認してください。

「これは［ワークスペース／パイプライン／複雑］な成果物で、［N 件の評価基準／評価器／複数のファイル］があります。審査員ボードを使うほうが、より的確に診断できます。ボードを使いますか、それとも単一の審査員にしますか？」

質問は 1 回だけです。ユーザーが単一の審査員を選んだ場合はそれに従い、先に進んでください。

OUTPUT_DIR のデフォルトは docs/simmer です。ユーザーが別の場所を指定した場合、またはテスト／スクラッチ環境で実行している場合は上書きしてください。

この概要をオーケストレーターに返してください。生成や審査には進まないでください。それらはオーケストレーターの役割です。

フローの例

テキスト／クリエイティブ（最小限のやり取り）

User: "Simmer a DND adventure hook for a one-shot session.
The party is level 5, exploring a haunted lighthouse."

Agent: [no inspection needed — seedless creative writing]

Agent: "This is a creative writing piece — I'll use judge-only evaluation.

For criteria I'd suggest:
- Narrative tension: scenes have stakes, time pressure, and consequences
- Player agency: multiple meaningful decision points, not just a railroad
- Specificity: concrete details (names, descriptions, sensory hooks) not generic fantasy

3 iterations, seedless. Sound right?"

User: "yes"

→ Emit brief, hand to orchestrator

パイプライン／エンジニアリング（詳細な検査）

User: "Simmer this pipeline at /tmp/pipeline —
I want the best model/prompt/topology for extracting entities."

Agent: [reads directory: config.json, run_pipeline.py, prompt.md,
        evaluate.sh, validate.sh, strategies/]
       [reads config.json: model=qwen3.5:4b, strategy=single-call]
       [reads evaluate.sh: measures coverage, precision, tokens per video]
       [reads validate.sh: runs 1 video, checks JSON format]
       [reads prompt.md: extraction prompt with JSON schema]
       [reads run_pipeline.py: supports pluggable strategies from strategies/ dir]

Agent: "This is a pipeline optimization problem. Here's what I found:

**Evaluator:** ./evaluate.sh — runs all 3 test videos, measures coverage
against ground truth, precision, and token count per model.
**Output contract:** JSON object with 'entities' array, each element has
'name' (string) and 'type' (string). Inferred from pipeline output format
and evaluator expectations.
**Validation:** ./validate.sh — runs 1 video, checks output is valid JSON
with correct schema. Takes ~1 min vs 5-30 min for full eval.
**Search space:**
  - Models: currently qwen3.5:4b in config.json (what else is available?)
  - Prompts: prompt.md (unlimited changes)
  - Topology: single-call currently, but run_pipeline.py supports pluggable
    strategies from strategies/ dir — multi-call is explorable

For criteria:
- Coverage: extracts maximum entities from ground truth (primary?)
- Efficiency: lowest token count while maintaining coverage
- Noise: minimal false positives

What models do you have available? And is coverage the primary goal?"

User: "qwen3.5 4b/9b/27b on Ollama. Yes, coverage is primary. 5 iterations."

→ Emit brief with all inferred + confirmed values

コード／テスト可能なもの（簡易検査）

User: "Simmer this extraction prompt at local_extract_test.py as PROMPT_V4_FULL"

Agent: [reads local_extract_test.py — finds prompt, test harness,
        evaluator command pattern]

Agent: "This is a prompt optimization with a test harness. I see the evaluator
runs via: OLLAMA_MODEL=qwen3.5:27b python3 local_extract_test.py v4_full

Output should be JSON with 'entities' array (name + type from the taxonomy).

For criteria:
- Coverage: extracts every entity from ground truth
- Noise: zero false positives
- Conceptual depth: captures painting theory, not just concrete items

Which matters most?"

User: "Coverage is primary. 3 iterations."

→ Emit brief

よくある間違い

読めばわかる内容をユーザーに説明させる

• 問題：ワークスペース内にあるファイルの説明をユーザーに求めてしまう
• 対策：まずファイルを読みます。推測できないことだけを尋ねてください。

評価ではなくフォームを提示する

• 問題：evaluate.sh に期待される形式が明記されているのに、「有効な出力とはどのようなものですか？」と尋ねてしまう
• 対策：評価スクリプトを読み、仕様を推測して提示してください。

質問を立て続けにしすぎる

• 問題：作業に着手する前に、6～8 回もやり取りしてしまう
• 対策：評価内容を一度にまとめて提示します。ユーザーが確認または調整します。

評価器／検証スクリプトを読まない

• 問題：スクリプトの存在は把握していても、何を測定するのか理解するために読んでいない
• 対策：スクリプトを読み、指標、形式、期待値を抽出してください。

テキスト／クリエイティブで過剰に調査する

• 問題：クリエイティブな文章に、ワークスペースの検査、仕様、検証は不要
• 対策：テキスト／クリエイティブの進め方は軽量に保ち、評価基準を提案して確認したら進めてください。

評価基準を 3 件より多く提案する

• 問題：審査のシグナルが薄まり、生成側が修正しようとする点が多くなりすぎる
• 対策：最大 3 件に絞り、推測した評価基準がそれより多い場合は、ユーザーに優先順位を尋ねてください。

10 点満点の基準を確認しない

• 問題：評価基準が曖昧で、審査員が採点の基準を持てない
• 対策：可能な場合は評価器の指標から 10 点満点の状態を推測してください。推測できない場合は尋ねてください。

生成や審査を始めてしまう

• 問題：セットアップの役割は概要の作成だけ
• 対策：概要をオーケストレーターに返し、そこで止めてください。

評価器の出力形式を強制する

• 問題：ユーザーが既存のスクリプトを仕様に合わせて変更しなければならなくなる
• 対策：評価器の出力形式に要件を設けないでください。生成された内容は審査員が解釈します。

軽微な調整の後に提案し直す

• 問題：ユーザーが「主要項目を X に変えて」と言っただけなのに、エージェントが評価内容をすべて提示し直してしまう
• 対策：調整を反映して概要を出力してください。ユーザーから見直しを求められた場合にのみ、提案し直してください。