skill-factory

skill-factory

skill-factory は、実用的なエージェントスキルを作成、更新、標準化します。要求された目的を保ちながら、手順、参照資料、アセット、スクリプト、テスト、Mise グラフ、CI、例、評価が新規チェックに合格する、移植可能なディレクトリを生成します。

成果と動機

成果とは、意図したユーザー向けの結果を生み出し、それを証明できるスキルです。パッケージの形状は必要な証拠ですが、それ自体が成果ではありません。重要な制約の背後にある理由をすべて明記し、実行者が成果を損なうことなく許容範囲内で適応できるようにします。モデルの注意を意味、判断、創造的な作業、例外に集中させるため、決定論的な仕組みは説明文に含めません。

シンプルさと言葉遣い

成果、証明、境界、禁止される結果、必須の手法、および受け入れられた動作を保つ、最小限で一貫した構造を、このファクトリーとすべての出力に適用します。シンプルとは、理解しやすいことです。各ルールの正式な所有元は1つ、各概念の安定した用語は1つ、各作業の既定の手順は1つ、重要な未知事項ごとの明示的な失敗分岐は1つにします。重複するルール、装飾的な構造、不要な間接化、動作を変えない選択肢を取り除きます。行数を減らすために、重要なドメインの複雑さを隠したり、ルールを弱めたりしてはいけません。

サポートを読み込む前に、各操作のコンテキスト予算を設定します。常時読み込む本文は、ドメインを完全に網羅する最小限の判断経路にします。各分岐では、現在の判断に必要な正式な所有元だけを読み込み、その内容ダイジェストを記録または検証し、検証済みの現在の受領証を再利用します。所有元が変更された場合、または不確実性がある場合にのみ、再読込みします。トークン効率を高めるために、ドメインの動機、制約、インターフェース、失敗分岐、証明の責務、モデルが担う能力、または知的で慎重な適応に必要なコンテキストを取り除いてはいけません。

平易で直接的な言葉を使います。このファクトリー、およびこのファクトリーが作成、更新、標準化、または取り込むすべてのスキルに対して、mise run lint-writing を通じて執筆ルールを読み込みます。まず結果を示し、能動態を使い、1文に1つの考え、1段落に1つのトピックを盛り込み、指示は実行順に並べます。機械的なリンターでは、範囲が限定された文章上の問題を検出します。同じ意味を保ちながらパッケージがよりシンプルになり、なお完全であるかどうかは、人によるレビューで判断します。

証拠と情報源の順序

まずユーザーの要求と、現時点で有効な正式な情報源を使用します。次に、現在の対象スキル、mise run validate を通じて読み込む生成契約、タスク固有の参照資料、実例、評価の証拠を使用します。ドメインの動作、用語、役割、制約、証明を定義する前に、mise run domain-research-policy を通じてユースケースの具体性を読み込みます。すべての側面とプリミティブについて、ドメインでの役割、保護する成果、具体的な進捗への価値、動機、防止する失敗、証明を明記します。データ構造、形式、キャッシュ、ベンチマーク、改善の試行を選ぶ前に、mise run improvement-policy を通じてリソースと実験の設計を読み込みます。生成するスキルの必須順序は、成果、動機、証拠、Mise タスクグラフ、手順、アセット、評価です。この順序によって、意図を行動に、行動を証明につなげます。

このスキルが受け付けるコマンド

ユーザーのリクエストを、次のいずれかのコマンドとして解釈します。

コマンド	説明
help	この表と、各コマンドの概要を1行で表示します。
new	プロンプトを満たすスキルを作成します。主な手順は以下のとおりです。
update	既存のスキルを変更し、その分野の目的と受け付ける動作を維持します。
standardize	既存のスキルを、このファクトリーの標準形式に変換します。その分野の目的は置き換えません。
standardize-target	ベースラインの凍結後に、プロファイルに基づくインプレースのレジストリ標準化を計画または適用します。
refresh-registry-lineage <skill...>	レジストリのスキル変更が承認された後、ソースの系譜を更新します。
import	ホスト固有のソースを、独立したポータブルなスキルとリポジトリガイダンスのパッケージに変換します。
variant	独自に適応させたスキルを作成します。明示的に要求された場合は、既存のスキルを更新します。
validate	スキルの構造、記述、コード、プレースホルダーのチェックを実行します。
eval	スキルの評価ファイルを確認し、テストケースを実行します。
doctor	mise run doctor を実行し、準備状況を報告します。

