We write about the tools in Anyshift's ecosystem: the CLIs and platforms that Annie integrates with. This one is about acli, Atlassian's command-line interface for Jira. It's the third in a series with Annie meets pup and Annie meets gcx.

The problem

A developer opens a PR that modifies validate_session() in shared/auth/session.py. Three services in production import it: checkout-service, notification-worker, and inventory-sync. Their teams (payments, notifications, catalog) should know now, not a sprint later when something breaks in staging.

  PR #1923  (shared/auth/session.py)
       │
       ├─→ checkout-service       →  payments
       ├─→ notification-worker    →  notifications
       └─→ inventory-sync         →  catalog

The information existed at PR time: which services consume the change, which teams own them, who reviewed the last similar change. Jira is the right system of record for the follow-up work. The production context that determines where that work should land usually lives outside Jira, in code, deploys, and infrastructure state.

That is the partnership shape: Atlassian records the work; Anyshift explains where the work should go.

Introducing annie do, with Atlassian's acli

annie do turns a single PR into one Jira epic plus one ticket per affected team: a heads-up that the team's service is impacted by the change. Each ticket lands on the right team's board, assigned to the engineer most likely to be the right reviewer.

What Annie adds before acli runs

The information that determines where each ticket should land lives outside Atlassian: in code, deploys, Terraform state, and live cloud. The Anyshift graph pulls it together so acli can write the right tickets on the right boards.

annie do is the planning surface. It reads the Anyshift context (which services consume the change, who owns them, who reviewed the last similar one), writes the runbook, and stops.

acli is the execution surface. It owns Jira auth, project keys, assignees, and the work-item commands (create, bulk-create, link). Annie hands the runbook over; acli is the one that touches Jira.

Here's annie-cli's output for one PR. The graph findings come first; the acli steps follow.

Color-highlighted YAML impact excerpt for annie do. It keeps the original PR, changed file, consumers, routing evidence, skipped services, and existing advisory chain, with YAML keys in yellow, service names in cyan, values in green, and comments in muted blue.

annie-cli then renders that into the JSON shape acli's create-bulk expects. One child looks like:

Color-highlighted JSON payload for acli create-bulk. It shows one child advisory issue for PAY, with a readable summary, Jira Task type, ADF description body, labels including pr-1923, parentIssueId pointing back to the ENG-1 epic id, and the routed assignee account id.

The Anyshift graph already knows which services consume the change and which team owns each one. acli writes the tickets.

The handoff

Diagram of the handoff between annie do and acli. Left card on a beige background with an ANYSHIFT cyan pill: annie do reads the Anyshift graph, writes the runbook, never touches Jira. Middle: a runbook.yaml document with terracotta arrows pointing in from the left and out to the right. Right card with an ATLASSIAN navy pill: acli owns Jira auth, project keys, assignees, and work-item commands; never touches the graph. Footer caption: the runbook on disk is the contract between them.

The handoff is just a file boundary. Annie returns one JSON object: the parent epic, plus for each affected service its team, assignee, evidence chain, and link back to the PR. annie-cli renders that into a runbook with exact Jira payloads and exact acli commands. acli does the Jira writes with the operator's Atlassian credentials.

The last step is the linking pass. It reads the parent epic key, loops over each child ticket key, and asks acli to create one Jira Relates link per child:

Simplified flow showing Anyshift mapping PR 1923 to impacted services and teams, Annie writing Jira keys into a runbook, and acli creating linked Jira work: ENG-1 as the parent epic with PAY-1, NOTIF-1, and CAT-1 as child advisory tickets.

annie-cli writes that. acli runs it with its own credentials. The full runbook has six steps in this same shape, one per phase of the handoff.

Before annie do runs, the affected teams' Jira boards have no tickets for this PR yet. The Anyshift graph already knows which services are impacted; Jira just has no signal.

Jira filtered to the four demo projects (Engineering, Payments, Notifications, Catalog). Main pane reads "There's nothing matching your search". The Space filter dropdown is open, showing all four projects checked.

Before: the impacted services are known to the Anyshift graph; no Jira tickets exist yet.

After one approval, an epic appears in ENG with three tickets linked under it. Each ticket lands on the right team's board, with the assignee already filled in from the Anyshift graph.

Jira filtered to the same four projects. Four rows now visible: ENG-1 (Cross-team change advisories for anyshift-backend#1923, assigned to roxane fischer), PAY-1 (advisory affecting checkout-service, assigned to roxane fischer), NOTIF-1 (advisory affecting notification-worker, Unassigned), CAT-1 (advisory affecting inventory-sync, Unassigned). All four labeled pr-1923, all in Backlog.

After: one epic, three tickets, on the right boards. PAY has its routed assignee; the others fall back to project default.

Where it is going

acli is the third vendor CLI Annie hands off to. Same shape across all of them: read the Anyshift graph, render a runbook, hand it to the CLI that owns the writes.

The verbs we'd run next on the same shape:

  • Continuous ticket sync as the Anyshift graph changes. A service moves to a new team and the open ticket gets reassigned. A code path gets renamed and the affected tickets get an updated link. A blast radius grows and the priority moves with it.
  • Dedup against open work. Before filing a new ticket, annie do searches Jira for any already referencing the same module. If one exists, evidence is appended as a comment instead of a fresh duplicate landing on the team's board.
  • Stale-ticket cleanup. The graph knows when a code path is deprecated or a service is decommissioned. annie do scans its open tickets and closes the ones whose underlying issue has resolved, with a comment explaining why.