create-skill-autoresearch

Autoresearch Factory によるスキルの作成

ゴールドスタンダードに基づく自動調査、マルチエージェント検証、構造化された合意形成を通じて、本番品質のエージェントスキルを生み出すファクトリーです。

このファクトリーは、5つのフェーズを通じて4つのエージェント役割を調整します。

フェーズ	内容	エージェントの役割
1. インタビュー	目的、ゴールドスタンダード、スコープを明らかにします	ORCHESTRATOR
2. 調査	ドメイン資料を調査し、資料集を作成して評価基準を提案します	RESEARCHER（N 並列）
3. ドラフト	構造を設計し、SKILL.md を生成してベースラインを測定します	BUILDER
4. 自動調査	ゴールドスタンダードに照らしてスキルを反復改善します（LLM-as-judge、または手順型スキルの客観的な実世界指標 — 3.4 を参照）	BUILDER + autoresearch スキル
5. 検証	事前検証、パネル評価、合意形成を行い、公開または反復改善します	PANEL（3つのサブエージェント）

重要な制約：BUILDER と PANEL はコンテキストを共有しません。パネルに渡されるのはスキルの出力、ゴールドスタンダード、評価基準のみです。構築プロセスによるバイアスは与えられません。

create-skill との関係

このファクトリーは、公式の単一パス型スキル作成ツール（Anthropic の Skills ベストプラクティスと skill-creator、Cursor の create-skill）を置き換えるのではなく、拡張します。単発の生成では実現できない、調査資料集、ゴールドスタンダードによるベンチマーク、自律的な改善ループ、独立したマルチエージェント検証を追加します。このファクトリーで作成されるスキルは、同じ公式規約に準拠します。references/skill-authoring-best-practices.md を参照してください。

連携スキル

このファクトリーは実行時に、同じ階層の以下のスキルを調整します。autoresearch（フェーズ 4 の改善ループ）、premortem（フェーズ 5 のリスク確認）、handoff（セッションをまたぐ継続性）。フェーズ 5 のパネル／合意形成の設計には llm-council が活用されています。このハーネスでは、これらのスキルは .agents/skills/ にベンダーとして含まれています。このスキルを単独でインストールする場合は、これらも一緒にインストールしてください。このファクトリーの作成レイヤー（references/skill-craft-principles.md）は、writing-great-skills（mattpocock/skills、MIT）から要点をまとめたもので、ハーネスでは .agents/skills/ にベンダーとして含まれています。インストールされている場合、フェーズ 5 では tribunal に処理を委任します（5.2 を参照）。

---

フェーズ 1：インタビュー

構造化された質問を通じて、ユーザーが必要としていることを明らかにします。決めつけず、質問してください。一度に1つのトピックについて質問し、回答を記録します。質問の正確な文言と追加質問は、references/pipeline-phases.md に記載されています。

1.1 - 1.5 明らかにする内容

トピック	質問する内容	記録する内容
目的とドメイン	解決する問題、ドメイン、使用するエージェント、「成功」の定義	SKILL_PURPOSE、DOMAIN、TARGET_USER、SUCCESS_CRITERIA
ゴールドスタンダード	「良いもの」の例 — 入出力のペア、参照成果物、過去に解決した問題、既存の品質レポート。それらの場所、形式、数	GOLD_STANDARD_SOURCE、GOLD_STANDARD_FORMAT、GOLD_STANDARD_COUNT
調査資料	ドキュメント、既存コード、文字起こし、設計ドキュメント、参照実装、仕様、スタイルガイド	STUDY_MATERIALS
スコープと制約	従うべき規約、連携するスキル、避けるべきアンチパターン、目標行数（デフォルトは < 500）、呼び出しモード — モデル呼び出し型（恒久的なコンテキスト読み込みが発生）またはユーザー呼び出し型（disable-model-invocation: true）	CONSTRAINTS、INTEGRATION_SKILLS、ANTI_PATTERNS、INVOCATION_MODE
既存のスキル	このドメインに既存のスキルがあるかどうか。ある場合は、調査資料であると同時にベースラインでもあります。調査し、評価基準に照らして測定し、最初から作り直すのではなく改善してください	EXISTING_SKILL を記録し、モードを greenfield ではなく upgrade に設定します