リクエストがどのコマンドにも該当しない場合、または必要な情報を取得できない場合は、処理を中止し、不足している情報を報告して回答を待ちます。推測してはいけません。

順序付きワークフロー

1. 成果とドメインを定めます。 モデル：コマンドを分類し、ユーザーに見える結果、境界、禁止する結果、許容される動作を、事実を作り出さずに確定します。分岐：依頼に応じて、新規作成、更新、標準化、インポート、バリエーション、検証、評価、診断、ヘルプから選択します。作成を始める前に、mise run resolve-scope を使用して、明示された選択を尊重し、更新時には有効なスコープを維持するか、意図する提供範囲が未確定の場合は簡潔な質問を1つ行います。
2. ランナーの準備状況を確認します。 Mise：mise run doctor を実行します。モデル：対応する公開操作を選択します。条件：準備が整っていない場合は、阻害されている作業を中止し、失敗した前提条件を正確に報告します。
3. ユースケースの根拠を確立します。 Mise：mise run domain-research-policy と mise run use-case-policy を実行します。モデル：最新の情報源を収集し、反証を検証して、対象スキルの用語、役割、失敗、根拠、対象外事項を決定します。各項目について、必須の情報源とドメインの各側面を、採用、却下、範囲の限定、または理由を添えて該当なしとします。
4. 変更内容を確定し、振り分けます。 Mise：操作にソースがある場合は、mise run plan-standardize -- <source> を実行します。クライアント固有のコーパスをインポートする場合は、mise run audit-source-corpus -- <source> を実行します。ポータブルなスキルパッケージには、パッケージのチェックを使用します。レジストリを直接更新する場合は、mise run standardize-target -- <source> --profile <profile> を --apply なしで実行し、プロファイルと変更セットを確認してから、--apply を付けて再実行します。モデル：ベースラインを維持し、最小限の担当箇所を特定して、衝突、所有者不明、ホスト固有の前提を却下します。
5. BOOTSTRAP、RED、GREEN、REFACTOR の順で構築します。 Mise：mise run task-graph-policy を実行し、続いて RED を記録するために mise run test を実行します。変更のたびに、再度実行します。モデル：決定論的なコードでは判断できない、ドメインの推論、創造的な動作、例外処理を記述します。反復：RED で動作の契約が失敗することを確認し、最小限の変更を実装して、GREEN になるまで再実行します。同じ契約のもとでリファクタリングを続け、必要な動作が通るか、実際の阻害要因によってループが止まるまで繰り返します。
6. 統合された根拠を作成します。 Mise：mise run decision-policy、対象スキルの mise run ci、続いて mise run refresh-registry-lineage -- <skill>、mise run validate-target -- <path>、mise run eval-target -- <path> を実行します。モデル：意味、情報源と主張のつながり、必要な場合の直接的な認識、反例、そして結果が確定した成果を実際に満たしているかを確認します。条件：チェックまたは判断に失敗した場合は、担当する最も下位のステップに戻り、そのステップに依存するものを無効にします。
7. 実行内容を記録します。 Mise：mise run invocation-policy -- <receipt> を実行します。モデル：残っている制限をすべて明示します。各項目について、すべてのタスクの実行根拠、またはドメイン固有の該当なしの理由をレシートに記録します。
8. 改善を維持するか、元に戻します。 Mise：任意の試行の前に mise run improvement-policy を実行します。モデル：名前を付けた評価軸が改善し、保護対象の評価軸が後退しない場合に限り、候補を維持します。それ以外の場合は、採用済みのダイジェストに戻して検証します。
9. メンテナンスは最後に行います。 Mise：採用する成果の作業が完了した後にのみ mise run mise-primitives-update を実行し、その後 mise run ci を再実行します。モデル：変更されたプリミティブを調整し、パッケージマネージャーによる阻害要因があれば、強制せずに報告します。停止：すべてが受け入れられた最初の状態で終了し、無関係な作業を追加しないでください。

