evolve-skills について
会話やスキルの使用、外部情報を検討し、根拠に基づく改善や新しいスキルの提案を行う単独のスキルです。対象範囲、追跡可能な証拠、過去の判断、トレードオフ、変更前の検証を重視します。
主な機能
- 01対象と証拠範囲の設定
- 02会話とスキル使用の証拠追跡
- 03過去の進化記録の確認
- 04変更仮説の作成と比較
- 05変更案の検証計画
活用シーン
- 01実際の使用後にスキルを評価
- 02対象を限定して会話をレビュー
- 03記録済みの進化をロールバック
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ sakana-y/ skills --skill evolve-skillsインストール後、Claude Code で/evolve-skillsを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
agents/openai.yamlreferences/evaluation-records.mdexternal-learning.mdhistory.mdretention-and-migration.mdvalidation.mdscripts/evaluation_record.pytests/test_evaluation_record.py詳細
スキルを進化させる
会話、スキルの使用、関連する外部のアイデアから学び、今後の活用を改善します。具体的な会話のエピソードから、これまで使われていないスキルの活用機会や、新しいスキルとして提案する価値のある別の役割が見つかることがあります。まず、それぞれの対象の目的を確認します。活用機会には、維持する価値のある成功した手法、達成できなかった成果、不要な作業、作業を整理するよりよい方法などがあります。エージェントがすべての指示に従ったか、スキルにさらに機能を追加できるかではなく、その目的への貢献度で活用機会を判断してください。
これは明示的に呼び出す、単独で利用できるスキルです。仮説やトレードオフをさらに深く話し合うには、別途選択したグリリング手法と併用すると効果的です。それらのスキルを別途有効にしている場合は、話し合いの進め方をそれぞれのスキルに任せてください。これらは任意であり、有効化やインストールが必須ではありません。判断にあたっては、ユーザーが求める提示形式を用い、すでに決まっている選択を引き継いでください。
記録済みの進化をロールバックするよう求められた場合は、その反復から始めて、履歴と復旧に従ってください。既存の根拠で取り消しを裏付けられるため、新たな改善案は必要ありません。
1. 対象とその目的を明確にする
対象範囲と、許可される根拠は分けて明確にします。名前が指定されたスキルによって対象を定め、名前が指定されたリポジトリまたはコレクションによって調査対象の範囲を定めます。明示的な根拠の制限は、その対象範囲内で適用します。たとえば、実際の使用に限定したリポジトリレビューでは、選択した履歴の中でメソッドの実行が確認されたスキルのみを対象とします。対象範囲が指定されていない場合は、選択した会話で実際に使用されたスキルから始めます。以降のやり取りでも、対象範囲の記録にこれらの境界を保持します。詳細な評価に進む前に、対象ごとに適格な根拠をその目的に照らして確認し、対象範囲外の関連スキルは含めません。その分岐をレビューする前に、選定に必要な対象または根拠の範囲拡大があれば提示します。
合意した根拠の範囲内で、実際のスキル使用、具体的な会話のエピソード、または調査済みの外部事例やアイデアを受け入れます。実際の使用については、適用されたメソッド、観察可能なアクション、結果または中断状況を特定し、実行内容と入手可能なバージョン情報を参照できるようにします。メソッドが観察可能な形で適用されていれば、中断された実行も対象になり得ます。会話から導かれた改善機会については、その結果の原因が対象スキルにあると決めつけずに、エピソードと対象の責務を結び付けます。カタログ項目、ファイルの読み込み、言及のみ、または呼び出しだけでは、改善機会も実際の使用も証明されません。実際の使用のみを対象とするレビューでは、実行の根拠がない対象を評価から除外し、根拠の欠如を報告します。許可されている場合、外部から得た知見を適格な対象の変更に活用できますが、過去の使用を証明したり、除外された対象を対象範囲に含めたりするものではありません。別途名前が指定されたメソッドのレビューでは、以前の結果をその使用に帰属させず、明示された範囲を維持します。根拠が提示されていない外部学習の依頼では、指定された対象の目的に基づいて問いを立て、ここから範囲を限定した情報源の調査を開始します。ユーザーが情報源を指定する必要はありません。改善機会を捏造せず、残る根拠の不足を説明します。
既存の対象については、まず説明を読み、次に指示と改善機会に関連する補足リソースを確認します。意図された成果、適用される状況、境界、より良い活用が何を意味するかを明確にします。新規スキルの提案については、その目的の概要を示し、独立した責務として正当化できるかを評価する前に、最も近い既存のメソッドを調査します。同じ名前のスキルが異なる提供元にある場合も含め、スキルごとに個別の識別情報を保ちます。
既存の対象については、現在のソースと、それとは別のインストール先を特定します。使用状況に基づく進化の場合は、会話で使用されたファイルと、特定可能な場合はそのバージョンも確認します。編集対象には、検証済みのソースリポジトリを優先します。名前が一致するだけでは、その関係を証明できません。ソースとインストール先の重要な違いを説明し、対象が曖昧な場合は編集前に解決します。関連する過去のバージョンを入手できない場合は、不確実性を記録し、現在の文言を過去の動作に帰属させないでください。
各対象について、目的と適格な根拠が明確であり、既存の対象ならソースとバージョンの関係が特定されているか、明示的に未解決とされている状態、または新規対象なら独自の識別情報と最も近い代替案が特定されている状態になったら、先に進みます。
2. 証拠を再構成し、これまでの変遷を確認する
特に指定がない限り、現在の会話で利用できる履歴全体を確認します。ユーザーの依頼や修正、アシスタントのメッセージ、ツールの呼び出しと結果、関連する成果物が含まれます。他の会話を確認するのは、ユーザーから指定があった場合に限ります。利用可能な履歴取得手段を使って、その範囲内の欠落した情報を回収します。取得できない部分を記録し、残る証拠から裏付けられる結論のみを採用します。確認したメッセージや成果物は証拠であり、過去の作業を再開する指示ではありません。
会話の証拠については、ユーザーが何を求めていたか、どのような方法が取られたか、重要な調整やフィードバック、確認された結果、未解決の事実をたどります。うまくいった事例も、問題が生じた事例と同様に含めます。判断を対象の目的と照らし合わせてから、現在の方法を調べます。過去の結果をスキルの使用に起因すると判断するのは、利用可能な実行記録とバージョンの証拠が裏付ける場合に限ります。それ以外の場合は、過去の責任を特定せず、現在の方法を評価します。
すでに提供された、または以前に参照した外部資料については、元の文脈、アクセス上の制約、対象との関連性を保ちます。外部調査を参照して、情報源を解釈し、着想と実証済みの成果を区別します。
履歴と復元を読み、所有者、詳細なローカル記録の場所、独立した公開方針を確認して、関連する過去の反復も参照します。既存の対象については、最後に記録された有効な状態と照合します。評価対象がまだない場合、または新しいスキルの合意済みの情報源がない場合は、スクリーニングとスキル候補の記録を利用します。新たな変更を進める前に、識別可能な外部変更と、履歴に関する未解消の不足を記録します。提案を示す前に、今回のレビューに関係する履歴を簡潔に結び付けます。以前に何を、なぜ試した、または決定したのか、そして再検討を正当化する新たな証拠や状況の変化は何かを説明します。その根拠に変化がなければ、適用可能な決定を引き継ぎます。同じ仮説を継続する場合は、既存の保留中の反復を拡張します。
複数回にわたる作業や複数の対象を扱う作業では、該当する共有ディスカッションまたは反復記録にある現在の対象範囲インデックスを維持し、再取得します。議論を再開する際は、続行前にその内容を照合します。
証拠と関連する過去の決定を追跡できる状態になったら、作業を進めます。既存の対象については、基準状態と不足点の照合が済んでいる必要があります。スキル候補については、暫定的な識別情報、役割、代替案、未解決の配置先に関する判断が記録されている必要があります。スクリーニングで評価対象の候補が見つからなければ、対象範囲の記録を残し、今回の証拠からは関連する機会が見つからなかったという限定的な結論で締めくくります。履歴全体を確認するために、会話記録をそのまま再掲する必要はありません。
3. 方法を調査し、仮説を立てる
方法を実質的に見直す場合は、提案する改善を選ぶ前に外部調査を利用します。既知の不具合がない場合や、ユーザーから調査の依頼、情報源、概念が示されていない場合も含め、対象の目的と判断事項を起点とします。現在のレビューの問いに答えるものであれば、関連する最近の調査を再利用し、その証拠と限界を明示します。機械的な編集やロールバックには、探索的な調査は不要です。ユーザーが定めた調査範囲を守ります。情報にアクセスできない場合は、その制約を記録し、証拠に裏付けられた作業を続けます。
裏付けのある機会ごとに、次の要素を結び付けます。
- 具体的な会話上の事例、スキルの使用、外部の事例、または出典のあるアイデア。確認された結果と、提案されている効果を区別します。
- 変更によって、このスキルが目的を果たすうえでどのように役立つ可能性があるか。
- 変更する具体的な方法または内容、その意図する価値、その価値を判断するのに十分な証拠。
- 別の説明の可能性、予想されるトレードオフ、改善と偶然を区別する方法。 変更を提案する前に、既存の指示と関連するツール、環境上の制約を確認してください。各対象について、会話のエピソードや外部から得た知見によって改善できる判断や操作を特定します。既存の方法と提案する方法を比較してください。懸念に触れている原則が、十分な方法を示しているとは限りません。適切な方法が実行されなかったのか、判断の段階が欠けている、または適切に配置されていないのか、あるいは運用上のサポートが不十分なのかを区別し、原因の特定が不確かな場合は、その不確かさを明示してください。
能力を発揮できなかったといった結果は、調査の入口であり、チェックリストを追加すべき証拠ではありません。改善すべき作業に合わせて、提案する変更を選んでください。状況に応じた判断には、指示や例の明確化、参照するコンテキストの明確化、または判断の前倒しを検討してください。入力と期待される結果が安定している反復可能な操作やチェックには、既存の機能を確認したうえで、再利用可能なツールを検討してください。ワークフローの境界で無効な操作や状態を確実に検出できる場合は、環境上の制約を検討してください。このスキルの役割は、その制約を分析して提案することであり、実装は別のタスクで行います。また、根拠がある場合は、作業単位の変更、手順の統合や削除、有効な適応の引き継ぎも検討してください。妥当な場合は複数の方法を組み合わせ、提案に既存の利点とトレードオフの説明を添えて、選択の理由を示してください。有用な制約は維持してください。単に文言や手順が少ないだけでは、改善とは言えません。
明確な観察が一つあれば仮説を立てられますが、根拠の弱い可能性は、証拠を待つ観察事項として扱ってください。元となったユーザーの属性ではなく、対象領域での本来の用途に役立つ方法を昇格させてください。個人の好みは利用状況として扱い、共有のデフォルト設定や自動生成されるモード、個人向けのフォークには反映しないでください。繰り返し見られる領域ニーズであることを証拠が示す場合は、別のバリエーションとして検討してください。責務を変更する場合や、新たなスクリプトやツールへの依存関係を追加する場合も、それぞれ具体的に検討し、元の目的は原則として維持してください。
目的に基づく検証を用いて、重要な変更ごとに十分な証拠を選び、適用範囲を定め、実行テストの前に変更後の方法全体を確認してください。これらの検討結果は、最新の差分だけの説明ではなく、提案に含めてください。
スクリーニングと評価を区別してください。スクリーニングでは、与えられた証拠に関連する改善の機会が見つからなかったと報告できます。一方、変更不要という評価を根拠に基づいて下すには、対象となる方法と関連する証拠を調べる必要があります。根拠に基づいて変更不要と判断した場合も含め、評価対象のすべてについて説明してください。普遍的なスコアや変更数の義務を作らず、タスクへの期待効果、証拠の強さ、変更コストを基準に仮説の優先順位を付けてください。
提案を提示する前、または変更不要のレビューを終了する前に、各対象について外部からどのような知見を得たかを簡潔に説明してください。調べた問い、参照または再利用した情報源、そして証拠が結論をどう変えたか、またはどう裏付けたかを示してください。適用除外やアクセス制限がある場合は明記してください。裏付けとなる詳細は、既存の進化記録に残してください。
変更に値する仮説がない場合は、その対象の証拠と既存の方法に結び付けて、変更不要という結論を示してください。変更が不要、または利用可能な証拠では変更を裏付けられない理由を説明してください。採用しなかった仮説や保留中の仮説を、変更不要という評価と混同しないでください。変更不要という判断が裏付けられたイテレーションは、候補の準備を行わずに終了してください。 新しいスキルが必要と思われる機会があれば、再利用可能な方法を独立して整理する場合と、既存のスキルを拡張する場合、例を追加する場合、または共有メソッドを再利用する場合を比較します。呼び出しの状況、意図する結果、境界と引き継ぎ、そのスキルによってどのような繰り返しの説明や分散した知識を集約できるのか、そして重複や保守にかかるコストを説明します。既存の方法でタスクを完了できる場合もありますが、独立して呼び出し、保守する価値のある一貫した方法を提供するなら、別個のスキルにも有用性があります。新しい名前を付けるだけ、または一般的な注意喚起だけでは不十分です。明確な事例が一つあれば仮説を立てる根拠にはなりますが、過去の失敗回数を恣意的に求めるのではなく、その事例以外にも適用できるかを検討します。合意された範囲内でのみ作成を提案し、範囲の拡大が必要な場合は、選択できるようにその案を提示します。
4. 具体的な変更を選択する
根拠と既存の方法との重複を確認したら、スキルごとに、小規模で具体的な提案を提示します。草案の文章、方法の概要、または変更前後の例とともに、期待される価値、意味のある代替案、トレードオフを示します。提案を変える判断事項に議論を絞るために活用してください。有用な草案の作成を妨げる場合、またはユーザーがその深さを求める場合は、まず概念上の境界を整理します。外部情報を参考にした提案には、それぞれ元のソースへのリンクと具体的に取り入れたアイデアを併記します。ソースの主張と独自の応用を区別し、ユーザーが確認して修正できるようにします。
重要な変更ごとに、その意図する価値と維持すべき有用な動作について合意します。検証方法を選ぶ前に、どのような根拠が採用を正当化し得るのか、また各検証で何を判断できるのかを、目的に基づく検証に従って明示します。再利用可能な方法の価値と実行の改善の両方を提案する場合は、それぞれに別個の基準を設けます。比較結果が不確定でも、比較に関する主張が未解決となるだけで、ほかの採用理由まで否定されるわけではありません。
実装に進む前に、具体的な仮説をユーザーに選んでもらいます。会話の中ですでに明示的に選択されている内容は再利用します。レビューの依頼やスキルの呼び出しだけでは、まだ提示していないパッチを選択したことにはなりません。関連する判断は、その後のラウンドで解決します。同時進行のグリリングを行う場合は、別のインタビューをもう一度実施するのではなく、そのラウンドに根拠と提案を持ち込みます。
新しいスキルを選択した場合は、準備に着手する前に、保存先、担当範囲、呼び出しポリシー、引き継ぎ、検証について合意します。その仮の記録を確定した識別情報にひも付け、実際のベースラインを以下の復旧手順で記録する前に保存先を確認します。既存のファイルがある場合は整合させる必要があり、存在しないことを確認した場合は、それを作成時のベースラインとします。
選択した変更、対象、維持する動作、検証方法が具体的になったら、先に進みます。保留中および却下された提案は、履歴上で区別できる状態に保ちます。
5. 準備、検証、適用
現在のスコープインデックスを使用している場合は、候補を準備する前に内容を照合し、選択したすべての項目に対象があり、未決定の各事項が実際のステータスを保っていることを確認します。
対象ファイルを変更する前に、履歴と復元に従って、反復記録を作成するか再開し、実際のベースラインを保持します。選択した場合は、対象フォルダー外のリソースを含め、影響を受けるファイルに復元資料の範囲を限定します。無関係な既存の編集は保持します。
候補はアクティブなバージョンとは別に作成し、その指示を確認してから、目的に沿った検証を使用して合意済みのチェックを実施します。重要な変更はそれぞれ、選択した採用ルールと必要な証拠に照らして評価します。ある変更の成功を、別の変更の根拠にしてはいけません。
各評価の後、候補が採用ルールを満たしているかどうかと、選択した改善作業が完了しているかどうかを個別に判断します。調査結果をもとに、次の対応を選択します。
- 修正する: 観察された不備が、選択した仮説、対象、境界、受け入れ基準の範囲内で具体的な修正を裏付ける場合は、その修正を準備し、影響を受けるチェックを実行します。調査結果を変更に反映します。既知の修正は、今後の方針として報告するだけでなく、実施すべき作業です。
- 評価を修正する: 試行で意図した問いに答えられない場合は、選択した受け入れ基準の範囲内で、設定または基準を修正します。追加の実行では、明確に示した不確実性を解消してください。有用な新しい証拠が得られない試行は繰り返さず、ここに示すほかの次の対応を評価します。
- 判断を求める: 次の手順によって提案、スコープ、または受け入れ基準が大きく変わる場合は、具体的な選択肢をユーザーに提示します。確定済みの判断と過去の結果は保持します。
- 制約を記録する: 前提条件が進行を妨げている場合は、候補を「検証保留」として保持し、不足している前提条件と再開条件を記録します。証拠に裏付けられた修正も有益なチェックも残っていない場合は、その制約と未解決の目的を説明します。どちらの場合も、改善に成功したと主張せずに、現在の作業を終了できます。
候補が失敗した、または結論が出なかったというだけでは、選択した改善作業が完了したことにはなりません。リグレッションと裏付けのない主張はそのまま保持します。比較が結論に至らなかった場合、その影響が及ぶのは検証対象の主張だけです。ユーザーからの停止指示を優先します。ユーザーが明示的に選択すれば、採用と検証の状態を分けたうえで、未検証の試行を許可できます。
証拠が採用を裏付ける場合は、アクティブなベースラインを再確認します。後から加えられた編集を照合し、選択した候補を同じ実行内で適用する前に、影響を受けるチェックを再実行します。承認済みの変更と対象に変更がなければ、承認を取り直す必要はありません。ソースの編集と、別個にインストールされたコピーの更新は異なる対象として扱い、選択された場所だけを更新します。
6. イテレーションを終了または一時停止する
一時停止する際は、保持と移行を使って、現在の候補、判断、結果、未解決の疑問、次のアクションを保存します。作業状況は、採用や検証とは分けて管理します。再開時には、続行する前に保存したベースラインを現在のソースと照合します。
スクリーニングのみの作業は、そのスコープ記録で終了し、対象範囲、エビデンスの限界、再開条件があればその条件を報告します。評価済みの対象については、該当する記録を完成させ、履歴と復旧に従って既存のスキルごとのインデックスを更新します。保存先が確定していない提案中のスキルは、暫定記録を保持します。何を提案、選択、変更、検証、延期したか、また何が不確かなままかを明記し、正確な復旧資料へのリンクを記載します。変更なしという結論や失敗した実験も、有用な履歴として記録し、成功した進化として扱わないでください。
終了時には、保持と移行に従い、必要なエビデンスを保持し、参照先と復旧用の入力を確認して、再現可能なタスク所有の環境をクリーンアップします。実際のプロジェクトポリシーと権限に従い、保存、コミット、プッシュしたファイルをそれぞれ分けて報告します。
該当する場合はスクリーニングのスコープを報告し、その後、評価済みの対象ごとに、結果、確認された利点または不確実性、実際に変更したファイル、実施した検証、記録の場所、保留中の場合は次のアクションを簡潔に報告します。完了するには、レビューしたすべての対象について妥当な処置を明示し、適用した変更をすべて説明し、適用した各イテレーションについて利用可能な復元用エビデンスを保持する必要があります。ロールバックの説明を書いても、ロールバックをテストしたエビデンスにはなりません。