ゴールドスタンダードは最低3つ必要です。それより少ない場合はリスクとなるため、ユーザーに警告し、合成例を作成するか、追加の参照資料を探す代替案を提示してください。

1.6 ワークスペースを確認して作成する

すべてのパラメーターを表にまとめ、ユーザーに確認を求めます。

確認後、3つの管理領域を持つビルドワークスペースを builds/<skill-name>/ に作成します。

• input/ -- ユーザーがゴールドスタンダードと学習資料を、どのような構成でも配置できる場所
• work/ -- ファクトリーが生成するすべてのもの：manifest.yaml、research/、evaluation/、experiments/、handoffs/
• output/<skill-name>/ -- 完成したスキル（SKILL.md + references/）を、公開準備済みの状態で専用の名前付きディレクトリに配置する場所

ユーザーにマニフェストを手作業で作成するよう求めてはいけません。input/ 内の内容をすべてスキャンし、各項目をゴールドスタンダード（模範的な入出力ペアまたは参照アーティファクト）か学習資料に分類し、train/validation/test タグを付けたインデックスを work/manifest.yaml に作成します。導出したマニフェストをユーザーに提示し、確認または修正してもらいます。受け入れ形式とマニフェストのスキーマについては、references/pipeline-phases.md を参照してください。

---

フェーズ 2：調査

スキルのコードを書く前に、ドメインを徹底的に調査します。

2.1 調査サブエージェントを起動する

学習資料を関連性に基づいてクラスター化し、クラスターごとに explore サブエージェントを1つ起動します。クラスター化のヒューリスティック：

• ソースの種類別：既存のスキルを1つのクラスターに、ゴールドスタンダードの出力を別のクラスターに、計画ドキュメントをさらに別のクラスターにまとめます
• サブトピック別：資料が異なる分野（例：バックエンドとフロントエンド）を扱う場合は、分野ごとに分割します
• 最大5～7クラスター：7を超えると、深さが比例して増すことなく統合作業の負荷が増します
• 最低2クラスター：クラスターが1つだけでは、並列化のメリットがありません

各サブエージェントは次のことを行います。

1. 割り当てられた資料を深く読み込みます
2. 調査結果を work/research/ に調査ノートとしてまとめます
3. スキルに関連するパターン、慣例、品質の指標を特定します

命名規則：work/research/01-<topic>.md、work/research/02-<topic>.md など。

2.2 調査結果を統合する

すべての調査担当者の作業が完了したら、調査結果を work/research/00-synthesis.md に統合します。

• 分野横断的なパターン
• スキルが従うべき重要な慣例
• 良い出力と悪い出力を区別する品質の指標
• ルーブリックの評価項目候補

2.3 ルーブリックを提案する

調査結果の統合に基づいて、work/evaluation/rubric.yaml の草案を作成します。

name: <skill-name>-rubric
dimensions:
  - name: <dimension>
    weight: <0.0-1.0>
    scale: "1-10"
    criteria: "<what this dimension measures>"
  # ... 5-10 dimensions
target_score: 0.85
max_iterations: 20
plateau_window: 5

次の普遍的な評価項目を必ず含めます（ドメインに応じて重みを調整します）。

• correctness：指示が技術的に正確で、実行可能である
• completeness：必要なセクションとエッジケースをすべて網羅している
• clarity：予備知識のないエージェントでも、曖昧さなく従える
• consistency：既存のコードベースの慣例に沿っている
• predictability：実行のたびに同じプロセスを導き、完了条件が検証可能かつ網羅的で、曖昧な判定基準や何もしない行がない（references/skill-craft-principles.md を参照）

調査結果の統合から、ドメイン固有の評価項目を3～5個追加します（合計5～10項目）。

ルーブリックをユーザーに提示してレビューしてもらいます。確認されるまで反復します。

テンプレートについては、references/rubric-templates.md を参照してください。

---

フェーズ 3：草案の作成

書く前に設計し、評価する前に書きます。

3.1 設計ドキュメント

work/experiments/DESIGN.md を作成し、次の内容を記載します。