決定論的な領域とモデルが担う領域の境界

決定論的なコマンドはすべてMiseが担います。スキーマ、解析、検証、ファイル生成、状態遷移、タスクの順序付け、レシート、測定、比較、再現可能なロールバック検査は、テスト済みスクリプトにまとめ、単一のMiseタスクの配下に置きます。モデルが担う領域は、意味の解釈、ドメインに関する判断、創造的な生成、因果関係の説明、人間の感覚による直接的なレビューのみに限ります。スキーマ検査に合格しても、意味や品質を証明することはできません。

Miseはオーケストレーションの境界であり、能力の上限ではありません。結果を得るために必要な、利用可能で認可されたあらゆる能力を使います。たとえば、直接的な視覚認識、最新のウェブ調査、ブラウザーやコンピューターの操作、ツール呼び出し、マルチモーダルな検査、意味的推論、統合、創造性、人間の感覚による判断などです。Miseには入力の準備、依存関係のスケジュール設定、レシートの保持、再現可能な主張の検証を任せますが、直接的な判断を代理手段で置き換えてはいけません。タスクにコードでは提供できない能力が必要なら、その能力を無効化したり模倣したりするのは、決定論的なゲートをすべて通過していても失敗です。Miseは、機械的な遅延をなくし、再現可能な不具合を明らかにすることで、モデルが担う注意を意味、知覚、創造性、例外に集中させるためのものです。

長いプロンプト、スキル、エージェント型プリミティブは、mise run agentic-request -- --request <file-or-dash> --runner <executable> --runner-args-json <array>を通じて実行します。リクエストをユースケースの契約、成果、ドメイン用語、ダイジェストに結び付けます。各プロンプト、SKILL.mdの依存関係、プリミティブには、ドメイン上の役割、貢献、関連性、証明を明記します。ランナーの認可は呼び出し元が提供します。ディスパッチャーは、シェル展開を介さず、標準入力で単一のJSONエンベロープを使用します。証明するのは構造であり、関連性や結果の品質ではありません。

一見すると非決定論的な作業を分解します。安定したマニフェスト、レシート、スキーマ、カバレッジ、順序、ダイジェスト、予算、出力エンベロープ、判断、ロールバックは、単一のMiseタスクを通じて処理します。意味の解釈、因果推論、創造性、直接的な知覚、人間の感覚による判断だけを残し、なぜコードがそれを担えないのかを記録します。

同じエンベロープ、プリミティブマップ、根拠のある判断、グラフ、証明、反証条件、失敗時の分岐、ロールバックを、skill-factory自体にも適用します。

実質的な各判断の結果、動機、選択した経路の理由、担当者、入力、影響、証明、反証条件、失敗時の分岐を、mise run decision-policyを通じてassets/decision-records.jsonに記録します。その記録が正しいかどうかは、意味的なレビューで判断します。

データ構造、アルゴリズム、形式、キャッシュキー、バッチ処理、並行処理は、測定したアクセスパターンに基づいて選択します。コールドパスとウォームパスに加え、該当する時間、CPU、メモリ、ストレージ、ネットワーク、キャッシュ、コンテキスト、プロセス、並行性、アクセラレーター、コスト、人間の注意を測定します。使用しなかったものも記録します。すべての入力、バージョン、環境、出力がそろっている決定論的なタスクのみキャッシュします。リアルタイムの判断、変更可能なリモート状態、捕捉されていないランダム性、副作用は、決してキャッシュしてはいけません。

Mise タスクグラフ

公開インターフェースは、mise run doctor、mise run resolve-scope、mise run new、mise run variant、mise run plan-standardize、mise run standardize-target、mise run refresh-registry-lineage、mise run audit-source-corpus、mise run domain-research-policy、mise run use-case-policy、mise run mise-primitives-policy、mise run primitive-lifecycle-policy、mise run task-graph-policy、mise run decision-policy、mise run validate-target、mise run eval-target、mise run agentic-request、mise run invocation-policy、mise run mise-primitives-update、mise run ci です。決して迂回しないでください。Mise がない場合は BLOCKED です。すべての依存関係と、各操作からのパスを 1 つずつ宣言してください。循環、ダイヤモンド、未知または未接続のエッジ、冗長なエッジ、ネストされた Mise 呼び出しは失敗となります。各タスクの結果、動機、進捗、証拠、適用可否を assets/use-case-contract.json に記録してください。

