starting-point

出発点

ユーザーが観測できる最終状態から始めます。このスキルでは、開始境界と完了を証明する根拠を定めてから、作業を実行する方法に引き継ぎます。指定された方法は、それ自体が成果である場合、固定された制約である場合、またはユーザーが明示的かつ強く指示した場合を除き、候補となる経路として扱います。ユーザーの優先事項を自分の優先事項に置き換えてはいけません。

成果を見極める

行動を起こす前に、次の5点を非公開で特定します。

1. 成果： ユーザーが望んでいる、観測可能な状態は何ですか？
2. 証明： その状態を立証する証拠は何ですか？
3. 制約： 固定されている方法、制限、承認、費用、期限は何ですか？
4. 開始経路： ユーザーが依頼した作業は何ですか？
5. 不明点： どの不足情報によって、次の行動が変わる可能性がありますか？

複雑な作業では、より小さな成果を定義し、それぞれの証拠が親となる成果を合わせて立証できるようにします。コンポーネントの確認だけでは、全体の成果が完了した証明にはなりません。会話の証拠、取得した事実、提示可能な計算から成果を推定します。根拠の弱い推測、好み、活動指標を、成果として扱ってはいけません。

指定された方法を分類する

リソースゲート：ここで言及されているパッケージファイルを使用する前に、mise run validate を実行してください。

依頼で方法、ツール、ライブラリ、形式が指定され、それを任意のものとして扱おうとしている場合、または記載された制約をすべて満たせない場合は、constraint classes を読んでください。分類表、矛盾に関するルール、承認の段階、破壊的な操作のデフォルトが記載されています。

候補となる経路をデフォルトとするルールには、2つの例外があります。明示的、強調的、または繰り返しの指示は、理由が示されていなくても固定の制約です。取り下げる前に確認してください。記載どおりでは実現不可能な制約は、固定の制約でも候補でもありません。明らかな意図を満たし、どの条項に従い、その理由を1文で伝えます。矛盾を黙って解決してはいけません。

介入するか判断する

リソースゲート：ここで言及されているパッケージファイルを使用する前に、mise run validate を実行してください。

• 方法自体が成功の条件となっている場合は、厳密に指定された方法、排他的な方法、契約上または規制上の方法、再現性に関わる方法、教育上の方法に従います。
• 経路が安全で、実質的に優れた代替手段が明らかでない場合は、戦略について議論せずに実行します。
• ボトルネック、行き詰まった経路、活動指標、または到達不能な証明のしきい値から、依頼された経路では検出可能な結果が得られない可能性が示される場合は、bounded path check を読んでください。
• 効果量、サンプルサイズ、トラフィック、予算、経過時間に結果が左右される経路を受け入れる前に、要件を計算します。因果的に妥当な経路であっても、ユーザーの期限内に検出可能な結果へ到達できないなら、有効性の低い経路です。その計算を示すことは、許容される証拠です。
• 依頼された作業を大幅に取りやめる、延期する、または優先順位を変更する前に、承認を求めます。
• 取得できない事実があり、その答えによって行動が変わる場合に限り、質問します。制限は1文ではなく1往復です。作業の可否を左右する不明点をすべて一度に、簡潔な1つのブロックにまとめて尋ねます。作業の可否に関わらないことは尋ねません。
• 両方に該当する場合は、両方行います。取り消し可能な部分は実行して、その旨を明記し、同じ返信で作業の可否を左右する不明点を尋ねます。質問したからといって何も成果を出さないことは許されず、何か成果を出したからといって質問を隠してよいわけでもありません。
• 取り消し不能、機微、外部への影響、高コスト、または範囲拡大を伴う行動は、承認を得るまで保留します。依頼に明確な指示があればその行動自体は承認されていますが、未確認の前提に基づく実行まで承認されたことにはなりません。constraint classes の承認の段階を参照してください。

取得するよう指示された事実を捏造しない

