skill-evolver

Daymade Skill Evolver

現在の専門 Skill を通じて、指定された既存 Skill の調査に基づく改善ラウンドを統括します。元の結果、各ステージの入力、依存関係、返された証拠を相互に結び付けた状態に保ちます。証拠が維持を支持する場合、Skill を変更しないことも有効な結果です。

統括はここで行い、専門的な作業は現在の担当者を通じて実行します。Skill Creator は選択された変更を作成して検証しますが、このラウンドのビジネス目標や調査計画を決めることはありません。 診断のみを求められた場合は、読み取り専用のままにします。

対象と結果を特定する

指定された Skill を、正式なリポジトリまたはプロジェクトのソース、現在のリリース識別情報、該当する場合は実際に読み込まれているエントリに対応付けます。そのエントリと、影響を受けるジョブで使用されるリソースを読みます。ソース、インストール済みのコピー、ホスト側での利用を区別し、キャッシュを所有元であるかのように編集しないでください。

改善を選択する前に、ユーザーに見える結果、その結果を否定し得る観察事項、維持すべき対応済みジョブ、承認済みの成果物、停止条件を明示します。最初に報告された失敗も含めます。それを調査レポート、短縮されたプロンプト、スコア、またはすべて緑のチェックに置き換えないでください。作業内容を変える情報が不足している場合、またはユーザーが決めるべき選択がある場合に限って質問し、すでに得られている回答と承認を再利用します。

候補を比較する間、成果の判定基準を一定に保ちます。改善を受け入れる前に、元の要件に照らして代理指標を修正してください。候補がすでに出している結果に合わせて目標を変更しないでください。

判断を変え得る証拠を集める

現在の実装、プロジェクトの決定事項、既存のツール／Skills、提供された例、以前に検証済みの作業から着手します。証拠の出所と条件が現在の担当者の契約のもとでも引き続き適用される場合は、それを再利用します。選択したステージを実行する前に、ステージ間の引き継ぎを読み込み、該当する担当者のルートに従います。このリファレンスが定めるのは入力と返却結果であり、二つ目の専門手順ではありません。

ステージは、ユーザーからの明示的な依頼、合意済みのルート、未解決の疑問に基づいて選択します。決定的な既存の証拠がある場合、限定的な修正で無関係な調査を行う必要はありません。ただし、その単純さを理由に、依頼された履歴、フェイバリット、競合他社、または Deep Research のレーンを省略してはいけません。再利用、実行、不必要、ブロック済みの作業を正確に示し、省略した調査を完了済みと記述しないでください。

選択した各ステージでは、実行前に、利用可能で能力が適合した担当者、その関連分岐、権限、必要なデータを確認してから、読み込みと実行を行います。公開ワークフローでは、利用可能な公開担当者を優先します。元のユーザー目標、対象ソース／ref、以前に成功したジョブ、承認、準備済みの証拠、解決すべき質問を渡します。そのワークフローを実行し、実際の証拠または結果を確認してから続行します。担当者の一覧や読み込み確認だけでは、ステージを完了したことになりません。推奨事項から証拠リストを作り直すのではなく、未解決の点を依存する判断に結び付けたままにします。

承認された履歴や準備済みの事例については、成功、失敗、ユーザーによる訂正を含め、履歴リーダーと Skill Creator の引き継ぎを使用します。肯定的な改善機会があるからといって、私たちの Skill に過去の失敗が必要になるわけではありません。セッション全体の監査を依頼され、そこから得た教訓を振り分ける場合は、公開の履歴／Creator の引き継ぎを使用し、アクセス可能な場合に限って session-retrospective を任意のローカルアダプターとして使用します。通常の対象改善では、別個の振り返り確認は不要です。

対象のタスク機能を調査する

調査の質問は、ビジネス上の成果と、対象の入力、エラー、復旧、後続利用者への各経路に結び付けてください。外部ツールや調査方法を選ぶ前に、リファレンスのキュレーション連携を通じて、アクセス可能なお気に入りの検索結果、または提供されたキュレーション済みリンク／エクスポートを使用してください。コードに基づく比較には、competitors-analysis の現在のエントリースコープ内にあるソースと統合の経路を使用してください。コードを使わない手動／ネイティブのワークフローには、製品の公式ドキュメント、提供された観察結果、またはタスクのプローブを使用してください。対象の意思決定プロセスを機能一覧で代用せず、ソースに結び付いた仕組みと反証を今回の検討に反映してください。

