tune-skill

PDCA：tune-skill

作業契約

方法論：PDCA（pdca）

タスク：具体的に観察された動作上の問題に対し、既存のエージェントスキルを改善します。そのスキルパッケージ内で、根拠に基づく最小限の変更を行い、方法論、元のタスク契約、複数スキル、自身の調整に関する問題は修正せず、担当するワークフローに振り分けます。

対象読者：このリポジトリでスキルを保守するエージェントと、提案されたスキル変更をレビューする人間です。

コンテキスト：権限の優先順位に従ってリポジトリの指示を確認し、保守対象のソースコピーを特定します。インストール済みコピーと実行時コピーは証拠としてのみ扱い、このスキルの実行中は読み取り専用とします。グローバルコピーは常に読み取り専用です。後続のインストールや同期は、tune-skill の範囲外であり、人間が担当する別のタスクです。無関係な作業ツリーの変更は維持してください。コミット、プッシュ、インストール、グローバルコピーの変更は行わないでください。

PDCA の運用枠組み： 計画：対象の SKILL.md を最初から最後まで読み、動作に関係するリンク先のリソース、失敗した出力または会話、利用可能なソースと実行時の差異も確認します。動作の分類、証拠、期待する動作、維持する動作の境界を含む、不満に対する契約を一つ定めます。ユーザーではなく、成果物から事実を得ます。重要な製品またはスコープに関する判断が曖昧なままの場合は、最大3つの質問からなる範囲を限定したインタビューを実施します。質問は一度に一つずつ尋ね、判断が未確定となる成果物上の事実を示し、推奨する回答を含め、共通認識が明確になるまで変更を加えません。インタビューの各ターンでも、次の4行形式を使用します：Result: blocked、Changeには未解決の判断を記し、編集していないことを確認します。Evidenceには関連する成果物上の事実と推奨案を示します。Nextには人間への質問をちょうど一つ記します。3つの質問を経ても判断を左右する曖昧さが残る場合は、ブロック状態のまま、その曖昧さを明記します。推測したり、インタビューを続けたりしてはいけません。分類する前に、利用可能な証拠から不満がどの分類に該当するか判断できない場合は、blockedを返します。直接編集の承認がないことは分類を妨げませんが、常にDoを妨げます。それ以外の場合は、次の優先順位で最初に一致する分類を使用します：(1) 自己調整は、現在の tune-skill を再帰的に実行しない、別の設計／作成セッションから methodology-selector および methodology-skill-creator に必ず差し戻します。(2) 外部要因：ツール、権限、または古い実行時コピーによって、報告された動作を完全に説明できる場合。(3) methodology への差し戻し：methodology で生成されたスキルが誤った手法を選択した場合。(4) 契約への差し戻し：選択された手法は妥当だが、元の8つのフィールドが誤っている場合。(5) ループへの差し戻し：複数のスキル、共有契約、アーキテクチャ、対象パッケージの範囲外、広範な再設計、または修正の責任が単一の直接的な tune にない場合。(6) 直接 tune：残る原因と修正全体が単一の対象パッケージ内にとどまる場合に限ります。それ以外はblockedです。より具体的な分類は、解決策が対象パッケージの外で実行されるというだけで、別の分類に変更してはいけません。担当先は正確に指定します。methodology への差し戻しは methodology-selector、次に methodology-skill-creator です。契約への差し戻しでは、methodology-selector の8フィールド契約を作り直してから methodology-skill-creator に戻します。ループへの差し戻しは、新しいループ目標の意図とともに loop-orchestrator に渡します。外部要因は、証拠で特定された人間またはツール／実行環境の担当者に渡します。ブロック状態は、不足している証拠または権限を持つ人間に渡します。直接 tune の場合は、失敗した出力を、それを許容した指示、欠落、矛盾、またはワークフローの順序までたどります。維持する動作を損なわず、不満と隣接するケースを1つ修正できる、最小限の動作変更を計画します。不満、証拠に基づく診断、対象パッケージ内の正確なファイル、提案する動作変更、維持する動作、検証計画を提示します。承認提案自体も、次の4行形式で記述します：Result: blocked。Changeには正確なファイル、提案する動作、維持する動作を記します。Evidenceには不満、診断、検証計画を簡潔にまとめます。Nextでは、人間にその正確なスコープの承認または修正を求めます。人間の承認を待ちます。ただし、同じ提案がすでに提示された後に承認されている場合を除きます。 Do：承認後、1つの対象スキルパッケージ内で、因果的に必要なファイルのみを編集します。1つの一貫した修正に必要な場合は、SKILL.md、参照資料、評価、スクリプトを含めます。新たな証拠により別のパッケージ、共有契約、方法論、または元の契約が関係すると分かった場合は、編集範囲を広げる前に停止し、現在の証拠に基づき、同じ優先順位に従ってPlanに戻り、再分類します。すでに行った変更を自動的に元に戻したり、リセットしたり、破棄したりしてはいけません。編集後に再分類が発生した場合は、Result: blockedを返します。Changeには部分的に変更した正確なファイルと状態を列挙し、Evidenceには再分類の根拠を示し、Nextには、変更を保持するか元に戻すかを判断する必要がある担当者と所有ワークフローを明記します。無関係なクリーンアップを変更に混在させてはいけません。

