timebox

タイムボックス

成果

指定された制限時間内に、ユーザーが依頼した作業全体と、その決定的な検証を完了します。これは厳格な受け入れ条件であり、しばらく部分的に進めるよう求めるものではありません。期限前に完了し、検証され、タイムスタンプが記録された作業だけが合格となります。

使用するタイミング

ユーザーがタスクと所要時間または正確な期限を指定して /timebox を呼び出した場合に使用します。例：/timebox 10 minutes fix and test the parser、/timebox by 16:00 EDT verify the release artifact。

タスクまたは制限時間が指定されていない場合は、作業を開始する前に簡潔な質問を1つします。曖昧な日付や時刻は always-current-datetime を使って確認します。制限時間は正の値で、絶対的な期限を算出できるほど正確である必要があります。

必須の構成

作業を受け入れる前に、次の手順を実行します。

1. always-current-datetime を読み込み、新しいローカル時刻の基準を取得します。その captured_at の値をタイムボックスの開始時刻とします。ツールを使って、この基準時刻から絶対的な期限を算出します。暗算はしません。
2. starting-point を読み込みます。完全な成果、決定的な証拠、範囲、権限、不明点、禁止される結果を定義します。
3. outcome-bounded-work を読み込みます。完全な成果と証拠は固定したまま、より迅速で安全な方法を選べるようにします。
4. logic-audit を読み込みます。範囲の矛盾、実現不可能な期限、証拠の欠落、期限内に収まらない依存関係がないか確認します。

必須のスキルを読み込めない場合は、contract-unavailable: <skill-name> を返して停止します。現在の指示を、記憶している内容で置き換えてはいけません。

受け入れ判定

次の条件をすべて満たす場合にのみ、タイムボックスを受け入れます。

• タスク、受け入れ基準、期限が明確であること。
• 必要な権限、入力情報、認証情報、依存関係、人による判断がすべてすでに利用可能であるか、期限内に収まることが実証されていること。
• 選択した方法が、依頼された作業の全範囲、安全規則、決定的な検証を維持していること。
• 各ツール呼び出し、コマンド、再試行、外部の待ち時間に、明確な最大所要時間が設定されていること。
• 決定的な確認、結果の検査、完了タイムスタンプの記録を含む、保護された検証用の時間が確保されていること。
• 制限時間付きの実行計画と検証用の時間を合わせて、期限前に収まること。

いずれかの条件を満たさない場合は、作業を開始しません。TIMEBOX_NOT_STARTED を返し、満たされていない受け入れ条件を示したうえで、より長い制限時間または明示的な範囲変更を求めます。上限のない見積もりを根拠に、確実な完了を約束してはいけません。

実行契約

1. 最初の作業に着手する前に、開始時刻、絶対的な期限、作業打ち切り時刻、検証用の時間、成果、証拠を記録します。
2. 期限から逆算します。作業打ち切り時刻は、期限から保護された検証用の時間を差し引いた時刻です。
3. 受け入れられた要件をすべて維持できる、最速の方法を選びます。範囲、品質、安全性、証拠を黙って削ってはいけません。
4. 各アクションの前に、最大所要時間と残りの作業時間を比較します。作業打ち切り時刻を超える可能性があるアクションは開始しません。
5. コマンドとツールのタイムアウトは、該当する打ち切り時刻を超えないよう設定します。終わりのない再試行、待機、ポーリング、バックグラウンド作業は避けます。
6. サブエージェント、キューに入れられたジョブ、承認、再起動、リモート処理は、最終的な証拠がタイムボックス内に得られるまで未完了として扱います。
7. 必須の手順が期限内に収まらなくなった場合、契約全体を維持できるときに限り、より迅速な方法を使用します。それ以外は停止し、直ちに TIMEBOX_FAILED を報告します。
8. 作業打ち切り時刻までに、またはそれより早く、決定的な検証を開始します。実装作業によって、保護された検証用の時間を消費してはいけません。
9. 決定的な確認がすべて合格した後に、完了タイムスタンプを記録します。再試行、確認、ツールの遅延、失敗を理由に期限をリセットまたは延長してはいけません。

完了判定

以下のすべてが証明された場合に限り、TIMEBOX_PASS を返します。

• 受け入れられた成果全体が完了している。
• 決定的な検証チェックがすべて合格している。
• 最終的な証拠が絶対期限より前に得られている。
• 完了時刻が期限以前である。
• 必須の作業が、キューに残っている、委任されている、承認待ちである、または未検証の状態にない。

実行を開始したものの、期限までにいずれかの条件を証明できない場合は、TIMEBOX_FAILED を返します。完了した作業、実施した検証、残作業、副作用、正確な時刻の判定を述べ、部分的な進捗を完了として説明しないでください。

受付条件を満たさない場合は、TIMEBOX_NOT_STARTED を返します。要求された保証を制限時間内に実現できない場合、これが正しい結果です。

失敗時の安全ルール

• テストや調査が残っているのに、主要な編集が終わったことを理由に成功を主張しないでください。
• キューへの投入、ディスパッチ、ツールからの応答、バックグラウンドプロセスを、完了した作業として数えないでください。
• 合格を作り出すために、検証を省略したり、弱めたり、期限後に回したりしないでください。
• 期限超過を隠さないでください。遅れて成功しても、その呼び出しは TIMEBOX_FAILED です。
• 停止時は安全な中間状態を保ち、その状態を報告してください。時間に間に合わせるために、取り消せない操作や機密性の高い操作を急がないでください。
• 新しいタスク、または変更されたタスクでは、受付判定は無効になります。ユーザーが新たに指定した制限時間を基に、新しいタイムボックスを開始してください。

出力

受付時には、開始時刻、期限、成果全体、決定的な検証、検証用に確保した時間を示してください。終了時には、TIMEBOX_PASS、TIMEBOX_FAILED、TIMEBOX_NOT_STARTED のいずれかを先頭に置き、完了時刻、期限、根拠、残作業を示してください。

段階的な情報開示

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

PD-101：evals/cases.json は、客観的な負荷ケースと受け入れ基準を管理します。このスキルのテスト、レビュー、変更を行う前に読み込んでください。このファイルは実行時の動作を管理し、評価の管理元へのリンクを含みます。

検証

• 時刻の基準は、現在の always-current-datetime の指示に基づいていた。
• 受付判定では、実装だけでなくタスク全体と検証も対象としていた。
• 作業開始前に、絶対期限と検証用の予備時間を算出していた。
• 各アクションは、割り当てられた締切より前に終わるよう制限されていた。
• PASS には、制限時間内の完了、決定的な検証、最終的な証拠が必要である。
• 部分的、キューに残っている、期限後、または未検証の作業は合格とみなせない。

リソース

• 受付時または終了時のフィールドを記録する前に、タイムボックスの記録を読んでください。
• 機械可読なフィールドテンプレートとして assets/timebox-record.json を使用してください。
• 受付済み、却下済み、合格時の応答形式については、examples/ を使用してください。
• このスキルのディレクトリから mise run ci を実行し、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つに保ちます。

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

Mise は、繰り返し可能な仕組み、実行順序、レシート、チェックを担います。モデルは、コードでは提供できない解釈、因果関係の判断、創造的な作業、直接的な知覚を担います。権限の不足、古いエビデンス、またはゲートの失敗があれば停止します。