アクター、オブジェクト、アクション、状態、不変条件、バリアント、インターフェース、権限元、失敗、復旧、証拠、時間、リソース、品質、用語、除外事項をマッピングしてください。すべてのスキル本文、リファレンス、アセット、スクリプト、テスト、Mise タスク、例、評価、ポリシー、スキーマ、記録をマッピングしてください。assets/primitive-lifecycle.json と mise run primitive-lifecycle-policy で、発見から廃止までを網羅してください。各フェーズには、実際のドメインタスク、進捗、動機、証拠、および防止する失敗が必要です。

すべての公式 Mise プリミティブを、assets/mise-primitives.json と mise run mise-primitives-policy で分類してください。結果に役立つプリミティブのみを使用し、使用しないプリミティブにはそれぞれドメイン上の理由を示してください。欠落、古い情報、創作されたプリミティブ、名目上の使用はいずれも失敗となります。

すべての呼び出しタスクを説明してください。選択したパスを実行し、それ以外の各タスクについて、リクエスト固有の inapplicable の証拠を示してください。レシートを mise run invocation-policy -- <receipt> で検証してください。実行を主張する場合は、すべての実行についてコマンド出力を保存してください。出力がない場合は失敗となります。

結果に関する作業中は Mise のバージョンを固定してください。受け入れ後にのみ mise run mise-primitives-update を実行して、カタログを整合させた後、mise run ci を再実行し、バージョンとダイジェストを記録してください。パッケージマネージャーまたは更新の失敗は BLOCKED です。置き換えを強制しないでください。

運用の分岐

• 新規作成： mise run doctor を実行し、mise run source-corpus で所有者を再利用してから、mise run new -- --name <name> --description "<description>" --scope <user-or-project> --dest <destination> を実行します。RED、GREEN、REFACTOR の順に、タスク、グラフテスト、動作テスト、スクリプト、SKILL.md、リファレンス、アセット、例、評価を作成します。新規のスキャフォールドは、すべてのプレースホルダーのシードが置き換えられるまでブロックされた状態です。
• 更新または標準化： mise run plan-standardize -- <source> を実行し、baseline_digest を保存します。レジストリ全体にポリシーを適用する場合は、まず mise run standardize-target -- <source> --profile <profile> を書き込みなしのプランとして実行し、ドメインプロファイルとベースラインを承認してから、--apply を追加します。これらの操作では、ドメインの目的、トリガー、承認済みの動作、証拠、結果、証明、境界、禁止される結果、必須の手法が維持されます。変更するのは最小の所有者にとどめ、ベースラインと比較します。
• インポート： mise run audit-source-corpus -- <source> も実行します。コーディングエージェントのクライアントとパッケージ形式は区別してください。衝突、シンボリックリンク、不明な所有者、プラットフォーム固有の前提は拒否します。機能に関する指示は SKILL.md に、リポジトリのルールは AGENTS.md に、ホストの所有権は .agents/ に変換します。ユーザーがインプレース移行を要求しない限り、ソースは変更しません。
• バリアント： mise run variant を通じて references/scope-variants.md を読み込みます。プランを作成し、ソースとターゲットプロジェクトのコンテキストをすべて読み、別の候補を用意して、適応後の動作を検証し、そのタスクを通じて承認します。レポートと系譜には、両方のスコープ、適応内容、ソースの保持状況を記録します。明示的な更新では、記録済みのベースラインを比較し、カスタマイズとの競合を解決します。明示的なインプレース適応にも同じゲートを適用します。方向に応じて、mise run variant を通じて examples/example-variant-project.md または examples/example-variant-user.md を読み込みます。
• 検証または評価： mise run validate-target -- <path> または mise run eval-target -- <path> を実行します。承認にはスコープが必要です。変更されていないレガシースキルを調査する場合に限り、--inspect-legacy を追加します。すべての失敗を報告し、新たに保存した証拠に基づいて動作ケースを評価します。