• スキル名と説明（create-skill の慣例に従う）
• 構造上の決定：セクション数、参照ファイルの分割、段階的開示の計画
• 呼び出しモード、情報階層の計画（手順と参照の使い分け、インラインと開示の使い分け、 分岐による許可）、および先頭に置く語句の候補。references/skill-craft-principles.md を参照してください
• 他のスキルとの統合ポイント
• 主要な用語と文体に関する決定

3.2 設計を厳しく検討する

スキルのコードを書く前に、設計に対して批判的な検討を行います。

• 実際の運用で、このスキルを失敗させる要因は何ですか？
• 構造上の決定には根拠がありますか。それとも単なる仮定ですか？
• 設計はゴールドスタンダードが示す内容に合っていますか？
• もっと簡単な代替案はありますか？

懸念事項をユーザーに提示します。設計が厳しい検討に耐えるまで反復します。

3.3 SKILL.md のドラフトを生成する

設計と公式のスキル作成ルール（references/skill-authoring-best-practices.md を参照）に従い、執筆前に次の事前チェックリストを確認してください。これらは好みではなく、必ず守るべき制約です。

• name：64 文字以内、小文字・数字・ハイフンのみ使用し、予約語の anthropic／claude は使用しないこと。内容を説明するケバブケースとし、同梱されるセットの命名規則に合わせます
• description：1024 文字以内、三人称で記述し、何をするかと、いつ使用するかの両方を明記します
• 本文は 500 行未満とし、段階的開示を取り入れます（要点は SKILL.md に、詳細は references/ に記載）
• ファイル参照は1 階層までに限定します。100 行を超える参照ファイルには目次を付けます
• 抽象的な指示より具体例を優先し、用語を統一して、パスにはスラッシュを使用します
• 説明文の作成：先頭に重要な語を置き、分岐ごとにトリガーを 1 つだけ設定し、類義語をむやみに加えないでください。 ユーザーが呼び出すスキルには、人が読むための説明を 1 行付けます（references/skill-craft-principles.md を参照）

ドラフトを output/<skill-name>/SKILL.md に書き込みます（参照ファイルは output/<skill-name>/references/ に配置します）。

3.4 評価スクリプトを作成する

work/evaluation/evaluate.sh を作成し、次の処理を行います。

1. ゴールドスタンダードのテストケースのパスを引数として受け取ります
2. テストケースから入力を抽出します
3. 入力に対してスキルを実行します。スキルは Markdown の指示（実行可能ファイルではない）なので、SKILL.md をシステムプロンプト、テストケースの入力をユーザーメッセージとして LLM を呼び出します。OpenAI 互換 API に curl でリクエストするか、言語固有の SDK を使用します。LLM の出力を取得します。
4. LLM-as-judge を使用して、出力をゴールドスタンダードのリファレンスと比較します
5. METRIC <dimension>=<score> の行を標準出力に出力します
6. 主な指標として METRIC overall_score=<weighted_average> を出力します

完全な実装例については、agent-skills-harness リポジトリの self-test/evaluation/evaluate.sh を参照してください。

overall_score はフェーズ 4 の指針であり、リリースの根拠ではありません。 ゴールドスタンダードに対する出力の絶対的な品質を測定しますが、ベースモデルとの比較は含まれていないため、「このスキルは役に立つか」という問いには答えられません。この問いに答えるには、同一モデルでの向上度ベンチマーク、つまりスキルありとスキルなしで同じモデルに同一タスクを実行させるベンチマークが必要です。リリース前に構築し、正直なマイナス結果も報告してください。overall_score から有効性を判断するのは、機能するスキルを役に立たないと結論づける最も一般的な原因です。標準、評価群、サンプル数、リトライ同等性のルールについては、references/benchmark-standard.md を参照してください。

LLM ジャッジでは、次の点に従ってください。

• 次元ごとのスコアリングには、構造化 JSON 出力を使用します
• 各次元を個別に採点します（ハロー効果を防ぎます）
• 極端なスコアには根拠（逐語的な引用）を必須とします
• 可能であれば、作成に使用したモデルとは異なるモデルファミリーを使用します

決定論的評価と LLM ジャッジによる評価：すべての次元で LLM ジャッジが必要なわけではありません。可能な場合は、決定論的なチェックを優先してください。