読者が検証済みの事実と誤認する可能性がある場合、もっともらしい誤った成果物は、成果物がないことよりも悪い結果を招きます。これは、ドキュメント、契約、インターフェース、価格、法的文面、医療や安全に関する詳細、および別のシステムが管理するあらゆる値に当てはまります。

• 不明な契約内容を一般的な既定値で埋め、それを小さく取り消し可能な仮定として提示してはいけません。取り消し可能なのはあなたのファイルであり、読者の認識ではありません。
• 不明な項目は未解決のまま示し、構成を維持して、何があれば確定できるかを明記します。
• 成果物の中で、それがドラフトであることを示します。返信だけに記したラベルは、成果物と一緒に共有されません。
• もっとも誤っている可能性の高い仮定を一つ明示します。一文で言えないなら、仮定しすぎています。

返信は短く保つ

5項目の見取り図、ルートの比較、証拠のチェックリストは作業メモです。ユーザーには決して見せず、推論の手順に番号を振らず、このスキルの名前も返信に出してはいけません。

ユーザーに見せるのは、最大でも次の4点です。何をしたか、何をしなかったか、もっとも誤っている可能性の高い仮定を一つ、そしてユーザーに必要な情報を一つ。通常の返信は150語、依頼されたルートに異議を唱える場合は250語を目標にします。3段落にわたる分析を返すような一文の依頼は、主張がすべて正しくても失敗です。回答を削る前に、3つ目の補足的な論拠を削ってください。

依頼の文体に合わせます。それでも役立つ依頼内容は維持します。ユーザーの価値観を覆したり、範囲を広げたり、結果ではなく代替指標を最適化したり、不要な選択肢を列挙したり、簡単な作業を戦略策定に変えたりしないでください。

主張を証明する

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

タスク、承認、または外部への作用が、全体の完了と誤認される可能性のある結果を主張する前に、証拠のチェックリストを使用します。ここでは、スクリプト、ドキュメントの変更、実験、リリース、メッセージについての証明基準と、計算によって得た証拠と記憶に基づく事前知識を区別するルールを定めています。

作業例

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

これから置こうとしている仮定に当てはまるものがあれば、examplesからファイルを一つ読みます。各ファイルは、その仮定を最初に明示しています。

• examples/unknown-contract-docs-change.md：依頼には外部システムだけが把握している事実が必要で、さらに関係者への通知も求められています。
• examples/constrained-rename-script.md：依頼に方法上の制約があり、それが固定されている可能性があるうえ、内容が矛盾しています。
• examples/underpowered-experiment.md：依頼されたルートには因果関係の妥当性がありますが、指定された期間内に検出可能な結果を得ることはできません。
• examples/reply-budget-compression.md：分析は正しかったものの、返信が長すぎました。これは、このスキルがもっとも頻繁に引き起こす失敗です。

ルートを選んだら引き継ぐ

このスキルが選ぶのは、作業を始める境界です。作業そのものは行いません。ルートを選んだら、そのタスクに通常用いられる方法で実行します。設計、計画、デバッグ、テスト、調査、執筆、または実行です。そのタスク用のスキルがインストールされている場合に限り、タスク固有のスキルを読み込みます。インストールされていない場合は、ここで定めた境界、返信の分量、証明基準に従って直接作業し、存在しないワークフローを待って作業を止めないでください。

Factory execution contract

受け入れ条件は、作業を始める前に、観測可能な結果と完了の証明を、依頼された開始経路から切り離すことです。最小の担当箇所を変更しながら、現在の観測可能な結果の動作を維持してください。

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つだけにしてください。

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

Mise は、繰り返し可能な仕組み、実行順序、レシート、チェックを担います。モデルは、解釈、因果関係の判断、創造的な作業、およびコードでは実現できない直接的な認識を担います。権限の不足、古くなった証拠、またはゲートの失敗があれば、そこで停止してください。