TL;DR
Dein Kanban-Board ist voller Ticket-Titel, und jeder davon ist eine Karte, an die du denken und die du schreiben musstest. Tekk.coach füllt das Board für dich. Sechzehn Loops lesen, was sich in deinem Code geändert hat, und bringen Proposals; jedes, das du mit Greenlight freigibst, wird zu einer Spec mit Akzeptanzkriterien und Checkliste. Dein Coding-Agent baut sie, und der gemergte PR schiebt die Karte auf Done. Teste es drei Tage lang, ohne Setup.
[Tekk.coach testen →]
Wie Tekk.coach Kanban macht
Die meisten Kanban-Board-Tools geben dir Spalten und Karten. Tekk auch – To Do, In Progress, Done. Drei Spalten. Bewusst einfach.
Der Unterschied ist, wer die Karten schreibt. Tekk lässt sechzehn Loops auf deine Codebase los – Security, Reliability, Backend, Payments, Performance, Testing und sechs weitere. Ein Loop wacht auf, wenn sich dein Code ändert, wenn Sentry anschlägt oder wenn ein Teil seines Bereichs zu lange ungeprüft geblieben ist. Er liest, was sich geändert hat, verfolgt es bis zu allem, was es berührt, arbeitet eine Methode aus seinem Regal voller Skills ab und bringt höchstens ein Proposal. Ein Lauf, der nichts findet, hält ehrlich „nichts gefunden“ fest, statt Arbeit zu erfinden.
Du gibst das Proposal mit Greenlight frei oder lehnst es mit Begründung ab. Freigegeben landet es als Spec in To Do: was gebaut wird, warum, die Akzeptanzkriterien, die sagen, wann es fertig ist, und eine Checkliste mit der Reihenfolge der Umsetzung. Abgelehnt bringt die Begründung den Loops bei, was für dein Projekt Rauschen ist. Wenn du weißt, was du willst, kannst du trotzdem selbst eine Spec schreiben – dasselbe Board, dieselben Akzeptanzkriterien. Das ist Spec-driven Development, angewandt auf jede Karte auf deinem Board.
Dann bewegt sich die Karte von selbst. Dein Coding-Agent – Claude Code, Codex, Cursor – liest die Spec über den Tekk-MCP-Server und setzt sie auf In Progress, wenn er anfängt. Wenn der Pull Request mit Closes TEK-123 gemergt und die Checkliste erledigt ist, wandert die Karte auf Done. Dieser Merge ist die nächste Änderung, die die Loops lesen.
Die wichtigsten Vorteile
Karten, die du nicht schreiben musstest. Loops bemerken die Arbeit – den fehlenden Ownership-Check, den Retry, der doppelt abbucht, die Query ohne Index – und bringen sie dir als Proposal. Du verbringst deine Zeit mit Entscheiden, nicht mit Formulieren.
Specs, die deine Codebase kennen. Die Loops planen nicht im luftleeren Raum. Jeder liest die Änderung in deinem Repo und verfolgt sie bis zu allem, was sie berührt, also verweist ein Proposal auf die Dateien, um die es wirklich geht. Allgemeine Ratschläge gibt es nicht.
Keine Rituale. Kein Sprint Planning, kein Backlog Grooming, keine Konfiguration eigener Felder, keine Freigabeketten. 76 % der Teams, die Kanban nutzen, halten es für effektiver als andere Methoden. Proposal mit Greenlight freigeben, Spec bekommen.
Funktioniert mit deinen KI-Coding-Tools. Wenn du mit Claude Code, Codex oder Cursor baust, arbeiten sie über den Tekk-MCP-Server auf demselben Board: Specs auflisten, die Akzeptanzkriterien lesen, bauen und die Spec mit dem Merge schließen.
Drei Tage Testphase. Keine Mindestanzahl an Seats. Verbinde dein Repo, und die Loops legen bei deiner nächsten Änderung los.
So funktioniert’s
Verbinde dein Repo. Schalte die Loops ein, die du willst. Sie legen bei deiner nächsten Änderung los.
Ein Loop bringt ein Proposal. Wenn sich dein Code ändert, Sentry anschlägt oder ein Bereich zu lange liegen bleibt, wacht ein Loop auf, liest, was sich geändert hat, und schlägt eine Sache vor – oder hält ein ehrliches „nichts gefunden“ fest.
Mit Greenlight freigeben oder ablehnen. Freigegebene Proposals landen als Specs in To Do. Abgelehnte bringen den Loops etwas bei. Du willst etwas, das kein Loop angesprochen hat? Schreib die Spec selbst.
Eine Spec bekommen, die dein Agent schließen kann. Was gebaut wird, warum, Akzeptanzkriterien und eine Checkliste mit der Reihenfolge der Umsetzung. Die Spec gibt dir den Kontext, den übliche Kanban-Metriken wie Cycle Time und Throughput allein nicht erfassen. Für Teams mit mehreren geplanten Features hält KI-Projektplanung alles über die ganze Roadmap hinweg strukturiert.
Der Merge schließt die Karte. Dein Coding-Agent baut die Spec über MCP. Der PR mit
Closes TEK-123schiebt die Karte auf Done, sobald ihre Checkliste erledigt ist.
Für wen das ist
Solo Founder und Indie-Builder. Du kümmerst dich um Architektur, Produkt und Entwicklung – alles in einer Person. Sonst behält niemand die Auth-Checks oder die Payment-Webhooks im Blick. Tekks Loops schon, und sie bringen dir, was sie finden, als Karten, die du mit Greenlight freigeben kannst.
Kleine Teams, die mit KI-Coding-Agents bauen. Wenn Cursor, Claude Code oder Codex zu eurem Stack gehören, kennt ihr das Problem: Der Agent schreibt Code, aber jemand muss trotzdem entscheiden, was er als Nächstes baut. Tekks Loops füllen diese Warteschlange, und jede Karte ist eine Spec, die euer Agent über MCP aufgreifen und mit einem Merge schließen kann.
Devs, die mit Jira durch sind. Du brauchst kein Sprint-Velocity-Tracking, keine eigenen Workflows, keine Freigabeketten. 56 % der agilen Teams nutzen bereits Kanban – gerade weil es diesen Prozess-Overhead weglässt. Du musst wissen, was du baust, warum es wichtig ist und welche Dateien du anfasst. Tekk gibt dir das ohne den Overhead.
Nichts für: Enterprise-Teams, die Prozess-Governance, eigene Feldkonfigurationen, Freigabe-Workflows oder Features für die Zusammenarbeit wie Kommentare und Benachrichtigungen brauchen. Tekk ist ein Board, das sich aus deinem Code selbst füllt, keine Projektmanagement-Suite. Teams, die neben ihrem Board ein tieferes Queue-Management brauchen, sollten sich auch das Backlog-Management-Tool ansehen, um zu priorisieren, was als Nächstes geplant wird.
Was ist Kanban Board Software?
Kanban ist eine visuelle Workflow-Methode, Ende der 1940er-Jahre bei Toyota erfunden. Taiichi Ohno, damals Leiter einer Maschinenwerkstatt, untersuchte, wie Supermärkte ihre Regale auffüllten, und übertrug dieses Pull-Prinzip auf ein kartenbasiertes System, mit dem sich Arbeit durch ihre Phasen tracken lässt – dieselbe Logik, die hinter jedem Kanban-Board-Tool von heute steckt.
In der Softwareentwicklung besteht ein Kanban-Board aus Spalten (meist To Do, In Progress, Done) und Karten (einzelnen Aufgaben). Teams schieben Karten von links nach rechts, während die Arbeit voranschreitet. Die zentrale Praxis: WIP-Limits (Work in Progress). Begrenze, wie viele Karten gleichzeitig in einer Spalte sein dürfen, und du zwingst dazu, Arbeit abzuschließen, bevor neue beginnt. Teams, die WIP-Limits durchsetzen, verbessern ihre Lieferzeiten um bis zu 37 %. Diese einfache Beschränkung reduziert Kontextwechsel und macht Engpässe sichtbar.
Kanban-Software reicht von kinderleicht (Trello) bis Enterprise-tauglich (Jira, Businessmap). Die meisten Tools haben inzwischen KI-Features: automatische Priorisierung, Engpass-Erkennung, Auslastungsausgleich, Board-Generierung aus Dokumenten. Was fast keines davon tut: Karten aus deiner tatsächlichen Codebase aufs Board bringen und sie wieder runternehmen, wenn die Arbeit gemergt ist. Tekk.coach wurde für genau diese Lücke gebaut – Loops, die die Arbeit vorschlagen, auf einem Kanban-Board, das dir nicht im Weg steht.

