Visuelles Feedback-Tool für Entwickler und KI-Coding-Agents
nit ist das fehlende Eingabegerät für UI-Arbeit mit KI. Alt-Klick auf das Element, Änderung in einem Satz, fertig: jede Annotation speichert Component-Tag, eindeutigen CSS-Selektor, XPath, Route und Viewport plus Screenshot. Genau genug, dass ein Coding-Agent die Stelle im Code findet, ohne dass Sie die Seite noch einmal beschreiben.
Kleine UI-Fehler in Prosa zu beschreiben, funktioniert nicht
Sie klicken durch Ihr Produkt und sehen die Kleinigkeiten: ein Badge in der falschen Farbe, ein Stern-Icon ohne Füllung, ein toter Active-State. Ein Ticket dafür anzulegen ist zu viel Aufwand. Also beschreiben Sie es dem Agent im Chat, und genau dort geht die Präzision verloren: "die dritte Kachel, nein, auf der Landingpage, die unter dem Hero".
Der Agent hat keinen Blick auf Ihren Bildschirm. Er braucht eine Referenz, die er im Code wiederfindet: welches Component, welcher Selektor, welche Route, welcher Viewport, und wie sieht die Stelle überhaupt aus. Das alles existiert im Moment des Klicks, und es verschwindet in dem Moment, in dem Sie anfangen, es in Worte zu fassen. nit greift genau dort zu.
So funktioniert es
Drei Schritte, eine Schleife: annotieren, fixen lassen, verifizieren. Reopen führt zurück in Schritt zwei, bis die Liste leer ist.
Schritt 1 - Annotieren
nit review https://staging.example.com startet ein echtes Chromium mit Annotations-Overlay und einem Panel-Fenster daneben. Alt-Klick auf das Element, Änderung eintippen, speichern. Schwer erreichbare Zustände wie Dropdowns oder Wizard-Schritte klicken Sie einfach an, nit zeichnet den Klick-Verlauf mit auf.
Schritt 2 - Agent fixen lassen
Geben Sie den Ordner nit-review/ an Ihren Coding-Agent, oder servieren Sie ihn mit nit mcp als MCP-Server. Der Agent arbeitet jeden offenen Change-Request am referenzierten Element ab und setzt ihn danach auf fixed.
Schritt 3 - Verifizieren
nit verify führt Sie durch eine Queue aller gefixten Punkte: Routen werden automatisch angesteuert, Nachher-Screenshots liegen neben den Originalen. Sie entscheiden Verified, Reopen mit einer Notiz, die der Agent liest, oder Skip.
Quickstart
nit braucht Node 20.12 oder neuer und installiert sein Chromium beim ersten nit doctor selbst.
npm install -g @spaceparrots/nit
nit doctor
nit setupnit review https://staging.example.com
nit mcp-install
nit verify Oder ohne Installation: npx @spaceparrots/nit review https://example.com
Was nit kann
Kein Dashboard, kein Projektmanagement. nit macht eine Sache: aus einem Klick eine Referenz, die ein Coding-Agent verwerten kann.
Präzise Element-Referenz
Jede Annotation speichert eine geschichtete Referenz auf das Element: Component-Tag, bei Angular zusätzlich den Klassennamen, einen zur Aufnahmezeit auf Eindeutigkeit geprüften CSS-Selektor, absoluten XPath, Elementtext und Klassen. Dazu Route, Viewport und der Klick-Verlauf, mit dem sich versteckte Zustände reproduzieren lassen.
MCP-Server für Coding-Agents
nit mcp serviert den Review-Ordner über stdio als MCP-Server, gebaut auf dem offiziellen SDK. Der Agent arbeitet mit nit_list_annotations, nit_get_annotation, nit_mark_fixed, nit_set_status, nit_set_issue_ref und nit_clear_verified, dazu Resources wie nit://review/brief.md für Sessions ohne Tool-Zugriff.
Screenshots mit Kontext
Screenshots werden als CDP-Element-Clip im Moment des Klicks aufgenommen und auf ein Mindestfenster von 480x360 um das Element erweitert. Dadurch überleben flüchtige Zustände wie ein offenes Dropdown, und der Agent bekommt das Element nicht freigestellt, sondern in seiner Umgebung.
Verifikations-Loop mit Vorher und Nachher
nit verify nimmt Nachher-Shots nach denselben Regeln auf, damit sie direkt vergleichbar sind, und führt Sie Punkt für Punkt durch die Queue. Ein Reopen speichert Ihre Begründung als statusReason, sodass der Agent in der nächsten Runde weiß, warum es nicht gereicht hat, statt zu raten.
Overlay, das jede Site verträgt
Die gesamte Overlay-UI liegt in einem isolierten Shadow DOM und fasst DOM, Styles und Scripts der Seite nicht an. Ein MutationObserver verankert die Pins nach SPA-Rerenders neu, Annotationen werden nach Viewport gefiltert, und nicht platzierbare Punkte werden mit Begründung ausgewiesen statt still verschluckt.
Mehrere Umgebungen, mehrere Reviewer
Ein Review-Ordner deckt localhost, Staging und Produktion ab, je Base-URL ein Unterordner, ein einziger MCP-Server für alle. Im Team reviewt jeder für sich, nit export, import und merge führen die Feedback-Dateien mit Autor-Zuordnung zusammen.
Für wen nit gebaut ist, und für wen nicht
nit passt, wenn
- Sie selbst entwickeln oder mit einem Coding-Agent arbeiten und ohnehin ein Terminal offen haben.
- Es um viele kleine UI-Korrekturen geht, für die ein Ticket zu schwer ist, ein Chat-Satz aber zu ungenau.
- Ihre Annotationen und Screenshots im Projektordner bleiben sollen, ohne dass Kundendaten an einen Anbieter gehen.
- Sie mehrere Umgebungen parallel reviewen und eine einzige Übergabe an den Agent behalten wollen.
nit passt nicht, wenn
- Nicht-technische Reviewer selbst annotieren sollen: nit ist eine CLI, sie braucht Node und ein installiertes Chromium. Ein Link, den man nur öffnen muss, ist es nicht.
- Sie Kommentar-Threads, Zuweisungen, Benachrichtigungen oder ein Board brauchen. nit hat kein Backend und damit auch keine geteilte Ansicht, Austausch läuft über Zip-Dateien.
- Sie einen Bug-Tracker-Ersatz suchen. nit ist für kleine, konkrete UI-Änderungen an einem Element, nicht für Features oder Fehlerberichte mit Reproduktionspfad.
- Sie viel in nativen <dialog>-Modalen arbeiten, die per showModal() geöffnet werden: die liegen im Top-Layer über allem, das nit-Popover ist von dort aus nicht anklickbar. Element im offenen Dialog picken, Dialog schließen, speichern. Overlay-basierte Dialoge wie Angular CDK oder Bootstrap sind nicht betroffen.
nit im Vergleich zu gehosteten Feedback-Tools
BugHerd, Marker.io und Userback sind für Reviewer gebaut, die keinen Code anfassen. Vercel Toolbar Comments sind für Teams gebaut, die auf Vercel deployen. nit ist für den Weg vom Klick in den Coding-Agent gebaut. Die Tabelle sagt, wo das ein Vorteil ist, und wo nicht.
| Kriterium | nit | SaaS-Feedback-Tools | Vercel Toolbar Comments |
|---|---|---|---|
| Übergabe an Coding-Agent | MCP-Server plus fix-annotations.md, der Agent schreibt den Status zurück | Kommentar liegt im Tool, Weitergabe je nach Anbieter über Integrationen oder von Hand | Kommentare am Preview-Deployment, gedacht für Menschen im Team |
| Element-Referenz | Component-Tag, geprüft eindeutiger CSS-Selektor, XPath, Elementtext, Route, Viewport, Klick-Verlauf | Screenshot und Element-Metadaten je nach Anbieter | Kommentar am Element der Preview |
| Backend oder Account nötig | nein | ja, gehostetes Backend und Account je Reviewer | ja, Vercel-Account und Projekt |
| Datenhaltung | Dateien im Projektordner, Austausch als Zip | beim Anbieter | bei Vercel |
| Vorher/Nachher-Verifikation | eingebaut über nit verify | Statuswechsel, erneute Prüfung von Hand | Kommentar auflösen |
| Nicht-technische Reviewer | schwach: CLI, Node und Chromium nötig | Stärke des Formats: nur ein Browser nötig | Link auf die Preview genügt |
| Kommentar-Threads, Zuweisung | nicht vorhanden | Kernfunktion | vorhanden im Vercel-Team-Kontext |
| Wo es läuft | jede erreichbare URL, auch localhost | Seiten mit Snippet oder Extension | Vercel-Preview-Deployments |
| Preis und Lizenz | kostenlos unter AGPL-3.0, kommerzielle Lizenz auf Anfrage | Abo, üblicherweise pro Nutzer und Monat | Teil des Vercel-Plans |
Ehrlich gesagt: Wenn Ihre Reviewer Marketing, QA oder der Kunde sind, sind die SaaS-Tools die bessere Wahl. Sie sind genau dafür gebaut, und nit ist es nicht.
Lizenz: AGPL-3.0, und eine kommerzielle Option
nit steht unter der GNU AGPL-3.0. Sie dürfen es frei nutzen, verändern und selbst hosten. Die Copyleft-Bedingungen greifen auch dann, wenn eine veränderte Version nur über das Netz bereitgestellt wird: Dann muss der Quellcode unter derselben Lizenz verfügbar sein. So kann niemand nit schließen und weiterverkaufen.
Wenn Sie nit auf eine Art einsetzen wollen, die die AGPL-3.0 nicht erlaubt, etwa eingebettet in ein geschlossenes oder kommerzielles Produkt, gibt es eine separate kommerzielle Lizenz. Schreiben Sie an [email protected], dann klären wir das direkt.
Fehlt etwas? Dann bauen Sie es ein.
Ich habe nit gebaut, um einen Arbeitsschritt zu automatisieren, der vorher von Hand lief, und um die Qualitätskontrolle nicht dem Zufall zu überlassen. Was bei mir gefehlt hat, fehlt in Ihrem Setup vielleicht auch.
nit ist Open Source, nicht nur einsehbar. Wenn ein Selektor in Ihrem Framework nicht greift, ein Befehl fehlt oder der Verifikations-Flow bei Ihnen hakt: machen Sie ein Issue auf. Wenn Sie es selbst lösen wollen, umso besser. Es gibt Issue-Vorlagen, einen Contributing-Guide und einen Code of Conduct, und ich sehe mir jeden Pull Request an.
Häufige Fragen zu nit
nit ist ein Open-Source-CLI-Tool, mit dem Sie eine Website per Klick annotieren und die Annotationen an einen KI-Coding-Agent übergeben. Statt eine UI-Änderung in Prosa zu beschreiben, klicken Sie das Element an; nit speichert Component-Tag, CSS-Selektor, XPath, Route, Viewport und einen Screenshot. Der Name kommt aus der Code-Review-Kultur, wo kleine Anmerkungen mit nit: beginnen.
Es gibt zwei Wege. Entweder Sie zeigen dem Agent den Ordner nit-review/ und sagen ihm, er soll fix-annotations.md befolgen. Oder Sie registrieren den MCP-Server einmal mit nit mcp-install; danach arbeitet der Agent direkt über die nit_-Tools und setzt jeden erledigten Punkt selbst auf fixed.
Nein. Das Ergebnis sind schlichte Dateien in einem Ordner: annotations.json, ein lesbares review.md, die Agent-Instruktion und die Screenshots. Der MCP-Server ist ein dünner stdio-Prozess über denselben Ordner. Es gibt nichts zu hosten und nichts zu registrieren.
Jeder Agent, der MCP über stdio spricht, kann sich verbinden; der Server ist auf dem offiziellen @modelcontextprotocol/sdk gebaut und meldet seine Arbeitsanweisung schon im Handshake an. Agents ohne MCP-Unterstützung bekommen denselben Vertrag über die Dateien, weil sie annotations.json direkt bearbeiten können.
nit deckt den technischen Teil dieser Tools ab: Element anklicken, Änderung notieren, Screenshot mit Kontext, Status verfolgen, verifizieren. Es ist Open Source unter AGPL-3.0 und läuft lokal. Was es bewusst nicht hat, sind Kommentar-Threads, Zuweisungen und ein geteiltes Board für nicht-technische Reviewer.
Im Projektordner, standardmäßig unter nit-review/. nit setup bietet den passenden .gitignore-Eintrag an, damit Reviews nicht im Repository landen. Zum Teilen packt nit export den Ordner in ein Zip, nit import und nit merge führen die Reviews mehrerer Personen mit Autor-Zuordnung wieder zusammen.
Ja. Ein Review-Ordner deckt mehrere Base-URLs ab, jede in ihrem eigenen Unterordner, und ein einziger MCP-Server serviert alle. Die IDs sind dann qualifiziert, also staging:a1, und jede Zeile trägt ihre Base und die navigierbare URL. Ein Review mit nur einer Site bleibt flach und ändert seine Form nie.
nit steht unter AGPL-3.0 und ist frei nutzbar, veränderbar und self-hostbar, auch in kommerziellen Projekten, solange Sie die Copyleft-Bedingungen einhalten. Diese greifen auch für netzwerk-gehostete veränderte Versionen. Wer nit in ein geschlossenes Produkt einbetten will, braucht eine separate kommerzielle Lizenz: [email protected].
Beim nächsten UI-Durchgang nicht wieder tippen, sondern klicken
Ein npm install, ein nit review, und Ihr Agent bekommt beim nächsten Mal Selektoren statt Beschreibungen.