依頼された調査レーン、または未解決の範囲／統合の課題には、deep-research を実行してください。現在のアセット、モード、ソースの契約を使用してください。承認済みの経路と既存の公式エクスポートを再利用し、プロバイダー、有料モード、レポートの長さを無理に選ばないでください。残る回答が選択や必須の受け入れ条件を変えられなくなったら、情報の取得を止めてください。返された証拠を統合する際は、ソース契約上の事実、実際に確認した動作、測定していないビジネス上の効果を分けてください。

重要な仕組みをすべて判断する

改善の診断を提示する前に、Skill Creator の該当する通常更新またはタスク横断の改善に関する連携を使用し、実質的な候補をそれぞれ対象の現在の意思決定経路と比較してください。既存の仕組みとそのソース、提案する意思決定の変更、その所見が仕組みの欠落、既存動作の未実行、証拠の不足、前向きな機会のいずれに当たるか、そして変更を適用すべきでない条件を1つ示してください。裏付けのある改善余地が残らない場合は、現在の仕組みを再利用してください。

不明または結論が出ていない効果は、価値がないという証拠と分けてください。順位付けされていない手がかりは、修正や投資の推奨と分け、証拠が十分なら調査を終了できるようにしてください。比較や追加調査は、意思決定を変えうる場合、または明示的に依頼された調査レーンを満たす場合にのみ追加してください。先行する失敗がなくても機会についての限定的な学びを維持し、競合他社による検証を無理に求めず、すでに正当化された修正を保持してください。指名されたヘルパーは実際のエントリースコープ内に留め、通常のツールで同等の作業ができる場合は任意としてください。

コードに基づく競合他社調査では、competitors-analysis の Landscape 連携を使用し、既存の分類契約に従って、発見した重要な仕組みをすべて採用、採用しない、または要検証として扱ってください。元の質問とソースに照らして返された網羅性を確認し、前向きな機会と既存の同等機能も含めてください。変更を捏造してはいけません。

技術的な代替案を選ぶ必要がある場合は、統合した証拠と現在の承認範囲を用いて、tech-selection の該当する完全版または簡易版の経路を実行してください。実際に選ばれた案、またはユーザー自身の判断に委ねられた未解決の決定を実装に引き継いでください。既存の所有者がすでに要件を満たしている場合は、重複させるのではなく、その読み込みや呼び出しを修正してください。互換性のある改善は組み合わせてください。大きな方針転換、新たな製品スコープ、実際の好み、取り消せない選択や外部への影響を伴う選択は、既存の承認境界に留めてください。承認された対象作業の範囲内で必要となる、取り消し可能なローカル実装の詳細は選択して実行してください。

選択した変更を実装して検証する

編集を始める前に、不変のソースから対象バンドル全体を確定してください。 トリガー、サポート対象のジョブ、インターフェース、確認ポイント、復旧手段、ユーザー所有データを維持してください。共有チェックアウトに別の作業が含まれている場合は、分離したソースチェックアウトで作業してください。対象のソースと、直接影響を受ける手順、例、ヘルプ、呼び出し元のルートの整合性を保ってください。

仕組みを置き換える前に、読み書きの動作、アクセス権限、生成物の保存場所など、影響を受ける実行時の既定値と副作用を洗い出してください。承認された改善によって明示的に変更され、その変更が受け入れ確認の対象となっている場合を除き、それらを維持してください。一般的なセキュリティ上の好みから、新たな要件を推測しないでください。

リポジトリの通常のワークフローに従って、選択した変更に対する Skill Creator の作成、移行、検証の引き継ぎを実行してください。確定した業務上の基準、従来のジョブ、維持すべき既定値と副作用を要件として渡してください。実際の利用者と復旧確認には対象の実行責任者を使い、統合された結果が依頼を満たすかどうかの責任を委任しないでください。変更は実際の障害発生範囲に基づいて分類してください。新たな機能や手法の追加だけでは、対になる評価、ベンチマーク、反復試行、ビューアー、追加エージェントが自動的に許可されるわけではありません。

