Ziel: Häufige Betriebsabläufe als eigene Befehle (API-Wrapper), damit Mensch/KI nicht jedes Mal Pfade, JQL und JSON manuell zusammensetzen muss.

Leitlinien

  • atlassian … http … bleibt als Escape-Hatch, nicht als Normalweg.
  • Jeder Betrieb ist klein, eindeutig und hat klare Eingaben/Outputs.
  • Output bevorzugt maschinenlesbar (JSON/TSV) und stabil.
  • Security-Policy bleibt unverändert (Allowlist, Tool-Owner, keine Secrets beim Aufrufer).

Heuristik

  • Wenn ein http-Aufruf mehrfach gebraucht wird: als Betrieb standardisieren.
  • Wenn ein Betrieb eine Fehlerklasse eliminiert (Encoding, Pagination, Feldtypen): priorisieren.

Beispiele

  • atlassian jira search jql <JQL>
  • atlassian jira subtasks list --parent J01-9
  • atlassian jira subtasks reorder --parent J01-9 --move J01-12 --after J01-11
  • atlassian jira issue transition --issue J01-12 --to done

Katalog (Start)

Der Katalog wächst nur entlang realer Nutzung (kein Vollabdeckungs-Ziel).

  • Search: JQL suchen (Pagination + Felder).
  • Subtasks: listen/reorder (Rank), Schritt-Nr pflegen.
  • Workflow: Transition in definierte Ziel-Status.
  • Erstellung: Subtask anlegen mit Standardfeldern.

Zwischenschritt: CLI-Cache

Wenn API-Betriebe noch Backlog sind, kann ein CLI-Cache als Zwischenschritt Zeit sparen: ein kleiner Katalog aus benannten Rezepten (Befehlsschablonen + Beispielparameter + erwartete Felder), damit Mensch/KI ähnliche Befehle schnell bauen kann.

Ziel des Caches: Ein KI-Agent soll schnell ein funktionierendes Beispiel finden und das Muster wiederverwenden, statt das Befehlsschema/Endpoint-Schema iterativ zu erraten.

Artefakt-Typen (minimal):

  • Rezept (Schema): benannter Use-Case + kopierbarer Beispielbefehl (mit Platzhaltern) + erwartete Felder/Output-Form + typische Fehlermodi.
  • Snapshot (Beleg): optionaler, gekürzter Ergebnis-Ausschnitt + Zeitpunkt, um spätere Prüfungen und Reproduktion zu ermöglichen.

Skill statt Cache (optional): Ein Codex-Skill kann die Arbeitsweise definieren (wann welches Rezept genutzt wird) und die Ablage der Ergebnisse steuern; die harte Policy bleibt trotzdem im atlassian-http-client.

Public-only Policy

  • Cache/Output nur für Inhalte, die als veröffentlicht/öffentlich gedacht sind.
  • Keine Secrets im Cache.

Einschränkung im atlassian-http-client

Statt Maskierung: harte Einschränkung über Allowlist/Denylist (insbesondere User-, Gruppen- und Berechtigungs-Endpunkte nicht zulassen). Maskierung bleibt optional als Zusatzschutz.