Pull Requests

Sobald ein Repository verbunden ist, beobachtet Tekk seine Pull Requests und ordnet jeden der Spec zu, die er umsetzt. Öffnest du eine Spec, siehst du den PR, der sie gerade baut – seinen Status, seinen Branch und seine Änderungsgröße –, und wenn dieser PR gemergt wird, kann die Spec von selbst auf erledigt wechseln.

Es gibt nichts zu konfigurieren. Sobald du dein GitHub-Repository verbindest, ist alles eingerichtet; neue Pull Requests verknüpfen sich ab dann von selbst.

Wie ein PR mit einer Spec verknüpft wird

Ein Pull Request verknüpft sich mit einer Spec, indem er ihre Kennung referenziert – den Code TEK-123, der auf jeder Karte steht. Es gibt drei Arten, sie zu referenzieren, und sie bewirken Unterschiedliches:

• Erwähnung – die Kennung steht irgendwo im Branch-Namen, im Titel oder in der Beschreibung des PRs (zum Beispiel „baut auf TEK-123 auf“). Eine Erwähnung verknüpft den PR mit der Spec, sodass er dort auftaucht. Mehr bewirkt sie nicht.
• Beitragende Referenz – ein beitragendes Schlüsselwort direkt vor der Kennung (Part of TEK-123, Refs TEK-123, Contributes to TEK-123) in Titel oder Beschreibung. Der PR wird als Teil der Arbeit an der Spec verknüpft, und ein Merge schließt die Spec nie. Nimm sie für einen PR, der ein Stück einer größeren Spec erledigt.
• Schließende Referenz – ein schließendes Schlüsselwort direkt vor der Kennung (Closes TEK-123, Fixes TEK-123, Resolves TEK-123) in Titel oder Beschreibung. Eine schließende Referenz ist das einzige Signal, das den Status der Spec beim Merge des PRs ändern darf.

Ein Branch-Name ist immer nur eine Erwähnung: Ein PR von fix/tek-107-… verknüpft sich mit TEK-107, kann sie aber nicht schließen, egal wie sein Branch heißt.

Die Trennung ist Absicht: Eine Spec zur Einordnung zu erwähnen, soll nie das Risiko bergen, sie abzuschließen. Ein PR, in dessen Beschreibung „das ist die Grundlage, auf der TEK-200 aufbaut“ steht, verknüpft sich mit TEK-200 – kann sie aber nicht schließen.

Tipp: Jede Spec hat einen Button Copy git branch name, der einen Branch wie tek-123-add-rate-limiting erzeugt. Ein PR von diesem Branch verknüpft sich von selbst mit der Spec; damit der Merge die Spec schließt, schreib trotzdem Closes TEK-123 in Titel oder Beschreibung des PRs.

Was du an der Spec siehst

Ein verknüpfter PR erscheint an der Spec, mit allem Wichtigen auf einen Blick:

• einem Status-Badge – Draft, Open, Merged oder Closed;
• Nummer und Titel des PRs, direkt mit dem Pull Request verlinkt;
• dem Branch, auf dem er liegt;
• der Änderungsgröße (+120 −34, 5 files) und der Person, die ihn erstellt hat.

Eine Spec kann mehr als einen verknüpften PR haben, und ein einzelner PR kann mit mehr als einer Spec verknüpft sein.

Ein Merge schließt die Spec – wenn die Checkliste zustimmt

Wird ein PR mit schließender Referenz gemergt, setzt Tekk die Spec auf completed – mit einer Schutzregel: Die Build-Order-Checkliste der Spec muss abgehakt sein.

• Checkliste vollständig (oder die Spec hat keine) → die Spec wechselt auf completed, und der gemergte PR wird an ihr vermerkt.
• Checkliste hat noch offene Punkte → die Spec bleibt in Arbeit, und Tekk vermerkt den Merge und den Stand der Checkliste (zum Beispiel „3/7 Punkte“). Tekk markiert die Spec nicht als erledigt, solange ihre eigenen Akzeptanzkriterien etwas anderes sagen. Hakst du den letzten Punkt später ab, wird die Spec mit diesem Haken abgeschlossen.

Genau darum geht es bei diesem Feature: Fertig heißt fertig. Ein Merge ist eine Tatsache, deshalb handelt Tekk ohne Nachfrage – schließt aber keine Spec ab, deren Checkliste widerspricht. Wenn ein Merge eine Spec sauber schließen soll, hake die Punkte vor dem Merge ab.

Mehrere Specs in einem PR schließen

Wiederhole das Schlüsselwort vor jeder Kennung:

Closes TEK-62, Closes TEK-66

Das entspricht GitHubs eigener Grammatik. Eine bloße Kennung nach einem Komma – Closes TEK-62, TEK-66 – erwähnt die zweite Spec nur; geschlossen wird sie nicht.

Eine Spec über ihren Code lesen

Weil eine Spec jetzt ihre Pull Requests mitführt, erkennst du beim Öffnen, ob ihr Status vertrauenswürdig ist – nicht nur, was im Statusfeld steht. Ist eine Spec noch als in Arbeit markiert, obwohl ihr schließender PR vor Tagen gemergt wurde, wird diese Lücke angezeigt, damit weder du noch ein Agent, der über den MCP-Server arbeitet, auf Basis eines veralteten Status handelt. Wenn du Tekk mit deinem Coding-Agent verbindest, läuft dieser Realitätscheck bei jedem Lesezugriff mit, und die Übersicht deines Boards markiert Specs, deren Status hinter dem Code zurückliegt.

Das Ergebnis ist ein engerer Feedback-Loop zwischen Board und Repository: Eine Spec zeigt, womit sie tatsächlich ausgeliefert wurde, und sie schließt sich selbst, wenn die Arbeit wirklich gemergt ist.