Linear mit Ottermind nutzen: Von der Ticketliste zu klaren nächsten Schritten

Beziehe deine Linear-Tickets in ein Gespräch darüber ein, was als Nächstes passieren muss. Wenn der Linear-Skill in Ottermind eingerichtet ist, kann dein Agent zugängliche Tickets und Kommentare lesen, eine Besprechung vorbereiten und Folgeschritte anhand des bereits dokumentierten Teamkontexts entwerfen. Nach der Freigabe können unterstützte Schreiboperationen diese Arbeit zurück nach Linear übertragen.

Das hilft, wenn die Details bereits im Ticketsystem stehen, ihre Zusammenhänge aber noch fehlen. Welches Ticket braucht eine Entscheidung? Beschreiben zwei Kundenmeldungen denselben Fehler? Welche Informationen würden das nächste Ticket so weit vervollständigen, dass ein Entwickler damit arbeiten kann?

Die folgende Anleitung verwendet ein fiktives Release mit einem Problem bei Einladungslinks. Ticket-IDs, Ausgangsfakten und Beispielergebnisse dienen der Veranschaulichung; sie stammen nicht aus einem Test mit einem verbundenen Workspace.

Verbinde das Team, mit dem du arbeiten möchtest

Nutze den von byungkyu veröffentlichten Linear-API-Skill. Dieser Skill eines Drittanbieters stellt die Verbindung über Maton her und benötigt eine Maton-Authentifizierung sowie eine aktive OAuth-Verbindung zu Linear. Die Verbindung bestimmt, auf welchen Workspace und welche Ressourcen der Agent zugreifen kann.

Aktiviere den Skill und ordne ihn dem Agenten zu, der deine Aufgabe übernimmt. Folge dabei dem Ottermind-Leitfaden zu Skills. Wenn du mehrere Linear-Verbindungen hast, gib den gewünschten Workspace an. Bitte den Agenten zunächst, ein bekanntes Ticket zu lesen und dessen ID und Titel zu bestätigen.

Der Skill dokumentiert die Suche, Abfragen, das Erstellen und Aktualisieren von Tickets sowie Kommentare. Schreiboperationen erfordern eine ausdrückliche Freigabe; manche Vorgänge benötigen möglicherweise zusätzliche Berechtigungsbereiche. Die Einrichtungsanleitung des Skills beschreibt diese Anforderungen.

Richte die Besprechung auf die anstehenden Teamentscheidungen aus

Angenommen, dein Team bereitet ein Release vor und drei Tickets erwähnen Einladungslinks. Eines ist bereits zugewiesen, ein anderes enthält einen neuen Kommentar mit einer Rückfrage, und im dritten steht eine Kundenmeldung zu einem noch nicht reproduzierten Problem.

Das Board zeigt dir, wo die Tickets stehen. Für die Vorbereitung der Besprechung musst du verstehen, welche Fakten gemeinsam betrachtet werden sollten. Bitte den Agenten, Beschreibungen und relevante Kommentare zu lesen und daraus eine kurze Tagesordnung mit Links zu den Belegen zusammenzustellen.

Erstelle eine Tagesordnung für die Release-Besprechung von [Projekt] im Linear-Workspace von [Team].
Lies die aktiven Tickets und die Kommentare, die zum Verständnis ihres aktuellen Stands nötig sind.

Nenne für jeden Diskussionspunkt Ticket-ID, Titel, Status, zuständige Person,
das dokumentierte Problem oder die Frage sowie einen Link zum belegenden Ticket.
Gliedere die Tagesordnung in nötige Entscheidungen, fehlende Informationen und bestätigte Blockaden.
Verwende dokumentierte Fakten. Leite nicht allein aus dem Alter eines Tickets ab, dass es blockiert ist.
Gib an, was du geprüft hast und welche Einträge du nicht abrufen konntest. Bearbeite keine Tickets.

Eine gute Tagesordnung enthält genug Details, damit Teammitglieder verstehen, warum jeder Punkt aufgenommen wurde. Im fiktiven Beispiel könnte das so aussehen:

Bei dieser Anfrage soll der Agent Belege zusammentragen und Fragen formulieren. Ein fehlender Reproduktionsschritt ist eine konkrete Informationslücke. Die Aussage, das gesamte Release sei gefährdet, würde weitere Informationen erfordern.

Linear unterstützt das Filtern von Tickets nach Eigenschaften und Beziehungen. Ein bestimmtes Projekt, Team oder eine abgegrenzte Ticketmenge hält die Besprechung fokussiert und macht ihren Abdeckungsumfang leichter einschätzbar.

Die Ticketmenge einlesen: Linear-Referenz zum Filtern · GraphQL-Leitfaden von Linear

Sobald die Tagesordnung steht, bitte um eine knappere Fassung: „Gib mir einen fünfminütigen Einstieg für die Besprechung. Beginne mit der Entscheidung zu den Einladungen und stelle Informationsanfragen danach vor.“ Die ausführliche Belegtabelle bleibt verfügbar, falls jemand ein Detail nachprüfen möchte.

Vergleiche ähnliche Meldungen, ohne ihre Unterschiede einzuebnen

Die Aussage „Der Einladungslink funktioniert nicht“ kann verschiedene Fehler beschreiben. Eine Person hat vielleicht einen abgelaufenen Link geöffnet. Eine andere ist möglicherweise im falschen Konto angemeldet. Eine dritte sieht nach dem Annehmen einer gültigen Einladung einen Fehler.

Suche vor dem Erstellen eines neuen Tickets nach möglichen Übereinstimmungen. Bitte anschließend um einen Vergleich der Beschreibungen, Bedingungen und erwarteten Verhaltensweisen. So wird aus einer groben Stichwortübereinstimmung eine überprüfbare Hypothese darüber, welche Meldungen zusammengehören könnten.

