Review a Mantic question set batch before you create it

This job governs setup and cost, not interpretation. The question is "what exactly are we about to commit to, and is it what the user meant?" It is not "what do the forecasts say?" (that belongs to the briefing job). A batch that is created with the wrong mode, too many runs or a bad title template cannot be cheaply undone, so the review is the main work.

1. Establish what already exists

Before drafting anything, check for an existing batch the user may be referring to, using get_question_set. If they name one, read its progress. Creating a second batch of the same questions duplicates forecasts and their cost, so ask whether they want to extend or inspect the existing one instead.

Confirm the account in use. Forecasts visible through MCP are the ones the signed-in Mantic account can see. If the user expects a different account or workspace, stop and resolve that first. Switching the active account or workspace needs the user's explicit yes, and you do not switch silently.

2. Build the drafts and check each one

Drafts are the individual questions the batch will forecast. Build them from the user's list or from search_questions results, and make sure each one is:

• Resolvable and specific. A question with a vague end state will produce forecasts nobody can judge. Ask the user to tighten any question that has no clear outcome.
• Not a duplicate of another draft or an existing forecast. Check with search_questions and list_forecasts before committing.
• Inside the window. A question that resolves before the batch's window_end yields no useful later runs.

Show the drafts to the user as a numbered list before any tool call that creates anything.

3. Choose standard or Scout mode with a deliberate reason

• Standard batch: one forecast per question at creation, with no further runs scheduled. Use it for a one-off snapshot.
• Scout batch: repeated forecasts tracking each question over time, with runs_per_question forecasts each, the first at creation and the rest spread evenly until window_end. Use it only when the user wants movement over time.

If the user asks for "tracking" or "updates" but accepts a snapshot, recommend standard mode and say why. Mode is hard to justify changing after the fact, so make the choice explicit.

4. Compute the commitment, not just the draft count

The total run commitment is the number that matters. For a Scout batch:

total runs = number of drafts × runs_per_question

The commitment must fall within 100 to 10,000 runs in total. Check it before proposing anything:

• Below 100: the batch is rejected or too small to be useful; raise runs_per_question or add drafts.
• Above 10,000: reduce either value, or split the batch into two.

Spell out the arithmetic in your review, for example "12 drafts × 40 runs = 480 runs". For repeat runs, confirm that window_end is in the future. A past or near-immediate end date collapses the schedule into one run and makes the commitment misleading.

5. Title template and variables

When there are several drafts that differ only by one or two parts (a country, a company, a date), use a title template with placeholders plus matching variables, rather than typing each title. Check that:

• Every placeholder has a value in every variable row.
• Every filled title is unique and still reads as a question.
• No row has a blank or repeated value, which would produce twin titles that are hard to tell apart later.

Read back two or three filled titles to the user so they can see the result before creation.

6. Present the review and wait

Present one review block (see Output) covering mode, drafts, template, runs per question, total commitment and window_end. Then ask for an explicit yes. Creating the batch with create_question_set is a state-changing action: wait for the user's explicit yes, and only create exactly the batch that was reviewed. If the user changes anything, re-present the review rather than creating with the edit applied silently.

7. Report progress on an existing batch

For an existing batch, use the read tools to report state rather than re-creating anything:

• get_question_set for overall progress.
• get_question_set_questions for completed forecasts, one per question.
• get_question_set_runs for every Scout run and its result, when the user wants run-level detail.

Report how many forecasts are complete against the total, and whether runs are still scheduled. Keep the list short: give the counts first and offer the detail on request.

Common patterns and traps

• Confusing runs with questions. "40 runs per question" across 12 questions is 480 runs, not 40. Always state the total.
• Scout chosen by default. Scout costs far more runs than a standard batch. If the user did not ask for tracking over time, default to standard and offer Scout as the alternative.
• Stale window. A window_end already in the past, or one set by habit a year ago, makes repeat runs fail to spread out. Check it against today.
• Template collisions. Two variable rows that fill to the same title look fine in the draft list but create confusing duplicates. Compare the filled titles directly.
• Batch already running. Re-creating a batch that exists doubles cost. Check get_question_set first.
• Commitment hidden in a summary. A reviewer who sees "10 questions" may not see that Scout multiplies it. Put the total in the first line of the review.
• Assuming the forecasts are right. This job checks setup. Whether a forecast is credible belongs elsewhere, so do not comment on the predicted numbers here.

Output

Batch: <title or template> | mode: <standard | Scout>
Drafts (<n>):
1. <title>
2. <title>
...
Runs per question: <n or "n/a, standard">
Total run commitment: <total runs> (<drafts> × <runs>; allowed 100 to 10,000)
Window end: <date, in the future: yes/no>
Duplicates or issues: <none, or list>
Existing batch with these questions: <none, or name and progress>
Awaiting: the user's explicit yes before creation.
Not checked: <anything you could not verify, e.g. resolution criteria>

For progress reports:

Batch: <name> | <complete> of <total> forecasts complete
Scheduled runs remaining: <n, or "none">
Questions with no completed forecast: <list or "none">

Rules

• Do not create, change or extend a batch without the user's explicit yes on the exact reviewed batch; wait for the user's explicit yes every time, even if they asked earlier in the conversation.
• Do not switch the active account or workspace without the user's explicit yes.
• Never state a total run commitment you have not calculated and shown.
• Do not create a batch to "test" the setup. Every creation costs runs.
• Do not interpret or recommend against a forecast's content in this job; hand that to the briefing job.
• Do not invent product behaviour (how Scout schedules, what a window does to billing) beyond what the connector's documentation says. If unsure, say "check the Mantic docs" rather than guessing.

Done when

• The total run commitment is calculated, shown and within 100 to 10,000, or the user has been told why it is not.
• Every draft and filled title has been reviewed, and the user has given an explicit yes before any creation.
• For a progress report, the counts are stated and any gap is named.
• The "not checked" line is honest.