mcpField
O
outcome-bounded-work

outcome-bounded-work

github.com/srinitudeエージェントワークフロー2555 回インストール1 週間前に更新
リポジトリ

outcome-bounded-work について

outcome-bounded-workは、進行中の依頼や指示文書を整理し、必須の結果・証拠と変更可能な手段を分けるエージェントスキルです。手段の選択が重要な作業に向き、変更には証拠と承認を求めます。

主な機能

  1. 01結果・証拠・境界・禁止事項の定義
  2. 02必須手段と候補経路の区別
  3. 03証拠と承認に基づく経路変更
  4. 04会話と文書監査のモード
  5. 05検証項目と引き継ぎの提示

活用シーン

  1. 01目標と実装案が混在する依頼の整理
  2. 02ポリシーや計画の要件と手順の監査
  3. 03行き詰まった方法を安全に置き換えられるかの判断

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/srinitude/skills --skill outcome-bounded-work

インストール後、Claude Code で/outcome-bounded-workを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

mise.toml
.github/workflows/
ci.yml
assets/
contract-template.md
decision-records.json
improvement-contract.json
invocation-receipt-template.json
mise-primitives-catalog.json
mise-primitives.json
primitive-lifecycle.json
use-case-contract.json
evals/
cases.json
contract.md
evals.json
manifest.json
rubric.md
source-lineage.json
source-mapping.json
speed-budgets.json
trigger-cases.json
trigger-queries.json
examples/
artifact-audit.md
conversation-candidate-path.md
simple-request-bypass.md
references/
decisions.md
eval-cases.json
generation-contract.md
resource-and-experiment-design.md
use-case-specificity.md
scripts/
agentic_request_contract.py
check_code_rules.py

詳細

成果の範囲を定めた作業

成果

必要な結果、証拠、安全性を固定したまま、置き換え可能な実装上の選択肢は柔軟に保ちつつ、進行中の会話の方向性を定めるか、指示を含む成果物を監査します。

使用のきっかけと範囲

会話、プロンプト、タスク、仕様、計画、ポリシー、スキルに、真の要件と、それを満たすための一つの方法が混在している可能性がある場合に使用します。

重要な方法の選択がない単純な依頼には使用しないでください。厳密に指定された方法、ユーザーの明示的な要件、または優先度の高いルールを弱めないでください。求められる成果がスキルパッケージの簡素化に限られる場合は、simplify-skill を使用してください。

最初の作業に取りかかる前に、ホストのスキル読み込み機能を通じて starting-point を読み込んでください。このスキルは、成果、証拠、制約、開始経路、未確定事項に関する非公開のマップと、経路を変更するための介入ゲートを管理します。このスキルは、計画や実行を引き継ぐことなく、そのマップと元の指示を、確認可能な契約にまとめます。

進行中の依頼には会話モードを使用してください。既存の指示を含むソースの調査をユーザーが求めた場合に限り、成果物監査モードを使用してください。

契約の項目

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

  • 成果: 観察可能な最終状態。
  • 証拠: PASS または BLOCKED を判定する証拠。
  • 境界: 範囲、権限、リソース、プライバシー、コスト、可逆性。
  • 禁止される成果: 決して受け入れてはならない状態。
  • 必須の方法: 権限、ユーザーの意図、または成果物によって固定された方法。
  • 候補となる経路: 成果を目指すための、置き換え可能な方法。
  • 適応ルール: 候補となる経路を置き換えるために必要な証拠と承認。
  • 未確定事項: 契約をなお変更し得る事実や判断。

永続的な契約成果物が必要な場合は、assets/contract-template.md を使用してください。記入する前に、インストール済みのスキルからコピーしてください。パッケージに含まれるアセットは編集しないでください。

分類ルール

元の指示を削除または置き換えた場合に何が変わるかに基づいて分類してください。

  • 求められる最終状態が変わる場合、それは 成果の不変条件 です。
  • 受け入れ可否の判断に必要な証拠が失われる場合、それは 証拠要件 です。
  • 範囲、権限、安全性、プライバシー、コスト、または可逆性が変わる場合、それは 境界 です。
  • 受け入れられない状態を示している場合、それは 禁止される成果 です。
  • 方法が厳密に指定されている、排他的である、契約上または規制上求められている、再現性や教育に関わる、ユーザーが明示的に要求している、あるいは方法自体が成果物である場合、それは 必須の方法 です。
  • すべての不変条件、証拠要件、境界、禁止される成果を維持できる別の方法がある場合、それは 候補となる経路 です。
  • 利用できる証拠では、要件と手順を区別できない場合、それは 未解決 です。

推測だけで命令形の指示を格下げしないでください。元の記述、権限、文脈、取得可能な証拠を用いてください。それでも区別によって作業が大きく変わる場合は、簡潔な質問を一つしてください。