実際の利用者を通じて元の結果を検証し、影響を受ける障害と復旧の経路も確認してください。確定したバンドルに照らして、重要な従来のジョブも確認してください。静的な維持確認とタスク結果の証拠は分けてください。既知の正常なケースと失敗するケースを使って受け入れ基準を調整してください。ルールが入力の有無や値を調べる場合、入力がない状態と空の値は区別してください。ソースの読解、サブプロセスの終了コード、テスト、CI は主張を裏付ける材料にはなりますが、要求された結果の代わりにはなりません。

対象リポジトリのリリース手順とローカルで利用可能にする手順に従って、承認された提供を完了してください。要求された結果に含まれる場合は、公開または利用された正確なオブジェクトを読み戻して確認してください。人による受け入れを確認できていない場合は、未確認のままにしてください。それでも、承認された実装と確認は完了してください。

結果を失わずに利用可能な実行手段を使う

選択した所有者は、利用可能なスキル検索を通じて能力に基づいて特定してください。利用できない場合は、現在のホストカタログと、ユーザーが利用可能だと宣言したソースを確認してください。 Evolver に含まれるのは独自のバンドルのみであり、関連する Skills は含まれません。公開されているからといって、インストール済みであること、ブランチの準備が整っていること、必要なデータにアクセスできることの証明にはなりません。非公開のリポジトリ、認証情報、ローカル設定を要求しないでください。所有者を自動的にインストールまたはクローンしたり、ホストの Skill 無効化ポリシーを覆したりしないでください。公開所有者がインストールされていない場合は、公開カタログとインストールガイドで実際のプラグインパッケージを確認するか、利用可能な同等の所有者またはツールを使ってください。実行が成功したと捏造してはいけません。

同じエージェントが Skills を順番に読み込み、実行してもかまいません。権限を付与された委任や、独立した並列レーンを開始する前に、現在のユーザー／ホストとの契約と、公開所有者の委任／検証ワークフローに従ってください。daymade-agent-discipline は、そのオプションのローカルアダプターがすでに存在し、アクセス可能な場合に限って適用してください。依存する段階は、必要な証拠が揃うまで待機します。 原則として、Skill ごとにエージェントを 1 つ割り当てたり、所有者のエンジンをここにコピーしたりしないでください。

呼び出しツールが利用できなくても、特定済みの Skill が存在しないことにはなりません。現在のエントリーを読み、利用可能なツールで該当するワークフローを実行してください。

専門家が利用できない場合は、同じ実質的な作業を行うために利用可能なツールを使ってください。提供された記録の範囲を限定して読み、固定されたソースオブジェクトを調べ、必要なプローブを実行し、トレードオフを比較するか、正本となるソースを編集して検証します。専門家の呼び出しを捏造したり、そのゲートを通過したと主張したりしないでください。必要なソース、権限、ランタイム、または利用者が利用できない場合は、その依存項目のみを一時停止し、不足している観測事項と再開条件を明記して、権限のある独立した作業を続けてください。オプションのツールがないからといって、必須の成果が免除されるわけではありません。

作業を停止し、段階的に再開できる状態にする

実際に改善した内容、または証拠に基づく変更なしの判断、正確なソース／差分と結果の証拠、未達の基準を報告してください。ソース、公開、インストール、準備済みタスクの実行、実際のビジネス成果は、それぞれ区別してください。

既存の正本ドキュメントがある場合は、変更した判断とソースアンカーのみを対象プロジェクト内で更新してください。再利用可能な修正は、それを管理する Skill に保持し、生の過去記録は履歴として残してください。次に行う未達項目とその再開条件は、メモリや 2 つ目の状態台帳を作成するのではなく、既存のタスクコンテキストに残してください。確定済みの調査を繰り返さず、そのアクションから再開してください。必須の結果と成果物の検証が完了した時点、または明示的にブロックされた項目のみが残った時点で停止し、自動的な改善ループを開始しないでください。