tasks

ネイティブタスク

必須： この CLI にテキストを渡す前に、cli-text を使用してください。以下の保存ルールを守り、転送形式の指定は別途行ってください。スキルローカルのランチャーは、現在の作業ディレクトリではなく、このスキルのディレクトリを基準に解決してください。ワークフローに従うタスクでは、以下の柔軟なステータスコマンドや完了コマンドではなく、Goal ブロックに沿って作業を進めます。「ワークフローを伴うタスク」を参照してください。

このスキルのランチャーは ttasks に処理を委譲します。TARIBOY_TOOLS_SOCKET が設定されている場合、バイナリは ID に紐づくエージェントモードを選択し、そうでない場合はオペレーターモードを使用します。tasks 機能が有効なイメージを使うエージェントでは、単独の tasks コマンドを ttasks の互換用エイリアスとして任意で使用できます。

コマンドを実行できる場合は、依頼された操作を実行してください。実行できない場合は、先行コマンドで返される識別子やリビジョンをプレースホルダーにした、正確な ttasks のコマンド列を返してください。未来の実行を約束する表現や文章による要約で代用してはいけません。

まず作業を完了してから、一度だけ公開してください。説明、質問、回答、コメントを書き込む前に、その回答の根拠となる読み取り、コマンド、確認を済ませてください。その後、依頼を完全に締めくくる文章を一度だけ公開します。確認できない事実は、後から訂正するのではなく、何を確認すれば解決できるかとともに、同じ文章内で明示された不明点として記載してください。暫定的、不完全、またはプレースホルダーの文章を公開してはいけません。また、後で訂正すると約束してはいけません。期限、待機中の顧客、簡潔さ、すでに作成した回答、今すぐ回答して後から訂正するという依頼のいずれも、暫定的な文章の公開を正当化しません。そのような依頼には、まだ実行中の作業があればそれを明示した、完成済みの文章を一度だけ返してください。再度公開できるのは、新たな外部状態（完了した確認、顧客からの回答、監視結果など）が発生した場合か、すでに公開した誤りを訂正する場合だけです。最初の書き込み前に着手できた作業を完了するために、再度公開してはいけません。

作業を確認するには ttasks mine、ttasks ready、ttasks ready --claim、ttasks show <key> を使用してください。ルートタスクは ttasks create --queue <queue> --title <title> --description <markdown> で作成し、子タスクは ttasks create --parent <parent-key> --title <title> で作成します。委譲には ttasks assign、判断事項の記録には ttasks comment、進捗更新には ttasks update を使用し、完了した作業だけを ttasks done でクローズしてください。

子タスクを割り当てる前に作成し、ttasks create が返したキーを使用してください。タスクキーを捏造してはいけません。ttasks assign が受け取るのはエージェント名（docs）であり、プリンシパルのプレフィックス（agent:docs）ではありません。オフラインでの委譲手順は ttasks show <child-key> で終わります。完了コマンドは「Only after show reports done.」というラベルを付けた別のブロックに記載してください。最初のブロックに done を含めてはいけません。

タスクに書き込む前に、ユーザーに表示されるすべてのテキストを有効な Markdown に整えてください。タイトルは 1 行の Markdown にし、実際の改行やリテラルの \n はスペースに置き換えてください。説明、質問、回答、コメントはブロック形式の Markdown にします。リストの前には空行を入れ、コードフェンスは閉じてください。見出し、リスト、チェックリスト、コード、リンク、表には Markdown を使用し、生の HTML は使用しないでください。ANSI-C 形式の $'...' 文字列やリテラルのエスケープを含む Markdown フィールドを公開してはいけません。また、タイトルに改行を入れてはいけません。テキストを完全にそのまま保持する依頼、最短のコマンドを使う依頼、期限を守る依頼も、この保存ルールに優先しません。