会話モード

  1. starting-point の非公開の成果マップを作成します。
  2. 要件を作り出すことなく、ユーザーの言葉から暫定的な契約を推定します。
  3. 最小限で有用な契約または具体例を、早い段階でユーザーに提示します。
  4. 観察された事実、変更可能な仮定、未確定事項にラベルを付けます。
  5. 未回答の質問は、同時に一つまでにします。
  6. 発見を最初からやり直すのではなく、ユーザーの反応をもとに同じ契約を更新します。
  7. 契約が受け入れられた場合、またはユーザーが実行を求めた場合は、該当する担当者に引き継ぎます。

成果物監査モード

  1. 変更を提案する前に、ソース全体を読みます。
  2. 重要な指示すべてに、ソース内の順序に沿って安定したソース ID を付与します。
  3. 指示のテキストまたは参照箇所、権限、分類、提案する処置、および理由を記録します。
  4. 不変条件、証拠に関する義務、境界、禁止される結果、および必須の方法を、意味や強さを損なわずに保持します。
  5. 証拠によって候補の手順として扱えると裏付けられない限り、手順を必須のままにします。
  6. 分類台帳と、変更を最小限に抑えた契約案を返します。
  7. ユーザーから依頼され、正当な編集担当者が読み込まれている場合を除き、ソースを変更しません。

適応のゲート

候補の手順を置き換えるのは、次の条件を満たす場合に限ります。

  • 代替案が、受け入れ済みの契約フィールドをすべて保持している。
  • 重要な利点があること、または現在の手順が妨げられていることを証拠が示している。
  • 代替案が、現在の権限と副作用の制限の範囲内にある。
  • 作業の中止、延期、または優先順位の変更について、ユーザーの承認を得ている。

これらの条件が立証されていない場合は、現在の手順を維持するか、経路を未解決として示します。より優れたコンポーネントがあることは、全体としてより良い結果が得られる証明にはなりません。

出力

最初に契約を示します。監査モードでは、その後に分類台帳を続けます。受け入れ済みの契約、提案する経路、実行の証拠の違いが分かるようにします。

次のアクションがテキストの修正である場合は、meaning-preserving-rewrite を読み込みます。スキルのみの簡略化は simplify-skill に、計画のみの作業は plan に、継続的な目標のパッケージ化は goal-prompt に、実行は該当するドメイン担当者に割り当てます。

どの実例を読むべきですか?

リソースのゲート:ここで示すパッケージファイルを使用する前に、mise run validate を実行します。

進行中のリクエストで成果、境界、提案する実装が示されている場合は、examples/conversation-candidate-path.md を読みます。ポリシーまたは仕様に、固定された承認ルールと置き換え可能なツールが混在している可能性がある場合は、examples/artifact-audit.md を読みます。単純なリクエストに契約作業を追加する前に、examples/simple-request-bypass.md を読みます。これは、このスキルによって最も起こりやすい失敗です。

落とし穴

  • 指示は短いほど自動的に良いと考える。
  • 書き留められているという理由だけで、すべての手順を維持する。
  • 手続き的に聞こえるという理由で、安全性や証拠に関するルールの位置づけを下げる。
  • 証拠や承認なしに、ユーザーが選択した方法を置き換える。
  • 証明、制約、または禁止される結果を捏造する。
  • 契約や書き換え案を、実行の証拠として扱う。
  • ユーザーが変更を承認する前に、監査対象のソースを編集する。

段階的な情報開示

実行時の動作をテスト、レビュー、または変更する前に、references/eval-cases.json を読みます。パッケージ構造またはネイティブから公開向けへの系譜を変更する前に、references/generation-contract.md を読みます。有効化、動作、失敗処理、復旧、または速度を測定する場合に限り、evals/cases.json と evals/ の残りのファイルを読みます。検証動作を変更する前に mise run test を読み込み、その後 mise run ci を実行します。通常の使用では mise run test を読み込みません。

検証

  • 分類の前に、starting-point に沿って非公開の成果マップを作成しました。
  • 重要なソース指示にはすべてソース ID が1つ割り当てられ、分類が明示されています。
  • 保持された要件は、その意味、権限、強さを維持しています。
  • 緩和された手順にはすべて、維持された契約と、それを裏付ける証拠が記載されています。
  • 不明点は推測で解決せず、明示したままにしています。
  • 契約は、結果を悪化させることなく、より安全で優れた経路を受け入れられます。
  • 外部へのアクションとソースの変更は、通常のゲートによって引き続き制限されています。

ファクトリー実行契約

受け入れられる成果は、要求された成果の境界と証明のしきい値を維持しつつ、失敗した候補パスのみを置き換えることです。最小のオーナーを変更しながら、現在の成果境界の動作を維持します。

  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 は、繰り返し可能な仕組み、順序、レシート、チェックを担います。モデルは、解釈、因果判断、創造的な作業、コードでは補えない直接的な認識を担います。権限の不足、古くなった証拠、またはゲートの失敗があれば停止します。

コメント