scenario-task-tracking

name: scenario-task-trackingdescription: "Use when a Scenario billed call is refused with task-id-required, when a project attributes Creative Units to tasks of the team's task tracker, when the user asks which task their generations are billed to, or when the user moves on to other work on such a project. Keywords: task_id, task tracker, task attribution, project tasks, cost attribution, time tracking, production tracking, enterprise."license: MIT

Scenario Task Tracking

Overview

Some Enterprise projects attribute every Creative Units charge to a task of the team's own task tracker. On those projects, a billed call without task_id is refused with task-id-required, and nothing is charged. The server stores no task: the agent carries the chosen task_id from call to call. The job is to bill each piece of work to the task the user means, while asking as rarely as that allows. Core loop and scope rules: see the scenario skill. If a sibling skill named here is missing from your available skills, load it with skill_get (Scenario MCP) or ask the user to install it (https://github.com/scenario-labs/skills#install); unattended, proceed from tool schemas and flag the gap.

Quick reference

The tools that take task_id are the ones that offer dry_run: model_run, workflow_run, train, prompt_spark, asset_analyze, asset_caption, asset_describe, asset_detect, and asset_quality_gate_run. task_id sits beside dry_run: at top level on a direct call, inside parameters when the tool runs through scenario_tool_execute_write. project_tasks_list is catalog-only: run it through scenario_tool_execute_read.

The id comes from the user, never from you

The API checks only the id's format (1 to 256 printable ASCII characters), never that the task exists or belongs to the project. Any string passes and bills that work to it.

• Use only an id the user picked from the project's task list or typed themselves.
• Never invent one, never guess from the task names, never reuse an example or placeholder id.
• Never pick for the user, even when one task looks like the obvious match: suggest it, then ask.
• A task the user named in an earlier conversation is a suggestion only. Tasks open and close, so confirm it before the first billed call.

When to ask again

Ask once per piece of work, not once per call and not once per conversation.

• Same work: more variations, a retry, an upscale or an edit of the same asset, the next step of the same pipeline. Keep the task_id, ask nothing.
• Other work: a new subject, a new deliverable, a different stage of production, or the user saying they are moving on ("now the environment", "next, the trailer"). Ask one short question before the first billed call of it: keep the current task or pick another.
• Another project or team: each project has its own task list, so a task belongs to one project, even when the same id appears in another project's list. Drop the task_id there; the first billed call either goes through (the project enforces nothing) or is refused with the list.
• In doubt, ask. A question costs the user a second; a charge on the wrong task costs a correction in their tracker.
• Unattended: nobody answers a question. After a refusal, retry only with an id the request states for this work and project, and only inside a budget or count it also states. Otherwise stop the billed steps, and report the project and the dry_run price.

Word the switch question so a one-word answer works: name the current task and offer the list.

Worked example

The user asks for three concept sheets of a dragon on a project that enforces task ids.

1. recommend picks the member (stop on no_match), then model_schema_get. A dry_run of the payload then quotes the price with no task_id.
2. model_run without task_id comes back refused: Task id required, with the project's tasks inline (ART-12 "Dragon concept", ART-14 "Castle key art", ...).
3. Ask: "This project bills generations to a task. Which one is this for? ART-12 Dragon concept looks like the match." The user answers ART-12.
4. Retry the same model_run with task_id="ART-12", then jobs_wait until no pending_job_ids remain: it takes no task_id.
5. Pass ART-12 on the two remaining sheets without asking again. The user then asks for an upscale of the one they chose: same work, so pass ART-12 there too.
6. The user says "now let's do the castle". Before the first billed call: "Still on ART-12 Dragon concept, or switch to ART-14 Castle key art?" The user picks ART-14; carry it from there.

Common mistakes

• Filling task_id with something plausible to get past the refusal: it passes and bills the wrong task.
• Asking before every billed call: once per piece of work is the contract.
• Carrying a task_id into another project or team, where the same id means nothing.
• Retrying the refused call unchanged: only a task_id clears the refusal.
• Asking for a task on a project that refused nothing: no task_id is needed until a billed call is refused. A task the user names unprompted is still passed.
• Saving a task id to memory as a standing default: tasks change, so confirm it each session.