ce-retune について
ce-retune は、対象モデルに合わせてコーパスを測定・調整するスキルです。再現可能なタスク、実行記録、ビルド選択手段を前提とし、静的な確認ではなく段階的な実験で変更を検証します。
主な機能
- 01測定の前提条件を確認
- 02過去の実行記録から基準を抽出
- 03評価基準を事前に登録
- 04独立したレビューでコーパスを監査
- 05変更と回帰測定を反復
活用シーン
- 01新しいモデルでのコーパス評価
- 02エージェントの停滞や早期終了の調査
- 03事前基準に照らした変更の検証
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ everyinc/ compound-engineering-plugin --skill ce-retuneインストール後、Claude Code で/ce-retuneを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
agents/openai.yamlreferences/baseline-mining.mdcorpus-audit.mdcut-passes.mdhalt-taxonomy.mdnoise-floor.mdworkflow-shapes.md詳細
新しいモデル向けにコーパスを再調整する
新しいモデルで性能が低下するコーパスについては、まず執筆ではなく測定に問題があります。おかしく見える箇所を書き直すと、もっともらしい修正リストは作れますが、どの項目が重要だったのかを知る手段は得られません。
成果: 変更を加える前に登録した基準を、対象モデルでの測定結果が上回り、回帰の種類が取り除かれ、それぞれの除去が原因に基づいて説明できるコーパスです。
完了条件: 基準を上回るか、裏付けられなかった具体的な主張を実行結果で報告します。テストスイートがすべて成功しても完了ではありません。何も壊れなかったことは証明できますが、動作が改善したことは証明できません。
対象外: 単語数の削減です。簡潔さと性能は、同じコーパスを扱う別々の取り組みです。ここで成果となるのは、そのうち一方だけです。報告するのは完了状況であり、単語数ではありません。
フェーズ 0:測定のゲート — まずここを確認する
動作を観測する手段がなければ、このスキルは実行できません。次の 3 つをすべて確認し、欠けているものがあれば明示してください。
- 実行アーカイブ、またはアーカイブを生成するハーネス — ツール呼び出しのトレース、終了マーカー、トークン数、最終メッセージを記録した実行ごとのログ。
- ビルドセレクター — ハーネスから、コーパスの特定のソースチェックアウトを実行対象に指定できます(
--plugin-dir形式のオーバーライド、設定可能なスキルのパス、環境変数など)。これにより、同じランナーを使って 2 つのビルドを比較できます。 - コーパスがエンドツーエンドで実際に実行する、再現可能なタスク。
1 つでも欠けている場合は、停止してその旨を伝え、何を構築すべきかを明示してください。静的監査に切り替え、それを再調整として提示してはいけません。監査で削減できそうな箇所は示せても、削減が役立ったかどうかは判断できません。監査だけを行うこと自体は正当な要望ですが、別の依頼です。
続行する前に、対象モデルと見つかったハーネスを明示してください。
各フェーズ
順番に実行し、それぞれが開始に必須となる参照資料を示しています。フェーズを割り当てる前に references/workflow-shapes.md を読んでください。誤ったオーケストレーションの形にすることが、よくある失敗です。担当ファイルが重複しないように作業を分担し、項目ごとには分担しないでください。項目は複数のファイルにまたがり、同じファイルを担当するエージェントは互いの編集を失わせます。
登録した基準を満たしているかを評価したり、その結果を解釈したりする前に、references/noise-floor.md を読んでください。
- 実行にコストをかける前に アーカイブを調査します —
references/baseline-mining.md。過去の実行は無料のベースラインであり、通常は現時点で実施可能な実験よりも規模が大きいです。 - ノイズフロアを確立します —
references/noise-floor.md。コーパスの同一のコピーを2つ用意し、両方で同じコミットに対してハーネスを実行します。そこで現れる差分が、以降の主張が必ず超えなければならないフロアです。変更が存在する前に、今すぐ基準を文書で登録してください。 結果を見た後で選んだ基準は、基準とは言えません。 - 敵対的な視点でコーパスを監査します —
references/corpus-audit.md。スキルごとに1人のエージェントが削除候補を提案し、別のエージェントが反対の立場を取り、既存の文面を擁護します。2つのパスには、互いに独立したコンテキストが必要です。 ホストに別々のエージェントとして実行する手段がない場合は、阻害要因として報告し、監査を中止してください。同じコンテキストで両方の立場を論じ、それを監査結果として提示してはいけません。 - 外科的なパスで削除します。エージェント1人につき問題1つです —
references/cut-passes.md。症状が停滞、停止、または実行されなかった作業を挙げたまま実行が終わることである場合は、references/halt-taxonomy.mdも参照してください。どの種類を削除する場合でも、すべてのパスには2つのルールが適用されます。スイートをグリーンにするためにテストを編集してはいけません。テストが固定している文字列を削除した場合、それはテストを弱めるのではなく、報告すべき発見事項です。また、すべての停止が敵とは限りません。 停止して確認を求めることが目的のワークフローもあります。それがプロダクトの仕様です。停止箇所に手を加える前に、実際にその先にいるのが誰なのかを基準に、すべての停止を分類してください。判断に用いる基準はreferences/halt-taxonomy.mdに記載されています。停止箇所を削除する前に必ず読んでください。 - 測定し、失敗に次の修正を選ばせます — 失敗した箇所がそれぞれ何を意味するか、また計測器が一度も実行しないフェーズを監査する方法については、再び
references/cut-passes.mdを参照してください。登録した基準を超えるまで、4と5を繰り返します。その後は停止してください。基準を超えたら完了です。測定されなかった内容も報告してください。基準を超えたからといって、対象外の範囲までカバーしていることにはなりません。 - リリースします — コミットと報告書で維持すべき内容は
references/cut-passes.mdに記載されています。