devtu-self-evolve

ToolUniverse 自己進化オーケストレーター

専門の devtu スキルに処理を振り分け、開発ライフサイクル全体を調整します。

サイクル

Discover → Create → Test → Fix → Optimize → Ship → Repeat

各フェーズは専用のスキルに対応しています。

フェーズ	スキル	機能
発見	devtu-auto-discover-apis	ギャップ分析、API のウェブ検索、一括発見
作成	devtu-create-tool	ツールクラス、JSON 設定、テスト例を作成
テスト	(このスキル)	研究者ペルソナのエージェントを起動して問題を発見
修正	devtu-fix-tool	失敗を診断し、修正を実装して検証
最適化	devtu-optimize-skills	スキルのレポート、エビデンス処理、UX を改善
最適化	devtu-optimize-descriptions	ツールの JSON 説明を改善して明確化
ドキュメント	devtu-docs-quality	ドキュメントの正確性を検証
リリース	devtu-github	ブランチ作成、コミット、プッシュ、PR 作成

クイックスタート

必要な作業に応じて、開始地点を選択してください。

• 「テストを実施する」 → テストフェーズに進む
• 「カバレッジを拡大する」 → Skill(skill="devtu-auto-discover-apis") を実行
• 「新しいツールを作成する」 → Skill(skill="devtu-create-tool") を実行
• 「壊れたツールを修正する」 → Skill(skill="devtu-fix-tool") を実行
• 「スキルを改善する」 → Skill(skill="devtu-optimize-skills") を実行
• 「全サイクルを実施する」 → 以下のすべてのフェーズを順番に実行

---

フェーズ 1：発見（任意）

Skill(skill="devtu-auto-discover-apis") を実行して、以下を行います。

1. 現在のツールカテゴリのギャップ分析を実施する
2. カバー率の低い分野のライフサイエンス API を検索する
3. カバー率、信頼性、ドキュメントに基づいて API を評価し、優先順位を付ける

フェーズ 2：ツール作成（任意）

新しい API ごとに Skill(skill="devtu-create-tool") を実行します。

1. API を実装する Python ツールクラスを作成する
2. パラメーター、説明、テスト例を含む JSON 設定を作成する
3. _lazy_registry_static.py と default_config.py に登録する
4. 検証する：python -m tooluniverse.cli test <ToolName>

フェーズ 3：テストフェーズ

これは、このスキルが直接実行する中核的なテストループです。

セットアップ

1. オープン中の PR を確認する：gh pr list --state open
2. 未マージの PR がある場合はそのブランチを使用し、マージ済みの場合は origin/main から新しいブランチを作成する
3. リベースする：git fetch origin && git rebase origin/main

研究者ペルソナのエージェント

Agent ツールを使って、各ラウンドにつき 2 つのエージェント（A + B）を以下のパラメーターで起動します。

各エージェントに指定する内容：

• 専門分野（腫瘍学、ゲノミクス、薬理学など）
• 研究課題（具体的な生物学上の問い）
• 異なるツールを試す 5～7 個のテストシナリオ
• 重大度（HIGH/MEDIUM/LOW）を付けて問題を報告する指示
• 問題 ID：Feature-{round}{letter}-{num}（例：Feature-59A-001）

エージェントのプロンプトテンプレート — references/persona-template.md を参照してください。

検証（重要）

エージェントが報告した問題を実装する前に、必ず CLI で検証してください。

python3 -m tooluniverse.cli run <ToolName> '<json_args>'

エージェントの報告の 50% 以上は、MCP インターフェースの誤解による誤検知です。検証済みの問題のみを修正してください。

修正の原則

1. 問題を再発させない。後から復旧するのではなく、根本原因を修正する
2. 入力時に検証する — 不正なパラメーターは明確な案内とともに早期に拒否する
3. 「データなし」と「クエリ不正」を区別する — それぞれに異なるメッセージを表示する
4. 抽象化を修正する — 増え続けるエイリアス一覧を追加しない

アンチパターン：検証の代わりにヒントテキストを使う、命名を修正する代わりにパラメーターのエイリアスを追加する、事前検証の代わりに事後的な調査を行う。

スキル有用性テスト（新規 — ツールテストを超えて）

標準的なテストは、ツールが動作することを検証します。有用性テストは、スキルが科学者の問題を実際に解決するかどうかを検証します。標準テストの後にこれを実行してください：

1. スキルが解決できると主張する実際の研究課題を選ぶ（ツールレベルのテストではない）
2. エージェントを起動する — 実際の課題に対してスキルのワークフローに従う
3. 正直に評価する：スキルは実行可能な回答を生み出すのか、それとも単なるデータの羅列なのか？

1〜10 の採点基準：

• 1〜3：ツールカタログ — 解釈なしでツールを列挙するだけ
• 4〜6：データ収集ツール — データを集めるが、組み合わせや解釈には役立たない
• 7〜8：推論フレームワーク — 表やスコアリング、統合によって解釈を導く
• 9〜10：意思決定エンジン — 具体的で防御可能な推奨事項を生み出す