• 行数、フロントマターの検証、リンクの整合性 → シェル／grep チェック
• パターンの網羅性（出力で X に言及しているか） → 正規表現によるマッチング
• 構造への準拠 → プログラムによる検証

主観的な判断（明確さ、品質の一致度、キュレーション）が必要な次元に限り、LLM-as-judge を使用してください。evaluate.sh では両方を組み合わせます。決定論的なチェックは METRIC 行を直接出力し、LLM ジャッジが残りを処理します。LLM API が利用できない場合は、決定論的な評価のみを行うように切り替え、警告を記録します。

手続き型／エージェント型のスキル（該当する場合はこちらを優先）：一度の実行で成果物を生成するのではなく、実際の成果物に対して複数段階のタスクをエージェントに実行させるスキルもあります（フレームワークのバージョン移行、モジュールのリファクタリング、インフラのひな形作成など）。こうしたスキルには、上記の単一呼び出しのハーネスは適していません。ジャッジの代わりに成果物自体の正解データを使用し、実際の成果物に対する実行と、客観的な実世界の指標によって評価してください。ベースラインの取得、リセット後に新しいエージェントを実行するオーケストレーション、そして実行ごとに新しいエージェントを使用する理由を含む手法全体については、references/benchmark-standard.md を参照してください。

複数ジャッジによる評価（予算に余裕がある場合に推奨）：

• 同じ出力を 2〜3 種類の異なる LLM モデルでジャッジします
• より堅牢なシグナルを得るため、次元ごとのスコアを平均します
• ジャッジごとのばらつきを追跡します。ある次元のばらつきが大きい場合、基準が曖昧である可能性があります
• work/evaluation/judges.yaml でジャッジを設定します。

  judges:
    - model: "<model-1>"
      weight: 1.0
    - model: "<model-2>"
      weight: 1.0
  aggregation: "mean"
  

必要に応じて、正確性を判定するゲートとして work/evaluation/evaluate-checks.sh を作成します。

3.5 ベースラインを測定する

初期ドラフトを使って、テストケースに対して evaluate.sh を実行します。 ベースラインのスコアを記録します。これが実験 0 です。

ユーザーには次のように報告します。

ベースラインを確立しました：overall_score = [value] 次元別内訳：[per-dimension breakdown]

---

フェーズ 4：自動リサーチ

autoresearch スキルを呼び出し、評価ルーブリックに照らしてスキルのドラフトを反復的に改善します。

4.1 自動調査の設定

自動調査スキルに次のパラメーターを指定します。すべてのパスはビルドワークスペースのルート（builds/<skill-name>/）からの相対パスです。このディレクトリを自動調査の作業ディレクトリとして使用します。自動調査セッションのファイル（.md、.jsonl、.tsv、run.log）は、セッション中にワークスペースのルートに作成され、セッションの終了時または引き継ぎ時にwork/experiments/へアーカイブされます。

