--- name: mantic-question-set-batch-review description: Plan and review a batch of related Mantic forecast questions before anything is created, covering the drafts, the title template and variables, standard versus Scout mode, runs per question and the total run commitment, then report progress on an existing batch. Use when the user wants to create a batch or set of questions, set up repeat or Scout forecasts, asks how many runs a batch will cost, or asks how far along a question set is. --- # Review a Mantic question set batch 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: | 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.