---
name: ironbee-issue-track
description: Work an issue-tracker ticket — read it, verify the code changes against its acceptance criteria, and report the outcome + captured evidence back to the ticket. Also handles read-only intake (`read:<ref>`), report-only (`report:<ref>`), and ad-hoc integration operations (search / create bug / transition / comment). Use when the user types /ironbee-issue-track or asks to work an integration ticket.
---

# IronBee Track

You (the main agent) drive the integration tools DIRECTLY — **run this skill INLINE, in THIS
conversation; never delegate it to a sub-agent via `Task`** (a sub-agent runs as a separate
session, so its integration calls and the attribution harvest land elsewhere and register nothing).
Integration operations are NOT a verification cycle: integration calls open no cycle, gate nothing, and
count as no cycle's evidence. **The provider section(s) at the bottom are your tool map** —
which tools implement read / search / report, the issue-ref shape, and search guidance.

## Provider (optional leading first word)

The arguments may begin with a provider name (__IRONBEE_INTEGRATION_PROVIDERS__, case-insensitive) — a first-class
selector separate from the ref, valid for every mode (including ref-less ad-hoc). If the FIRST word
is one of those, that's the provider: use ONLY its section's tools and drop the word from the rest.
Otherwise decide from the provider sections present in THIS file: exactly ONE → use it; MULTIPLE →
**ask the user which provider** before proceeding. Echo the chosen provider in your reply
(`linear ENG-123 — <summary>`).

## Mode (dispatch on the arguments)

- **`read:<ref>`** → intake only (below). STOP after the digest.
- **`report:<ref>`** → report-only (below). It reports the LAST verification of this session;
  none ran → say "nothing to report — verify first". NEVER re-verify just to report (a re-run
  might not reproduce the verified state).
- **A bare `<ref>`** (issue key like `PROJ-123`, or a noun phrase naming a ticket) → the FULL
  LOOP: read → verify (the /ironbee-verify flow, using the ticket's acceptance criteria as the
  scenario; an optional `scenario:<name> [args:{...}]` tail applies verbatim) → report.
- **An imperative integration instruction** ("create a bug for …", "find my open QA tickets") →
  ad-hoc: the single matching integration operation.

## Resolving `<ref>`

Exact key (the provider section's ref shape) → use directly. Free text → the provider's SEARCH
tool (see its search guidance). 0 matches → say so; 1 → proceed (echo `KEY — summary`); N → ask
the user which one.

## read — ticket intake

Read the key with the provider's READ tool; digest: summary, status, type, acceptance criteria
(verbatim), key constraints, attachment names. No writes.

## report — post the verification outcome

1. Recover this cycle's evidence: `echo '{}' | ironbee hook verification-artifacts` (session_id from the
   session context if the environment doesn't resolve it) — prints
   `{"verification_id", "paths", "timeline_link"}`: the last verdict-closed cycle's captured
   artifacts + a console deep-link to the run. `{"error": …}` → nothing to report; say so and stop
   (the error still carries a `timeline_link`).
2. Post with the provider's REPORT tool: the key, the verdict `outcome` (pass/fail — the tool
   badges it), a `summary` describing WHAT was verified + issues (**don't restate pass/fail** in
   the body — the badge covers it), the `paths` as artifacts, AND the `timeline_link` appended as
   a Markdown link (renders clickable): `🔗 [View in IronBee](<timeline_link>)`. Write tools unavailable → show the composed report instead.

## Write gating

A provider's evidence/outcome/report tools exist only when the project enables integration writes.
When a write tool is missing, do the read part and say writes are disabled — never fake an
outcome.

<!--IRONBEE:INTEGRATIONS-->
<!--/IRONBEE:INTEGRATIONS-->