有用性テストで見つかったよくある失敗パターン：

パターン	スコアへの影響	修正
結果をどう扱うかを説明せずに「A を呼び、次に B、次に C」とだけ書く	-3	解釈用の表を追加する
ツールのパラメータが誤っている（ツールは動作するが、スキルが誤った名前を記載）	-2	get_tool_info() で全てのツールパラメータを検証する
API が提供できないデータを約束している（例：DepMap CRISPR スコア）	-2	制限について正直に記載し、計算手順による回避策を追加する
最後に統合フェーズがない	-2	全ての証拠を組み合わせる「だから何なのか？」フェーズを追加する
証拠のグレーディングがない	-1	T1〜T4 などの信頼性ティアを追加する
ツールではできないことに対する計算手順がない	-1	scipy/pandas/numpy を使った Python コードブロックを追加する

ツールが役に立たない場合は、計算手順を追加する：分析によっては API 呼び出しではなく Python コードが必要です。スキルには以下に対する動作するコードブロックを含めるべきです：

• 統計的検定（scipy.stats、FDR 補正）
• ダウンロードしたファイルからのデータ分析（DepMap、TCGA などの CSV を使った pandas）
• スコアリングアルゴリズム（ACMG 分類、生存率スコア）
• 配列解析（Biopython）

完全なガイダンスについては devtu-optimize-skills のパターン 14〜15 を参照してください。

フェーズ 3.5：ベンチマーク評価

テスト後にプラグインのパフォーマンスを定量化します。Skill(skill="devtu-benchmark-harness") を使用します。

# Run lab-bench (20 MCQ)
python skills/devtu-benchmark-harness/scripts/run_eval.py --benchmark lab-bench --mode plugin-only --n 20

# Run BixBench (computational, use first 20)
python skills/devtu-benchmark-harness/scripts/run_eval.py --benchmark bixbench --mode plugin-only --n 20

# Analyze results
python skills/devtu-benchmark-harness/scripts/analyze_results.py --results <results-file>

# Generate report
python skills/devtu-benchmark-harness/scripts/generate_report.py --results <results-file> --output BENCHMARK_REPORT.md

前回のラウンドと比較します。いずれかのカテゴリが後退している場合は、フェーズ 4 でそのスキル／ツールの修正を優先してください。

フェーズ 4：修正とコミット

1. 検証済みの修正を実装する（コードレベルのパターンについては references/bug-patterns.md を参照）
2. code-simplifier を実行する：Skill(skill="simplify") — コードを書いたり変更した後は必ず実行します
3. Lint：ruff check src/tooluniverse/<file>.py
4. 構文を検証する：python -c "from tooluniverse.<module> import <Class>"
5. テスト：python -m tooluniverse.cli run <Tool> '<json>'
6. pre-commit フックのパターン：ステージ → コミット（失敗し、再フォーマットされる）→ 再ステージ → コミット
7. プッシュ：git push origin <branch>

再利用可能な修正パターンとアンチパターンについては Skill(skill="devtu-code-optimization") も参照してください。

フェーズ 5：最適化（任意）

修正が安定した後で：

• Skill(skill="devtu-optimize-descriptions") — ツールの説明を改善する
• Skill(skill="devtu-optimize-skills") — リサーチスキルの品質を改善する
• Skill(skill="devtu-docs-quality") — ドキュメントの正確性を検証する

フェーズ 6：出荷

Skill(skill="devtu-github") を呼び出すか、手動で行います：

1. リベース：git fetch origin && git stash && git rebase origin/main && git stash pop
2. git push --force-with-lease origin <branch>
3. PR を作成または更新する：gh pr create / gh pr view <N> --json mergeable で検証する
4. 完了を報告する前に "mergeable": "MERGEABLE" を検証する

GitHub リポジトリ：mims-harvard/ToolUniverse — プッシュする前に必ず git remote -v で検証してください。

---

Git ルール（重要）

• main に絶対にプッシュしない — すべての作業はフィーチャーブランチで行います
• 複数の修正 PR を同時にオープンにしない — 現在のブランチに追加し続けます
• プッシュする前に必ずリベースする：git fetch origin && git rebase origin/main
• コミットメッセージの形式：「BUG」という用語は使わず、「Feature」または「Fix」を使用します
• コミットに AI の帰属表示を含めない

よくある問題のカテゴリ

カテゴリ	シグナル
パラメーターのサイレントな見落とし	誤ったフィールドのチェック。パラメーターが無視される
条件が常に実行される	誤った型に対する .get("field")
サイレントな正規化	自動変換が明示されていない
表記・大文字小文字の誤り	遺伝子融合、タイトルケースの名前
部分文字列の一致	短いシンボルで複数の対象が返される
try/except のインデント	不一致 → SyntaxError

パターンの全一覧 → references/bug-patterns.md

ラウンドの追跡

各ラウンドの後に、カウンターを進め、パターンファイルを更新し、この SKILL.md を 150 行未満に保ちます。

現在のラウンド：127（完了したラウンド：52-126）