---
name: ironbee-manage-scenario
description: >
  Add, update, or delete a reusable IronBee verification scenario by delegating to the
  ironbee-scenario custom agent. Use when the user types `$ironbee-manage-scenario`. The sub-agent
  authors the script in the devtools format and saves it to the scenario store (or finds and
  updates/deletes an existing one).
---

# IronBee — Manage scenario

> **Delegate — do NOT run the scenario tools inline.** Spawn the **`ironbee-scenario` custom agent**
> via `spawn_agent` with `agent_type="ironbee-scenario"` **and `fork_turns="none"`** (the default
> `fork_turns="all"` silently drops the agent_type → a generic toolless agent). The sub-agent owns
> the devtools `ibdt_scenario-*` tools; you don't have them.

Add / update / delete a reusable verification **scenario** by delegating to the `ironbee-scenario`
custom agent. This is NOT a verification cycle — it submits no verdict and does not gate completion.

## Steps
1. **If the request points to a file path** (scenario content to save), read that file now and pass
   its **contents** into the sub-agent's prompt. If a given path doesn't resolve, stop and report
   `scenario file not found: <path>`.
2. **Spawn** `spawn_agent` with `agent_type="ironbee-scenario"` and `fork_turns="none"`, passing in
   `message`:
   > Operation: manage
   > Request: \<the user's request — content to add/update, or the target to update/delete>
   > Scope: \<`global` if the user asked, else `project`>
   > Mode: \<include `Mode: draft` ONLY if the request begins with a `draft` token (source-only, no app
   >        run) — otherwise OMIT so the sub-agent authors against the live app>
   The sub-agent decides add vs update (checks for an existing same-name scenario first), authors the
   script (single- or cross-platform) — **against the live app by default** (starts the app if needed,
   observes the real behavior, validates by running once, then cleans up — deletes any probe /
   throwaway scenarios it added and stops what it started; `draft` skips this)
   — and declares the typed `params` contract for parametric ones (defaults captured from the run)
   plus stamps metadata.
   **Delete and fuzzy-resolved update ask you to confirm** the matched scenario first — relay that
   to the user and pass their answer back. **Wait for the sub-agent in the same turn.** Block on it with `wait_agent` passing `timeout_ms: 600000` (install also sets that as the default wait). A wait that returns with no completed agent is NOT a failure — call `wait_agent` again; do not nudge a still-running agent with `send_message` and do not interrupt it. A run takes minutes.
3. **Relay** the sub-agent's summary (what it created / updated / deleted, on which platform).