---
name: ironbee-issue-track
description: >
  Work an issue-tracker ticket via the ironbee-issue-tracker custom agent. Use when the user types
  `$ironbee-issue-track`. A bare <ref> runs the FULL LOOP — read the ticket, verify against its
  acceptance criteria via the ironbee-verifier, report the outcome + evidence back to the
  ticket. `read:<ref>` only reads; `report:<ref>` only reports the LAST verification (never
  re-verifies); a free-form integration instruction (search / create bug / transition / comment)
  runs as-is.
---

# IronBee Track

> **Delegate — do NOT drive the integration tools inline.** Run this command by spawning the
> **`ironbee-issue-tracker` custom agent** via `spawn_agent` with `agent_type="ironbee-issue-tracker"` **and
> `fork_turns="none"`** (the default `fork_turns="all"` silently drops the agent_type), and — in
> the full loop — the **`ironbee-verifier`** agent the same way for the verification step.
> **Await every spawned agent in THIS turn; strictly sequential** (read → verify → report). 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. The verify step takes minutes.

## Provider (optional leading first word)

The text may begin with an issue-tracker provider name (__IRONBEE_INTEGRATION_PROVIDERS__, case-insensitive) — a
first-class selector separate from the ref, so it works for every mode. If the FIRST word is one of
those, **consume it**: pass a `Provider: <id>` line (lowercased) to EVERY `ironbee-issue-tracker`
spawn below, and treat the REST as the normal `[read:|report:]<ref-or-instruction>`. Otherwise pass
no `Provider:` line — the sub-agent uses the only configured provider, or (SEVERAL configured) hands
back a provider-selection question; ask the user and re-delegate with `Provider: <id>`.

## Mode (dispatch on the text provided alongside `$ironbee-issue-track`)

- **`read:<ref>`** → intake only: spawn the integration with `Operation: read` + the `<ref>`; relay
  its digest. STOP — no verifier, no report.
- **`report:<ref>`** → report-only: spawn the integration with `Operation: report` + the `<ref>`.
  It reports the LAST verification of this session; none ran → it answers "nothing to report —
  verify first" (relay that; suggest the full loop). It NEVER re-verifies.
- **A bare `<ref>`** (issue key like `PROJ-123`, or a short noun phrase naming a ticket) → the
  **FULL LOOP** below. An optional trailing `scenario:<name|description> [args:{...}]` tail is
  relayed to the VERIFIER step verbatim (the `$ironbee-verify` grammar).
- **An imperative integration instruction** ("create a bug for …", "find my open QA tickets") →
  **ad-hoc**: spawn the integration with the instruction as-is; relay the result.
- Ambiguous bare form → ask the user.

`<ref>` may be an exact key or free text — the integration resolves it. When it returns MULTIPLE
candidates, present them, ask the user which, and re-delegate with the chosen key.

## Full loop — read, verify, report

1. **Read** — spawn `ironbee-issue-tracker`:
   > Operation: read
   > Provider: \<the selected provider id, when one was given\>
   > Ref: \<the `<ref>`\>
   Keep its digest — you need the resolved key + the **acceptance criteria**.
2. **Verify** — spawn `ironbee-verifier` (exactly as `$ironbee-verify` does), passing the
   ticket's acceptance criteria as the scenario intent (+ the `Saved scenario:` / `args:` lines
   when a `scenario:` tail was given). It runs the cycle and submits the verdict in this shared
   session.
3. **Report** — spawn `ironbee-issue-tracker` again:
   > Operation: report
   > Provider: \<the same provider id as step 1, when one was given\>
   > Ref: \<the resolved key\>
   > Verdict: \<the verifier's verdict summary — status, what was verified, issues\>
   The integration recovers this cycle's captured evidence itself (`ironbee hook verification-artifacts`) and
   posts the report; when integration writes are disabled it returns the composed report — show it.
4. **Relay** a compact wrap-up: ticket, verdict, what was reported/attached.

A FAIL verdict does not abort the loop — report it honestly, then tell the user what failed
(suggest `$ironbee-verify fix` for the repair loop; re-report afterwards with `report:<key>`).