simplify-skill

スキルを簡素化する

使用するタイミング

既存のスキルが、その分野で必要とされる水準よりも理解、運用、検証、保守が難しい場合に使用します。通常のコードのみのクリーンアップには使用しないでください。

成果

名前を明示したアクターとタスクについて、宣言された複雑さのコストを少なくとも1つ削減します。ユーザーが正確な損失を承認しない限り、目的、権限、動作、安全性、依存関係、出力、証明を維持します。

行数だけを簡素化の根拠として認めてはいけません。

厳守する境界

• 現在のパッケージ全体を、基準となる信頼できる情報源として扱います。
• 分野に不可欠な複雑さは維持します。まず偶発的な複雑さを取り除きます。
• 損失のない変更をデフォルトとします。
• コマンド、パス、スキーマ、ハッシュ、引用文、権限ゲート、数値制限、停止ルールは正確に維持します。
• コンポーネントのステータスとスキル全体のステータスを分けて扱います。
• すべてのモデルやプロバイダーで文章が同一になると主張してはいけません。
• 決定性は、閉じた意思決定契約と機械で検証された最終状態として定義します。

必須の構成

リソースゲート：ここに記載されたパッケージファイルを使用する前に、mise run validateを実行します。

パッケージを変更する前に、依存関係の調整を読みます。トリガー条件に該当する場合は、コレクションの開始点、人間の行動、エージェントの行動、意味の保持を担当するオーナーを利用します。

ネイティブホスト専用の読み込みは証拠ではありますが、移植可能な依存関係ではありません。その不変条件を内部化するか、インストール済みの公開ピアにルーティングします。どちらも不可能な場合は、BLOCKED_DEPENDENCYを返します。

入力契約

target、actor、task、environment、scope、invariants、measure、allowed_lossを記録します。データが不足している場合はunknownを使用します。ユーザーが正確な範囲を承認しない限り、allowed_lossはnoneです。

状態機械

次の順序のみを使用します。

DISCOVER -> BASELINE -> CONTRACT -> SELECT -> REWRITE -> VERIFY -> ACCEPT

ゲートに失敗した場合はBLOCKEDに移行します。未承認の損失がある場合はNEEDS_APPROVALに移行します。承認されたコスト削減がない場合はNO_CHANGEに移行します。

判断が同点の場合は、権限、安全性とプライバシー、動作の維持、ユーザーが指定した正確な方法、宣言されたコストの低さ、最後にNO_CHANGEの順で判断します。

手順

1. 発見する。 現在の対象、リンク先のすべてのファイル、近接するオーナー、出自記録、チェック項目、規定するソースを読みます。説明のつかない差異があれば停止します。
2. 凍結する。 すべてのファイルをバックアップし、ハッシュを取得します。既存のチェックと代表的なタスクを実行します。
3. 契約する。 各ルールと観測可能な動作に安定したIDを付与します。権限、強度、条件、保護対象の範囲、対象、証拠を記録します。カバレッジは1.0でなければなりません。
4. 選択する。 deduplicate、clarify、reorder、progressive-disclosure、extract-child、simplify-code、続いてapproved-lossの順に試します。拒否条件に該当せず、宣言されたコストを下げる最初のモードを使用します。
5. 主張を確認する。 動作が改善したと主張する前に、人間またはエージェントの対象集団と、対象となるテストを定義します。
6. 書き換える。 変更対象のオーナーを最小限にします。平易な言葉、1文につき1つのルール、名前を明示したアクター、閉じたステータス語、デフォルト、正確な停止条件を使用します。
7. コードを扱う。 まずテストを行い、コードの証明と指示の証明を分けて維持します。
8. 検証する。 ハッシュ、台帳のカバレッジ、保護対象の範囲、リンク、メタデータ、読み込み、テスト、パッケージの状態、最終状態の読み戻しを再確認します。同じ環境でベースラインと候補を比較します。
9. 承認または復元する。 宣言されたコストが下がり、すべての不変条件に合格し、拒否条件が残っていない場合のみ承認します。それ以外の場合は復元するか、正確なブロック状態を返します。

子への抽出

子を作成するのは、独立したトリガー、単独で完結する成果、明示的なインターフェース、正規のオーナーシップ、直接テスト、親からのルートのテスト、調整コストを上回る見込みの再利用、非循環な読み込みグラフがすべてそろう場合に限ります。行数を減らすことだけを目的に分割してはいけません。

受け入れ条件

ACCEPT には、以下が必要です。

• ベースラインと候補のパケットハッシュが再計算されること；
• 台帳のカバレッジが 1.0 であり、未承認の損失がないこと；
• 保護対象のすべてのスパンが合格するか、明示的な承認を得ていること；
• 同じ環境で、宣言されたコストのうち少なくとも1つが減少すること；
• ネイティブ、タスク、パッケージ、リンク、読み戻しの各チェックに合格すること；
• 10件すべてのネイティブな圧力ケースで、必須の動作が維持され、禁止された動作が発生しないこと。

パッケージの合格、評価への登録、動作評価の合格、コンポーネントのステータス、スキル全体の合格は、それぞれ別の結果です。

リソース

• 簡素化モデル
• 保持契約
• 依存関係の調整
• 台帳テンプレート用の assets/
• 受け入れ済みおよびブロックされた結果の例を収めた examples/
• ネイティブケースの系譜とポータブルなテストを収めた evals/
• パッケージチェック用の mise run test

ファクトリー実行契約

受け入れられる結果は、意味的な同等性を証明し、受け入れられた動作をすべて維持しながら、スキルの複雑さを減らすことです。動作を保つ簡素化の現在の挙動を維持し、変更はその最小の責任主体に限定します。

1. mise run ci で現在のパッケージを凍結し、そのダイジェストを記録します。
2. mise run domain-research-policy を実行し、動作を保つ簡素化の現在の情報源と反証を評価します。
3. 指定された動作を保つ簡素化の操作について、mise run agentic-request を実行します。意味上の判断はモデルに委ねます。
4. mise run decision-policy、mise run ci、動作評価を実行します。失敗した場合は、最も低いレベルの責任主体に戻ります。
5. mise run invocation-policy -- <receipt> を実行し、すべてのタスク、またはドメイン固有の理由による未使用を記録します。
6. 必要に応じて mise run improvement-policy を実行します。保護対象のディメンションに後退がない場合に限り、変更するディメンションを1つに保ちます。

assets/use-case-contract.json はその契約が必要な場合にのみ mise run use-case-policy で読み込み、evals/evals.json はその契約が必要な場合にのみ mise run evals で読み込みます。

再現可能な処理手順、順序、レシート、チェックは Mise が担います。解釈、因果関係の判断、創造的な作業、コードでは得られない直接的な認識はモデルが担います。権限の不足、証拠の陳腐化、またはゲートの不合格があれば停止します。