Check：対象パッケージの差分全体を確認し、利用可能な構造バリデーターを実行します。明示的な例外がない限り、すべての動作検証は非変更とします。読み取り専用の成果物または隔離されたハーネスを使用し、テスターに共有リポジトリやランタイムを編集させたり、インストール済みまたはグローバルなコピーを同期させたり、外部システムに接続させたり、ほかの重大な操作を行わせたりしてはいけません。有効な証明に変更が必要な場合は、別途権限を得るまで停止します。安全な証明を得られない場合、完了としてはいけません。元の失敗、またはそれと同等の最小限のケースを再現し、例に過剰適合していないかを明らかにする隣接ケースを1つ実行します。さらに、問題の指摘内容と以前のバージョンまたは差分を、変更を加えず独立してコールドリードで確認します。Markdownのチェックは、動作の証拠にはなりません。チェックを実行できない場合、または失敗した場合は、完了を主張せず、新たな提案、ルート、またはブロックのためにPlanに戻ります。

Act：3つすべての動作チェックが問題の指摘内容を裏付け、スコープが固定されたままである場合にのみ、変更を維持します。それ以外の場合は、新たに承認された計画に基づいて調整するか、所有ワークフローに引き継ぐか、停止します。このチェックとアクションの判断後に、今回の呼び出しを終了します。

必須の出力：簡潔な4行のみを正確に返し、既定の詳細は追加しません。Result: changed | routed | blocked；Change: 動作の変更内容、またはルート変更・ブロックの理由；Evidence: 元のケースまたは同等のケース、隣接ケース、コールドリードの結果、またはルート変更・ブロックを裏付ける証拠；Next: 次に実行する正確なスキル、人間の担当者、またはnone。診断情報や差分の詳細は、求められた場合のみ提示します。

方法の適合性

• 最適な用途：測定を繰り返しながらワークフローを改善する場合。
• 避けるべき場合：次のサイクルがない単発の判断タスク。
• 選定の根拠：実際の利用を通じてスキルの調整を繰り返します。範囲を限定した動作変更を計画して一度適用し、証拠を問題の指摘内容と比較してから、スコープを密かに広げず、維持、調整、引き継ぎ、または停止します。

標準手法

出典：標準PDCAリファレンス

定義

変更を計画し、小規模に実行し、証拠を確認して、得られた学びに基づいて行動することで、プロセスを改善します。

適合性

• 測定を繰り返しながらワークフローを改善する場合に最適です。
• 次のサイクルがない単発の判断タスクでは避けます。

原則

• 計画する変更は、テストできるだけの小ささに保ちます。
• 定められた境界内で実行します。
• 結果を期待値と比較します。
• 次のサイクルに進む前に、標準化、調整、または停止を行います。

手順

1. 役立つ範囲で最小の変更を計画します。
2. 範囲を限定して1回実行します。
3. 仮説に照らして証拠を確認します。
4. ループを維持、変更、または停止することで対応します。

品質に関する質問

• 変更は評価できるだけの小ささでしたか？
• 結果は測定されましたか？
• 次のアクションは証拠に基づいていますか？
• 実行中、スコープは固定されていましたか？

停止

チェックとアクションの判断後に停止します。単発のタスクに対して、次のサイクルを無理に作ってはいけません。タスクがPDCAに適合しない場合、必要なコンテキストが不足している場合、または推測なしでは検証できない場合は、停止して人間に支援を求めます。

検証

• 苦情はユーザーが示した抽象度で固定され、変更を提案する前に、現在の成果物の証拠に照らして追跡されています。
• 範囲を限定したインタビューでは、一度に一つの判断事項を尋ね、推奨回答を提示します。リポジトリの調査後も重大な曖昧さが残る場合に限り、実施します。
• 実行では、作業を direct-tune、return-to-methodology、return-to-contract、return-to-loop、external-cause、blocked のいずれかに分類し、次に担当するワークフローを明示します。
• 人間が正確な診断、ファイル、動作の変更内容、維持する範囲を承認するまで、対象ソースは編集しません。
• direct tune では、対象となる一つのスキルパッケージ内で、因果的に必要なファイルのみを変更し、インストール済みのコピーやグローバルなコピーには手を加えません。
• 方法論から生成されたスキルでは、選択した方法論と8項目の契約を維持します。互換性のない修正は上流へ差し戻します。
• 元の失敗、または証拠上同等のケース、隣接するケース、変更を加えない独立したコールドリードのすべてが完了を裏付けます。確認項目が欠けている場合や、確認に失敗した場合は、完了として扱いません。
• 最終回答には、ユーザーが詳細を求めない限り、Result、Change、Evidence、Next のみを含めます。

提示する証拠：

• 苦情の契約と、診断に用いた成果物の証拠。
• 承認済みのファイル範囲と、対象スキルパッケージの最終差分。
• 元のケース、または証拠上同等のケース、隣接するケース、独立したコールドリードで観測された結果。
• Result、Change、Evidence、Next の最終4行の報告。

人間によるレビューと停止

• 範囲を限定したインタビュー後も、苦情、期待される動作、または維持する範囲が曖昧なままである。
• 証拠から、方法論または元の8項目の契約が誤っていると判断される。
• 修正に別のスキルパッケージ、共有契約、アーキテクチャの再設計、または tune-skill 自身の変更が必要である。
• 承認済みのファイル範囲を超えることになる。
• 元の失敗、隣接するケース、または独立したコールドリードを実行できない、あるいは完了を裏付ける結果にならない。

次の作業を行う前に人間の承認が必要です：正確な診断と提案された変更を確認したうえで、対象スキルパッケージを編集すること。

境界

• PDCA のみを適用し、別の方法論を組み合わせないでください。
• 検証を容易にするために、タスクの契約を変更しないでください。
• 必要な人間の判断を得ずに、承認を行わないでください。
• タスクが記録済みの方法論への適合から外れた時点で停止してください。