auto-research

自動リサーチ

次の手順で、対象となるプロンプト成果物（SKILL.md、CLAUDE.md、サブエージェント定義、スラッシュコマンド、または一般的なプロンプト用 Markdown）を改善します。

1. 検出 — 成果物の種類と、適用されるルールを特定します
2. リサーチ — 信頼できる最新のベストプラクティスを並行して調査します。すべての主張に出典を付けます
3. 書き換えを提案 — 変更ごとの根拠と出典 URL を示します
4. 書き換えを検証 — テスト可能な成果物では、git のコミット／リセットを記録しながら、自律的に実行する Karpathy 方式の二値アサーション評価ループを使用します。テスト不可能な成果物では、決定論的な形式検証を行います
5. 最後に一度だけ確認 — 変更前後のスコア表、差分、出典を提示します。ユーザーが明示的に「はい」と答えた場合に限り、最終的な書き込みを行います

手順 1〜4 の間は自律的に実行します。手順 5 でのみ停止します。

---

フェーズ 0 — 入力を読み込み、ワークスペースを準備する

ユーザーは対象の成果物を指定します（パス、または「私のコピーライティングスキル」のような表現。該当するものを特定します）。特定ルールは次のとおりです。

• パスが指定されている場合は、そのパスを使用します。
• スキル名が指定されている場合は、.claude/skills/<name>/SKILL.md（プロジェクト）を検索し、次に ~/.claude/skills/<name>/SKILL.md（ユーザー）を検索します。
• 「この CLAUDE.md」などと指定されている場合は、現在の作業ディレクトリツリー内で最も具体的なもの（プロジェクト > ユーザー）を使用します。

次に、以下を実行します。

1. 対象の成果物を全体にわたって読み込みます。
2. references/artifact-types.md に従って分類します：SKILL.md / CLAUDE.md / サブエージェント / スラッシュコマンド / 一般的なプロンプト。
3. ワークスペースを準備します — 対象の隣に兄弟ディレクトリ .auto-research/<target-name>/ を作成します。対象の親ディレクトリが git 管理下にない場合は、コミット／リセットの記録がローカルで行えるよう、そこで git init を実行します。（ユーザーのプロジェクトルートに独自の git リポジトリがあり、対象がその中にある場合は既存のリポジトリを使用し、サブリポジトリは初期化しないでください。）
4. ベースラインを記録します — 元の成果物を .auto-research/<target-name>/iteration-0/baseline.md にコピーし、git のリビジョンを記録します（取得できる場合は git rev-parse HEAD、それ以外は「untracked」）。
5. iterations.tsv を作成し、次の列を含めます：iter | hypothesis | score_before | score_after | decision | git_rev | timestamp | notes。

ワークスペース全体の構造については、references/eval-loop.md に記載されています。フェーズ 4 で評価ループを実行する際に、このファイルを読みます。

---

フェーズ 1 — リサーチトピックを抽出する

成果物を読み、リサーチトピックのリストを作成します。これは、回答をもとに成果物をより良く書き換えられる具体的な問いです。各トピックは、（a）2026 年時点で信頼できるウェブ上の回答が見つかる可能性が高く、かつ（b）対象のセクション、主張、慣例に直接適用できる必要があります。

適切なトピックの例：