• 目標：overall_score（ゴールドスタンダードに基づくLLM-as-judge、または手順スキルの客観的な実環境メトリクス。3.4を参照）で測定される<skill-name>の品質を向上させます。
• メトリクスコマンド：./work/evaluation/evaluate.sh（ワークスペースのルートからの相対パス）
• 主要メトリクス：overall_score
• 方向性：higher_is_better
• 対象ファイル：output/<skill-name>/SKILL.md、output/<skill-name>/references/*
• 対象外ファイル：input/、work/
• 制約：公式のスキル作成ルールに従う必要があります（500行未満、フロントマター形式。3.3を参照）。
• 予算：ルーブリック設定のmax_iterations（デフォルトは20）
• チェック：work/evaluation/evaluate-checks.shが存在する場合は、ワークスペースのルートにautoresearch.checks.shを作成して、このスクリプトを呼び出します（自動調査スキルはこのファイル名を想定しています）。

4.2 データの分割

ゴールドスタンダードが10件以上の場合：

• 訓練用70%：各自動調査実験で使用します。
• 検証用20%：過学習を適応的に検出するために確認します（下記参照）。
• テスト用10%：フェーズ5の検証まで完全に保留します。

ゴールドスタンダードが3～9件の場合：

• 1件除外ローテーション：各実験では1件を除くすべてを評価し、除外する項目をローテーションします。

分割内容をwork/evaluation/data-split.yamlに記録します。

大規模なデータセット（ゴールドスタンダードが100件以上）でのコストへの配慮：LLM-as-judgeの呼び出しには実費が発生します。訓練ケースが70件で、呼び出し1回あたり約0.50ドルの場合、1回の実験につき約35ドルかかります。実験ごとに訓練ケースからランダムにサンプリングして評価する（例：10～15件を選び、サンプルをローテーションする）ことでコストを抑えます。保持する実験の検証時やフェーズの節目に限り、訓練セット全体で実行します。

過学習の検出：検証セットに対してevaluate.shを適宜実行します。具体的には、実験を保持するたびに、停滞したときに（上限は本物か、訓練データに固有のものかを確認するため）、および訓練スコアが0.05を超えて上昇したときに実行します。訓練スコアが改善する一方で検証スコアが0.05を超えて低下した場合は、最近の変更が過学習している可能性をユーザーに警告し、それらを一般化する、検証で安定していた最後のコミットに戻す、または狭くなりすぎたルーブリック基準を広げる方法を提示します。検証チェックはautoresearch.jsonlに"type": "validation_check"として記録します。

1件除外方式での過学習検出（ゴールドスタンダードが10件未満の場合）：固定の検証セットがないため、ケースごとの分散を追跡します。平均が改善する一方で分散が広がる場合、一部のケースに特化することで他のケースの性能を犠牲にしていることを示します。他のケースが改善する中で、いずれか1件のスコアが1.0ポイントを超えて低下した場合は警告します。

4.3 オートリサーチを実行する

オートリサーチスキルが次のループを処理します。

• THINK-EDIT-COMMIT-RUN-MEASURE-DECIDE-LOG サイクル（コミット優先の Git モデル）
• 測定のための METRIC プロトコル
• 構造化メモリのための ASI フィールド
• 停滞の検出
• 結果を autoresearch.jsonl と results.tsv に記録

ファクトリーはオートリサーチのアイデアバックログ（autoresearch.ideas.md）に次の内容を追加します。

• リサーチを統合して得られたアイデア
• ルーブリックに基づく、次元ごとの改善戦略
• ゴールドスタンダードで観察された、まだスキルに反映されていないパターン
• references/skill-craft-principles.md に基づく仕上げ作業：先頭語の探索、無操作・重複・堆積の削除、開示内容の再調整

ループを終了するかどうかはファクトリーが判断し、ループ自身が決めるものではありません。 オートリサーチスキルは停滞を参考情報として扱い、予算が残っている間は続行するため、タスクでは到達できない target_score を設定すると、予算を使い切ったうえで「終了条件を満たしていません」と報告し続けます。これを上書きしてください。

• 信頼度を考慮した停滞は終了条件です。 停滞が評価者のばらつき（1～10 のスケールで約 0.2～0.3。これを下回ると改善を測定できません）の範囲内であれば、停止し、現時点での最良の結果をフェーズ 5 に引き継ぎます。
• 目標未達は失敗ではなく判定です。フェーズ 5.4 で評価し、target_score - 0.10 以上なら「注意事項付きでリリース」と判定します。state.yaml の baseline_lock も同様に尊重し、実際の目標をアイデアバックログに記録します。
• 到達不能な数値を目指して、繰り返し再実行を求めないでください。上限を報告し、制約となっている要因（目標が高すぎる、または改善幅が評価者のばらつきを下回る）を明示して、先に進みます。

4.4 監視と引き継ぎ

オートリサーチセッションがコンテキスト上限または実験予算を超えた場合：

1. handoff スキルを呼び出して、work/handoffs/HANDOFF-<session>.md を生成します
2. 構造化された再開状態（フェーズ、セッションカウンター、最高スコアとコミット、実施済みの実験、残りの予算、検証スコア、主な懸念事項、ブロックされている次元、baseline_lock）を work/handoffs/state.yaml に書き込みます。完全なスキーマは references/pipeline-phases.md を参照してください
3. 次のセッションでは state.yaml を読み、正しいフェーズから再開します

4.5 再開プロトコル

work/handoffs/state.yaml が存在する場合：現在のフェーズを確認するために読み込み、コンテキストを把握するために最新の work/handoffs/HANDOFF-*.md を読み、記録されたフェーズから再開します（interview ではパラメーターを再確認し、research では資料が不完全なら統合し、draft ではドラフトが存在する場合にベースラインを測定し、autoresearch では ASI の履歴を確認するために autoresearch.jsonl を読み、残りの予算で続行し、verify では直前の判定が ITERATE だった場合にパネルを再実行します）。その後、セッション番号を増やします。フェーズごとの詳細は references/pipeline-phases.md を参照してください。

---

フェーズ 5：検証

作成に参加していないエージェントによる独立した検証です。ビルダーとパネルの間にコンテキストの壁を設けることが重要です。これにより、作成プロセスによる偏りを防ぎます。

5.1 事前検死

premortem スキルをスキル成果物に対して実行します。特定されたリスクを追加のテストシナリオとしてパネル評価に取り込み、5 つの仕上げ上の失敗モード（早すぎる完了、重複、堆積、肥大化、無操作）を必須の検証項目に含めます。

5.2 パネル評価

独立した検証サブエージェントを3つ、並列に起動します。それぞれが受け取るのは以下の情報のみです。

• スキルの SKILL.md と参照資料
• ゴールドスタンダード
• ルーブリック
• プレモーテムのリスク

以下の情報は受け取りません。調査メモ、実験ログ、ビルダーのコンテキスト、ASI。

パネルの役割：

役割	注目点	バイアス
検証者A（品質）	正確性、完全性、明瞭さ、仕様への準拠	中立
検証者B（有用性）	実環境での使いやすさ、エッジケース、開発者エクスペリエンス	中立
悪魔の代弁者	失敗モード（5つのクラフト失敗モードを含む）、隠れた前提、制約の不足	明示的に敵対的

各パネルメンバーは、ルーブリックの各評価軸を独立して採点し、以下を提示します。

• スコア（ルーブリックの尺度に従う）
• 確信度（0.0～1.0）
• 根拠（成果物からの逐語引用）

可能な場合は、パネルに異なるモデルファミリーを使用してください（例：ビルダーがあるモデルを使った場合、検証者には別のモデルを使います）。

役割ごとに1つのエージェントを使ってください。これは形式ではなく、この仕組みそのものです。 1つのエージェントが1つのコンテキストでパネルをシミュレートすると、単独での下限スコア（実測値0.62、個別エージェントでは0.75）になります。コンテキストを共有すると、見落としも共有されるためです。オーケストレーターはエージェントを割り当てて裁定しますが、採点はしません。並列エージェントを使わない場合は、各役割をそれぞれ独立した新しいコンテキストのセッションで実行し、結果に「単一コンテキスト（独立性なし）」と明記してください。合意形成の計算を行う前に、判定を左右する引用をすべて成果物と照合して grep してください。引用が逐語で見つからない場合、その引用に基づく指摘は破棄します。

パネル用プロンプトのテンプレートについては、references/pipeline-phases.md を参照してください。

tribunal スキルが利用可能な場合は、Phase 5 をそこに委任してください。このパターンは一般化され、別途ベンチマークも行われています。成果物としてビルダーの出力を、基準として Phase 3 の草稿作成前に固定した Phase-2.3 のルーブリックを渡します。オーケストレーターには、スキルを作成したエージェントを使わないでください。それ以外の場合は、インラインパネルを実行してください。単独でインストールできるものが、別のスキルに依存してはいけません。

5.3 合意形成プロトコル

3つの採点結果をすべて集めた後、次の手順を実行します。

1. 一致の確認：すべての評価軸で全スコアの差が1点以内なら、加重平均を算出して完了します。
2. 統合ラウンド（いずれかの評価軸でスコアの幅が2以上、または悪魔の代弁者がある評価軸を1点と評価した場合）：各メンバーが意見の分かれた評価軸について論拠を記述します（最大500語）。論拠は匿名化して同時に共有します。メンバーは、書面で根拠を示して評価を修正できます。修正しない場合は、最も有力な反対意見に反論しなければ、そのスコアを維持できません。
3. 解決：差が1点以内に収束した場合は、加重平均を算出します。2対1の多数決になった場合は、多数派の評価を採用し、少数派の意見を work/experiments/craft-decisions.md に少数意見報告として記録します。膠着状態になった場合は、ユーザーにエスカレーションします。
4. 悪魔の代弁者によるエスカレーション：悪魔の代弁者は、多数派が退けた重大な懸念について ESCALATE: <reason> と記述できます。これにより、その懸念は平均化で消されず、ユーザーに提示されます。

完全なプロトコル、アンチパターン、研究上の根拠については、references/consensus-protocol.md を参照してください。

5.4 出荷または反復

最終スコア	アクション
>= target_score AND 寸法にブロックなし	出荷 -- スキルを最終配置先にコピー
>= target_score - 0.10	注意事項付きで出荷 -- 懸念事項を記録して進める
< target_score - 0.10	反復 -- パネルのフィードバックを autoresearch に渡す
過半数の評価者でいずれかの寸法が 3/10 未満	ブロック -- まずブロック要因となる懸念に対処する

反復する場合：

1. 各パネルメンバーから主な懸念事項を抽出する
2. Devil's Advocate から失敗シナリオを抽出する
3. 具体的な改善仮説を autoresearch.ideas.md に追加する
4. パネルのスコアと根拠を work/experiments/craft-decisions.md に記録する
5. 構造化されたフィードバックを添えてフェーズ 4 に戻る

出荷時には、ビルドルートに BENCHMARK.md（パネルの最終スコアと判定）を作成し、references/publishing.md に従ってください。出荷はファイルのコピーではなく登録チェックリストです。レジストリエントリーと一致しないバージョンを使うと、誤ったものがインストールされます。スキルにふさわしい価値があることを、ベンチマークの向上で証明してください：references/benchmark-standard.md。

---

出力構造

各ビルドは、次の 3 つの領域で構成される自己完結型フォルダー builds/<skill-name>/ に格納されます。

builds/<skill-name>/
  input/                  # HUMAN: gold standards + study materials (any structure)
  work/                   # FACTORY: process artifacts (not shipped)
    manifest.yaml         #   derived gold-standard index    <- yours to correct
    research/             #   study notes and dossier
    evaluation/           #   rubric.yaml (exit criteria), evaluate.sh, judges.yaml, data-split.yaml
    experiments/          #   results.tsv, autoresearch.jsonl, run.log, DESIGN.md, craft-decisions.md
    handoffs/             #   cross-session context (state.yaml, HANDOFF-*.md)
  output/                 # FACTORY: the finished, publish-ready skill
    <skill-name>/         #   the skill in its own named dir
      SKILL.md
      README.md           #   optional, ships on install: what it does, method, results
      references/         #   if needed
      scripts/            #   if needed (NOT evaluation scripts)
      assets/             #   if needed
  BENCHMARK.md            # FACTORY: final panel scores + verdict (Phase 5)

work/ は生成されますが、フェーズの境界で人が修正する 4 つのファイルがあります：manifest.yaml、evaluation/rubric.yaml（終了条件）、evaluation/judges.yaml、evaluation/data-split.yaml。これらのファイルには認証情報を絶対に記述しないでください。work/ は実際のプロジェクトリポジトリ内でコミットされることがよくあります。

出荷されるのは output/<skill-name>/ のみです。向上ベンチマークはスキルディレクトリの外部にある benchmarks/<skill-name>/ に配置します。公開方法：references/publishing.md。

---

引き継ぎルール

次のいずれかが発生した場合は、引き継ぎを作成します：

• コンテキストウィンドウが上限に近づいている（ターン数が多い）
• 現在のセッションの実験予算を使い切った
• フェーズが切り替わる（調査 → ドラフト、ドラフト → autoresearch など）
• ユーザーから明示的に依頼があった

引き継ぎごとに、次のものを作成します：

1. work/handoffs/state.yaml -- 自動再開用の構造化された状態
2. work/handoffs/HANDOFF-<label>.md -- 人が読みやすい詳細なコンテキスト

再開するには、state.yaml を読み、現在のフェーズを特定し、関連するコンテキストを読み込んで続行します。