Suche in den Tickets von [Team] nach Einladungslinks, die ablaufen oder sich nicht öffnen lassen.
Lies die relevanten Ticketbeschreibungen und Kommentare.

Vergleiche das gemeldete Verhalten, die Reproduktionsbedingungen, den betroffenen Kontext
und das erwartete Ergebnis. Füge in jeder Zeile die Ticket-ID und den Quellenlink hinzu.
Schlage Paare vor, die als mögliche Duplikate geprüft werden sollten, und begründe jeden Vorschlag.
Halte unsichere Treffer getrennt. Schließe, vereine oder ändere keine Tickets.

Hier ist ein kurzes Beispiel für den gewünschten Vergleich. Diese IDs und Meldungen sind fiktiv:

DEMO-41 und DEMO-63 kommen für eine gemeinsame Diskussion infrage. Damit ist noch nicht belegt, dass sie dieselbe Ursache haben. DEMO-58 erwähnt ebenfalls Einladungen, doch die Reproduktionsbedingung deutet auf eine andere Fragestellung hin.

Eine hilfreiche Anschlussfrage lautet: „Welche Belege würden zeigen, ob DEMO-41 und DEMO-63 in einem Ticket behandelt werden sollten?“ Die Antwort könnte passende Screenshots, genaue Fehlermeldungen oder einen Vergleich der Reproduktionsschritte verlangen. Sie sollte aus den Meldungen hervorgehen und keine Diagnose erfinden.

Diese Unterscheidung ist bei der Ticketsichtung wichtig. Du möchtest doppelte Untersuchungen vermeiden und zugleich Informationen bewahren, die ein Entwickler später brauchen könnte.

Überführe das vereinbarte Verhalten in ein umsetzbares Ticket

Nehmen wir nun an, die Besprechung führt zu einer Entscheidung: Eine abgelaufene Einladung soll das Problem erklären und die Person dazu auffordern, bei einem Workspace-Administrator eine neue Einladung anzufordern. Die Entscheidung umfasst keine Änderung der Gültigkeitsregeln für Einladungen.

Diese Notizen reichen aus, um ein klar begrenztes Ticket zu entwerfen. Setze das Gespräch im selben Verlauf fort, damit die zugehörigen Meldungen und die Begründung der Entscheidung verfügbar bleiben.

Entwirf ein Linear-Ticket aus diesen freigegebenen Produktentscheidungen: [Notizen].
Verwende [Team] und [Projekt]. Verlinke die zugehörigen Meldungen, die wir gerade geprüft haben.

Nimm einen knappen Titel, beobachtetes Verhalten, erwartetes Verhalten,
enthaltene Arbeiten, ausdrücklich in den Notizen genannte Ausschlüsse und Akzeptanzkriterien auf.
Erfinde keinen Implementierungsansatz. Lass Zuständigkeit und Priorität offen,
sofern sie nicht in den Notizen festgelegt sind. Zeige vor dem Erstellen den vollständigen Entwurf.
Gib nach meiner Freigabe zur Erstellung die Ticket-ID und URL zurück.

Für die fiktive Entscheidung könnte der Entwurf Folgendes enthalten:

• Titel: Den nächsten Schritt erklären, wenn eine Einladung abgelaufen ist.
• Beobachtetes Verhalten: Der gemeldete Ablauf für abgelaufene Links endet ohne hilfreiche Möglichkeit zur Behebung.
• Erwartetes Verhalten: Erklären, dass die Einladung abgelaufen ist, und dazu auffordern, bei einem Administrator eine neue Einladung anzufordern.
• Nicht enthalten: Änderungen an den Gültigkeitsregeln für Einladungen.
• Akzeptanzprüfung: Beim Öffnen einer abgelaufenen Einladung werden die vereinbarte Erklärung und Handlungsanweisung angezeigt.

Das ist ein Schreibbeispiel und keine Behauptung, Ottermind habe ein Ticket erstellt oder getestet. Es zeigt, wie eine Entscheidung umsetzbar wird, ohne unbemerkt Anforderungen hinzuzufügen.

Prüfe das erwartete Verhalten und die Akzeptanzkriterien gemeinsam. Wenn die Notizen nicht sagen, ob die Handlungsanweisung als Schaltfläche oder als einfacher Text erscheinen soll, markiere das als offene Frage. Eine präzise Frage jetzt ist hilfreicher als ein erfundenes Designdetail im Ticket.

Der ausgewählte Skill unterstützt das Erstellen von Tickets und das Hinzufügen von Kommentaren. Bitte nach der Freigabe der konkreten Schreiboperation um den Link zum entstandenen Ticket. Gehört die Entscheidung zu einem bestehenden Ticket, bereite dort einen gezielten Kommentar vor, statt einen weiteren Ort für die Nachverfolgung derselben Arbeit zu schaffen.

Verknüpfe den nächsten Schritt mit der ursprünglichen Meldung

Eine gute Sitzung kann drei zusammenhängende Ergebnisse liefern: eine Tagesordnung, einen Ticketvergleich und einen Entwurf, der die Teamentscheidung wiedergibt. Jedes Ergebnis sollte auf die Einträge verweisen, die den Anlass der Arbeit erklären.

Starte mit dem Linear-Skill und einer Ticketgruppe, die Aufmerksamkeit braucht. Die Einführung in Skills erklärt, wie diese Fähigkeit deinem Agenten bereitgestellt wird. Für den übergeordneten Arbeitsansatz behandelt der Leitfaden zum KI-Projektmanagement Besprechungen und Übergaben. Der Leitfaden zu Agenten-Workspaces zeigt, wie Kontext die Arbeit über mehrere Schritte hinweg unterstützt.