• 「SKILL.md の description フィールドについて、Anthropic が現在推奨する構成と、文字数制限は何ですか？」
• 「CLAUDE.md の長さと記載内容の選定に関する、2026 年のベストプラクティスは何ですか？」
• 「.claude/agents/*.md で現在サポートされているフロントマターフィールドと、tools の指定方法は何ですか？」
• 「公式の skill-creator スキルでは、SKILL.md 本文と参照ファイルの間で情報を段階的に開示する方法について、何を推奨していますか？」
• 「2026 年には、どの <tool> フロントマターフィールドが <old-tool> に置き換わりましたか？」（対象で非推奨の可能性がある項目を使用している場合に限り、質問します）

アンチパターン：

• 「このスキルは優れていますか？」 — 抽象的すぎて、リサーチできません
• 「autoresearch について Karpathy は何と言っていますか？」 — 対象の書き換えに直接適用できません

成果物の種類ごとのトピックチェックリストと、情報源の権威性の順位については、references/research-strategies.md を読んでください。

このフェーズの出力：research_topics リスト（5〜12 件）を .auto-research/<target-name>/research_topics.md に保存します。

---

フェーズ 2 — 並列リサーチ

各トピックについて、Agent ツールを使用して並列サブエージェント（汎用、モデル：sonnet）を起動します。各サブエージェントは次の作業を行う必要があります。

1. トピックについて、現行年の 2026 年を指定して WebSearch クエリを実行します。
2. references/research-strategies.md の情報源の信頼性ランキングを参照し、最も信頼できる情報源の結果を WebFetch で取得します。
3. 構造化された調査結果ブロックを返します。

### Topic: <topic>
**Verdict:** <1–3 sentence answer>
**Evidence:**
- Quote: "..." — <URL>
- Quote: "..." — <URL>
**Confidence:** high | medium | low
**Implications for rewrite:** <1–2 sentences>

すべてのトピックのエージェントを、1 つのメッセージ内で並列に起動します（1 回の応答で複数の Agent ツール呼び出しを行います）。すべてのエージェントが完了するまで待ちます。「信頼度が低い」と返された場合、または情報源がない場合は、そのトピックを不確実としてマークし、書き換えから除外するか、焦点を絞った調査質問を 1 つ尋ねます。

集約した調査結果を .auto-research/<target-name>/findings.md に保存します。

---

フェーズ 3 — 書き換え案の作成（ドラフト）

調査結果を適用し、書き換えた成果物を .auto-research/<target-name>/iteration-1/proposal.md に作成します。

ルール：

• 実質的な変更はすべて、findings.md 内の少なくとも 1 つの引用元にたどれるようにします。
• 引用付きのベストプラクティスに別段の定めがない限り、プロジェクト固有の内容（ドイツ語の文章、カスタムワークフロー、例など）は保持します。
• references/artifact-types.md の形式制約（行数制限、フロントマターのルールなど）を遵守します。
• 根拠のない新しいセクションを、説明なく追加しないでください。

次に、.auto-research/<target-name>/iteration-1/rationale.md に根拠ブロックを作成します。変更ごとの形式は次のとおりです。

### Change: <one-line summary>
**Old:** <quoted excerpt>
**New:** <quoted excerpt>
**Why:** <1–2 sentences>
**Source:** <URL>

---

フェーズ 4 — 検証／評価ループ

成果物の種類に応じて検証方法を決定します。references/artifact-types.md のルールを参照してください。種類ごとに、自律型 Karpathy 評価ループを実行するか、形式検証のみを行うかが表に記載されています。

4a. 形式検証（必ず実行）

評価ループに入る前に、決定論的なチェックを行います。

• SKILL.md：フロントマターに name と description があること、description が 1024 文字以下であること、本文が 500 行以下であること、参照が 1 階層のみであること。
• CLAUDE.md：全体が 200 行以下であること（200～250 行の場合は失敗ではなく警告）。ネストしたインポートが 1 階層を超えないこと。Windows のバックスラッシュ形式のパスがないこと。
• サブエージェント（.claude/agents/*.md）：フロントマターが有効であること（name、description、任意の tools、model）。description が三人称で、「use when …」の形式になっていること。
• スラッシュコマンド（.claude/commands/*.md）：フロントマターは任意。適切な長さ（200 行未満）であること。目的が明確で、1 つに絞られていること。
• 汎用プロンプト MD：行数と見出し構造のみを妥当性確認します。

形式検証に失敗した場合は、書き換え案を修正し、続行する前に再検証します。不正な形式の案のまま先に進んではいけません。

4b. 自律評価ループ（対象の種類のみ）

references/artifact-types.md に記載されている対象の種類：SKILL.md（常に対象）、測定可能な出力がある汎用プロンプト（ユーザーがテスト入力を提供した場合）。

references/eval-loop.md に記載されたループを実行します。完全な運用マニュアルは参照ファイルにあります。

• 二値のアサーションを含む evals.json の生成方法
• 自律実行の指示ブロック（「よく考え、止まらず、ループを続ける…」）
• 反復ごとに、仮説を立てる → 変更する → N 個のテストプロンプトでスキルを実行する → 採点する → 維持（git commit）または取り消し（git reset）を行う → 記録する
• 反復上限：デフォルトでは 10 回、15 回で強制停止（それを超えると通常は品質が低下します。eval-loop.md を参照）
• 決定論的な採点スクリプトは scripts/score_evals.py です。

ループは自律的に実行します。ループの途中でユーザーに確認するために一時停止しないでください。プッシュ通知は問題ありませんが、質問はしないでください。

4c. 評価をスキップする分岐

成果物の種類が評価スキップ対象（CLAUDE.md、サブエージェント、スラッシュコマンド、テスト入力のない汎用プロンプト）の場合、スコアは「format-validation-only: PASS/FAIL」とします。評価スコアを捏造してはいけません。

---

フェーズ 5 — 最終確認ゲート（唯一の停止ポイント）

スキルが停止してユーザーに確認するのは、ここだけです。正確なレポート形式については、references/confirmation-gate.md をお読みください。

次の項目を含む確認レポートを 1 つ作成します。

1. 成果物 — パス、種類、変更前後の合計行数
2. スコア — eval ループを実行した場合は実行前後の eval 合格率、実行しなかった場合は「format-validation only」
3. イテレーション — iterations.tsv の表
4. ソース — findings.md で引用したすべての URL（重複を除く）
5. 差分 — ベースラインと最終提案の統一差分（非常に大きい場合は約 150 行に切り詰めます。完全な差分は .auto-research/<target-name>/final.diff にあります）

その後、質問を 1 つだけ、正確に尋ねます。「これらの変更を に適用しますか？（yes / no / iterate-with-feedback）」。

• yes → 最終提案で対象ファイルを上書きします。ワークスペースにはイテレーションの履歴がすでに Git に保存されています。最終コミット情報を .auto-research/<target-name>/RESULT.md にコピーします。
• no → 対象ファイルは変更しません。ワークスペースは確認用に残します。
• iterate-with-feedback → ユーザーの自由記述のフィードバックを新たな制約として取り込み、その制約を追加してフェーズ 3 に戻り、イテレーションを 1 回実行してからフェーズ 5 に再度進みます。

無期限にループしないでください。ユーザーが「iterate」と 3 回連続で答え、「yes」と言わない場合は、そのことを明示し、中止するかどうかを尋ねます。

---

ツールとモデルに関するガイダンス

• フェーズ 2（調査）：general-purpose サブエージェントを使用し、モデルは sonnet とします。並列で実行します。
• フェーズ 3（書き換え）：メインエージェント（Opus）が担当します。1 回の逐次実行で行います。総合にあたっては、全体のコンテキストが活用されます。
• フェーズ 4（eval ループ）：メインエージェントがループを進行させます。各テストプロンプトで対象スキルを実行するため、general-purpose の sonnet サブエージェントを起動します（1 回のイテレーション内で、プロンプトごとに並列実行できます）。スコア判定には決定論的な Python を使用します。
• **eval ループでスコアリングスクリプト（scripts/score_evals.py）や evals.json を変更することは、決して許可しないでください。これらは Karpathy の prepare.py に相当する、変更禁止の正解データです。

---

このスキルが意図的に行わないこと

• スキルをゼロから新規作成することはありません。その場合は skill-creator スキルを使用してください。このスキルは既存の成果物を改善するためのものです。
• Anthropic の完全な eval／ベンチマーク／パッケージングのパイプラインは実行しません。skill-creator がすでにこれを実行し、このスキルと組み合わせて使用できます。
• 対象ファイルを通知せずに上書きすることはありません。フェーズ 5 は必須です。
• 調査対象のトピックがすべて「確信度が低い」という結果になった対象を書き換えることはありません。その旨を伝え、十分な根拠がないまま進めるかどうかを尋ねます。