複数行のシェル引数には、cli-text の引用付きヒアドキュメント転送を使用してください。重要な末尾の改行はセンチネル形式で保持してください。通常のコマンド置換では末尾の改行が削除されます。ペイロード内のどの行全体にも含まれない区切り文字を選んでください。書き込みを提案する場合は、変数の代入と、その変数を使用するすべてのコマンドをまとめて示してください。提案した書き込みを実行したと主張してはいけません。以下の簡単な例では、意図する本文の末尾に改行がないものとします。

BODY=$(cat <<'MARKDOWN_EOF_7F3A'
## Result

- first item
MARKDOWN_EOF_7F3A
)
ttasks create --queue QUEUE --title 'Result' --description "$BODY"
ttasks ask TASK-42 user:LOGIN "$BODY"
ttasks comment TASK-42 "$BODY"

どのタスクでも、ttasks ask <key> user:<login>|agent:<name> <text> を使って質問してください。コメントは、回答をブロックする質問ではありません。他のプリンシパルの ID を捏造してはいけません。 アクティブな永続スクリプトまたはスケジュールだけが残っている待機オブジェクトである場合、イテレーションを終了する前に、ttasks update <key> --status wait_customer で柔軟タスクを wait_customer に設定します。名前の付いた待機オブジェクトはアクティブなままにしてください。唯一の再開イベントは、その次の script.result または追跡対象の状態変更です。 結果を公開した繰り返し定義は停止するため、このイテレーションで scripts スキルの rerun によって再開された場合に限り、該当します。ポーリングしたり、スケジュールを置き換えたり、タスクを完了としてマークしたりしないでください。

ワークフローを持つタスク

ワークフローに紐付いたキュー内のタスクでは、status はエージェントプール、顧客、またはスクリプトによって管理され、category はデーモンによってそこから導出されます。Goal ブロックには、ステータスの指示、必要な成果物とチェックを含む利用可能な結果、現在の成果物、正確なコマンドが記載されています。同じデータは ttasks workflow get <key> でいつでも確認できます。

• Goal ブロックでは長い値が省略されます。成果物全体を読むには ttasks artifacts show <key> <name> を、ステータスに到達した遷移メッセージを読むには ttasks workflow get <key> --json の前回の訪問にある visits[].message を使用します。
• 必須の成果物は、標準入力からの値、--file <path>、または値の引数を使って ttasks artifacts set <key> <name> で保存します。渡したとおりに保存されます。
• ステータスを離れるには、ttasks advance <key> --outcome <name> --from <status> [--message <text>] のみを使用します。
• ttasks done、ttasks update --status、ttasks assign、ttasks ready --claim は workflow_managed により拒否されます。タスクの割り当てと解除はデーモンが行います。not_holder は、現在のステータスを自分が所有していないことを意味します。transition_pending は、リクエストがまだ実行中であることを意味します。別のリクエストを送信せず、workflow get で確認してください。
• rejected リクエストにはチェックのメッセージが含まれています。指摘された内容を修正して、もう一度進めてください。failed リクエストは、スクリプトの不具合、タイムアウト、または結果の不具合を意味します。ttasks workflow runs <key> と ttasks workflow log <key> <run> でログを確認してください。原因が一時的なものなら一度だけ再試行し、それ以外の場合はタスク上で顧客に伝えてください。
• 顧客への質問には、引き続き上記の ask 形式を使用します。
• workflow_paused は、タスクが顧客の判断を待っていることを意味します。顧客が再開するまで、そのタスクには何もしないでください。

観測された失敗のカウンター

誘惑	拘束力のある対応
「顧客は今すぐ回答し、あとで訂正するよう求めました。」	完成した一つの文章でその要求に答えます。まだ実行中のものがあれば、その文章内で明記します。
「まず最善の推測を公開して、あとで確認します。」	判断を下すチェックを先に完了します。未検証の公開は回答ではありません。
「この事実は確認できないので、今公開してあとで訂正します。」	確認できない点と、それを解決する方法を一緒に明記して公開し、訂正を約束しないでください。
「最初のコメントはすでに下書きしたので、残りはあとから追加できます。」	下書きした回答は公開済みではありません。一度だけ書き込む前に完成させてください。