書き込み前にスコープを決める

作成または更新するすべての出力には、metadata.scope 文字列を必ず1つだけ保存します。ユーザーのプロジェクト全体で利用する場合は user、特定のプロジェクトまたはリポジトリ向けの場合は project です。ラベルはこのメタデータ拡張から導出し、ほかのメタデータは保持します。汎用的な指示やソースレジストリの場所からスコープを決めることはできません。明示的な選択を優先し、それがなければ、更新、標準化、インポートでは有効なスコープを維持します。不足しているスコープは、用途と権威あるコンテキストから明確に判断できる場合に限り推定します。証拠が不足または矛盾している場合、該当する書き込みを行う前に、簡潔な質問を1つします。変更されていないレガシーの調査ではスコープがなくても構いませんが、無効な値、型、重複キーは常に失敗とします。生成されたチェッカーにも同じ承認ルールを適用します。スコープの解決、バリアントの適応、インテグレーションが所有する配置先の検証には、mise run resolve-scope を通じて references/scope-variants.md を読み込みます。メタデータだけでインストール、配置変更、複製、実行時の権限変更が行われることはありません。

段階的な開示

references/generation-contract.md と examples/example-help.md には mise run validate、references/resource-and-experiment-design.md には mise run improvement-policy、references/use-case-specificity.md には mise run domain-research-policy、references/writing-rules.md には mise run lint-writing、references/code-rules.md には mise run lint-code、references/eval-authoring.md と evals/ には mise run evals、references/registry.md と assets/source-shape-corpus.json には mise run source-corpus、assets/skill-template.md と examples/example-new-skill.md には mise run new を使用します。doctor の失敗後は examples/example-doctor.md を読み込み、プレースホルダーの証拠は mise run lint-placeholders を通じて、検証例は対応するターゲットタスクを通じて読み込みます。実装は Mise の内部に隠されています。

証明の出力

コマンドが成功すると、終了コード 0 を返します。mise run validate、mise run lint-writing、mise run lint-code、mise run lint-placeholders、mise run evals、mise run improvement-policy は問題が 0 件であることを報告します。mise run doctor は "ready": true と "mode": "mise" を報告します。構造上の合格が証明するのは、その契約だけです。行動評価とドメインレビューも引き続き必要です。

作業の完了条件

完了とは、新たに実行した mise run domain-research-policy、mise run use-case-policy、mise run mise-primitives-policy、mise run primitive-lifecycle-policy、mise run task-graph-policy、mise run decision-policy、mise run ci、mise run validate-target、mise run eval-target、および mise run invocation-policy -- <receipt> の証拠が合格し、タスク固有の動作、ソースから主張へのレビュー、ドメイン置換攻撃、ドメイン用語削除攻撃が合格し、ログが動機、証拠、タスク、ステップ、アセット、評価に至る結果を追跡でき、汎用的な側面、プリミティブ、ライフサイクルの段階、Mise の処置、タスク、プレースホルダー、ソースの衝突、ホスト限定の前提、適用可能なタスクのスキップ、または証明されていない完了の主張が残っていないことを意味します。

任意の最終改善実験

必須作業の受け入れ後にのみ実行してください。新しいベースライン、評価器、フィクスチャ、環境、時間予算、反復回数、および適用可能なリソース指標を固定します。名前を付けた1つの次元を、その最小の所有単位で変更します。mise run improvement-policy を実行し、続いて所有する Mise タスクを通じてユースケース実験を行います。内容ダイジェストと保護対象の次元の結果を記録した、外部の採用、破棄、またはクラッシュの台帳を保管します。名前を付けた次元が大幅に改善し、保護対象の次元に後退がない場合にのみ、候補を保持します。それ以外の場合は、最後に受け入れられたバージョンに戻し、そのダイジェストを検証します。ユーザーの完了条件で必要とされない限り、終わりのないループを開始しないでください。