Häufige Fragen

Verbinde GitHub, wähle Repositorys aus und fordere dann eine Prüfung an:

• Melde dich mit GitHub an und wähle unter Wähle, wo deine Repositorys liegen dein persönliches Konto oder deine Organisation. Fehlt es in der Liste, wähle Auf GitHub installieren und wähle es dort aus.
• Wähle auf GitHub Only select repositories, markiere die Repositorys, die geprüft werden sollen, und bestätige. In einer Organisation bittet GitHub einen Inhaber um Genehmigung, sofern du nicht selbst einer bist.
• Entscheide, ob HeyDeer von sich aus prüft: Lass Pull Requests automatisch prüfen eingeschaltet, damit jeder Push geprüft wird, bis zu 5-mal pro Pull Request, oder schalte es aus, damit nur auf Anfrage geprüft wird.
• Kommentiere @heydeer review in einem offenen Pull Request.

Du brauchst Schreibzugriff auf das Repository. Ein neuer Arbeitsbereich startet im kostenlosen Tarif ohne Kreditkarte, und die Befunde erscheinen als Prüfkommentare im Pull Request.

Du kannst direkt nach dem Verbinden eine Prüfung anfordern. HeyDeer liest die Änderungen des Pull Requests im Kontext des gesamten Repositorys, zusammen mit Titel, Beschreibung und Diskussion des PRs, und jede Prüfung sucht von Anfang an nach Bugs und Sicherheitsproblemen.

Wenn deine ersten Prüfungen eine Lücke zeigen, ergänze Hinweise dort, wo sie hingehören:

• AGENTS.md für die Funktionsweise deines Codes und die Konventionen, denen er folgt; auch Coding-Agents halten sich daran.
• REVIEW.md dafür, worauf Prüfungen achten sollen, was sie ignorieren sollen und wie schwer ein Problem wiegt.
• Eine Repository-Prüfung für eine Anforderung, die HeyDeer in jedem Pull Request verifizieren muss, der bestimmte Dateien ändert.
• Prüfanweisungen für Hinweise, die ein Pull Request nicht ändern darf oder die für alle Repositorys gelten.

Sobald jemand darum bittet: Kommentiere @heydeer review in einem Pull Request, wähle Prüfung starten auf der Seite Prüfverlauf oder wähle Re-run beim Check HeyDeer Review. Ein neuer Arbeitsbereich startet mit Nur manuell, und direkt nach der Einrichtung fragt HeyDeer, ob automatisch geprüft werden soll.

Ein Admin des Arbeitsbereichs kann den Zeitpunkt jederzeit unter Arbeitsbereichseinstellungen → Prüfregeln → Wann prüfen ändern:

• Einmal pro PR prüft einen passenden Pull Request, bis eine Prüfung erfolgreich ist.
• Bei jedem Push prüft, sobald der Pull Request zum ersten Mal deinen Filtern entspricht, und danach nach jedem Push, der Commits hinzufügt, standardmäßig bis zu 5-mal.

Automatische Prüfungen überspringen standardmäßig Entwürfe, Forks und Abhängigkeitsupdates.

Führe es schrittweise ein und lass HeyDeer über Merges entscheiden, sobald dein Team seinen Ergebnissen vertraut:

• Probiere es an ein paar Pull Requests aus: Kommentiere bei ausgeschalteten automatischen Prüfungen @heydeer review in einer Handvoll unterschiedlicher PRs und vergleiche die Befunde mit denen deiner Reviewer.
• Schließe die Lücken, die diese Prüfungen zeigen: Konventionen in AGENTS.md, Anforderungen in Repository-Prüfungen, Prioritäten in Prüfanweisungen.
• Schalte automatische Prüfungen für ein oder zwei Repositorys ein (wähle sie unter Repositorys aus, dann Zeitpunkt ändern) und danach für den ganzen Arbeitsbereich.
• Mach den Check HeyDeer Review erforderlich, entscheide über die automatische Genehmigung und richte in einem kostenpflichtigen Tarif die automatische Aufladung und ein Nutzungslimit ein.

Geh zur nächsten Stufe über, wenn dein Team die meisten Befunde umsetzt und Prüfungen ohne Hinweise zur Prüfung abschließen. Admins des Arbeitsbereichs ändern die Einstellungen; alle mit Schreibzugriff können Prüfungen anfordern.

Jeder dieser Wege prüft den neuesten Commit des Pull Requests:

• Kommentiere @heydeer review im Pull Request.
• Wähle Re-run beim Check HeyDeer Review.
• Wähle Prüfung starten auf der Seite Prüfverlauf in HeyDeer; dort kannst du auch eine andere Prüftiefe oder einen anderen Feedback-Umfang wählen.

Ist Nur neue Änderungen prüfen eingeschaltet, deckt eine Prüfung ab, was sich seit der letzten geändert hat; kommentiere @heydeer full review, um den gesamten Pull Request erneut zu prüfen. Zum Anfordern einer Prüfung brauchst du Schreibzugriff. Eine angeforderte Prüfung wird wie jede andere abgerechnet, zählt aber nicht zur Höchstzahl automatischer Prüfungen pro PR.

Wenn du eine Prüfung in HeyDeer startest, kannst du Prüftiefe und Feedback-Umfang für genau diese Prüfung wählen:

• Öffne Prüfverlauf und wähle Prüfung starten.
• Wähle Repository und Pull Request. Die Liste zeigt Repositorys, in denen du Schreibzugriff hast.
• Um Prüftiefe oder Feedback-Umfang zu ändern, öffne Prüfoptionen; beide beginnen mit den Standardeinstellungen des Repositorys.
• Wähle Prüfung ausführen.

Die Prüfung läuft dann und wird veröffentlicht wie eine, die auf GitHub angefordert wurde.

Nach der ersten Prüfung konzentriert sich HeyDeer auf das Neue. Ist Nur neue Änderungen prüfen eingeschaltet, was die Standardeinstellung ist, sucht eine spätere Prüfung nur in dem nach neuen Befunden, was die eigenen Commits des Pull Requests seit der letzten erfolgreichen Prüfung geändert haben, und prüft die früheren Befunde erneut. Commits, die aus dem Basis-Branch hineingemergt wurden, bleiben außen vor, Konfliktlösungen werden dagegen geprüft.

HeyDeer prüft den gesamten Pull Request, wenn:

• jemand @heydeer full review kommentiert oder die Einstellung ausgeschaltet ist.
• sich der Basis-Branch seit der letzten Prüfung geändert hat.
• die letzte Prüfung Hinweise zur Prüfung enthielt oder um Klärung gebeten hat.

Die Zusammenfassung des Checks zeigt mit Neue Änderungen oder Gesamter PR, was eine Prüfung abgedeckt hat.

Jede spätere Prüfung gleicht HeyDeers offene frühere Bedenken mit dem aktuellen Code ab:

• Bedenken, die weiterhin zutreffen, stehen unter Offene frühere Bedenken.
• Bedenken, die HeyDeer nicht verifizieren kann, stehen unter Zu bestätigende frühere Bedenken, zusammen mit den Informationen, die es braucht.
• Ist Geklärte HeyDeer-Unterhaltungen als erledigt markieren eingeschaltet, was die Standardeinstellung ist, markiert HeyDeer seine Unterhaltung als erledigt, sobald der Code das Bedenken behebt oder zeigt, dass es unbegründet war, oder sobald das Bedenken abgelehnt wurde.

Die Behebung muss im Code sichtbar sein; eine Antwort, dass es behoben ist, reicht nicht. Offene oder unbestätigte Bedenken blockieren die automatische Genehmigung und lassen, wenn Check bei gefundenen Problemen fehlschlagen lassen eingeschaltet ist, den Check fehlschlagen.

HeyDeer veröffentlicht die Befunde, die in deinen Feedback-Umfang fallen. Er legt fest, wie sicher sich HeyDeer sein muss, bevor es einen Befund des jeweiligen Schweregrads (Kritisch, Hoch, Mittel oder Niedrig) meldet:

• Kompakt meldet kritische Befunde, wenn sie wahrscheinlich sind, hohe und mittlere nur, wenn sie sicher sind, und niedrige nur aus Repository-Prüfungen. Das passt zu Teams, die jeden Kommentar lesen.
• Ausgewogen, die Standardeinstellung, meldet kritische Befunde schon bei Verdacht, hohe, wenn sie wahrscheinlich sind, und mittlere und niedrige, wenn sie sicher sind.
• Ausführlich meldet kritische und hohe Befunde schon bei Verdacht und mittlere und niedrige, wenn sie wahrscheinlich sind. Das passt zu Teams, deren Coding-Agent jeden Befund vor der Behebung verifiziert.

Befunde außerhalb des Umfangs werden nicht gemeldet, lassen den Check nicht fehlschlagen und blockieren die automatische Genehmigung nicht. Um die Umfänge zu vergleichen, sieh sie dir vor dem Wechsel in einer Vorschau auf eine abgeschlossene Prüfung in HeyDeer an.

Ja. „Mit HeyDeer beheben“ macht aus den Befunden, die du auswählst, einen Pull Request, den du begutachten und mergen kannst:

• Wähle Mit HeyDeer beheben in einem Prüfkommentar oder Befunde beheben auf der Prüfungsseite in HeyDeer.
• Wähle die Befunde aus und nutze Anweisungen hinzufügen für alle, die Kontext brauchen, etwa einen bestimmten Lösungsweg oder ein Verhalten, das erhalten bleiben soll.
• Wähle die Schaltfläche, die deine Auswahl zählt, etwa 2 Befunde beheben.

HeyDeer nimmt die Änderungen vor, führt deine Tests in einer Sandbox aus und öffnet einen separaten PR, der auf den Branch deines PRs zielt. Nachdem du ihn gemergt hast, prüft die nächste Prüfung deines PRs diese Befunde erneut. „Mit HeyDeer beheben“ ist in jedem Tarif enthalten.

Autopilot übergibt einen Pull Request an HeyDeer, bis er bereit zum Mergen ist oder dich braucht. In jeder Runde behebt HeyDeer, was offen ist, pusht in den eigenen Branch des PRs und prüft den neuen Commit, bis zu seinem Rundenlimit: standardmäßig 5 Runden, änderbar pro Arbeitsbereich oder Repository. Er kümmert sich um:

• Befunde innerhalb deines Feedback-Umfangs und offene frühere Bedenken.
• Anfragen von Personen mit Schreibzugriff in nicht erledigten Prüfungsunterhaltungen und neuen Kommentaren.
• Fehlgeschlagene Checks: die erforderlichen oder alle Checks außer HeyDeer Review.
• Merge-Konflikte, die er durch Mergen des Basis-Branches löst, nie durch Rebase oder Force-Push.

Starte ihn mit der Schaltfläche Autopilot auf der Prüfungsseite oder in HeyDeers Prüfkommentar, oder kommentiere @heydeer autopilot. Wenn er stoppt, veröffentlicht HeyDeer seine Prüfung und listet auf, was noch offen ist. Autopilot erfordert einen kostenpflichtigen Tarif, und jede Runde verbraucht Credits wie jede andere Behebung und Prüfung.

Wähle Autopilot stoppen auf seiner Seite in HeyDeer oder kommentiere @heydeer autopilot stop; alle mit Schreibzugriff können ihn stoppen. Der Autopilot stoppt auch von selbst, wenn:

• nichts mehr zu beheben ist oder er deine Antwort auf eine Frage braucht.
• jemand anderes in den Branch pusht, auch mit der GitHub-Schaltfläche Update branch.
• er sein Rundenlimit erreicht hat oder seine Runden keine Fortschritte mehr gemacht haben.
• Checks nach einer Stunde noch liefen, der PR in der Merge-Warteschlange ist oder GitHub seinen Push abgelehnt hat.
• der PR geschlossen oder gemergt wurde oder der Arbeitsbereich keine Credits oder keinen kostenpflichtigen Tarif mehr hat.

Sein Kommentar im PR sagt, warum er gestoppt hat und was noch von dir gebraucht wird, und erwähnt die Person, die ihn gestartet hat, wenn er sie braucht. Ein erneuter Start setzt die Rundenzahl zurück und berücksichtigt neue Antworten und Kommentare.

Erwähne @heydeer in einem Kommentar zu einem Pull Request oder Issue, in einem Inline-Prüfkommentar oder in der Beschreibung eines neuen Pull Requests oder Issues, um eine Frage zu stellen oder HeyDeer eine Aufgabe zu geben. Zum Beispiel:

• @heydeer what does this function do? erklärt den Code in einer Antwort.
• @heydeer fix the first issue and open an issue for the second öffnet einen Pull Request mit der Behebung und das neue Issue.
• @heydeer do the latest Next.js docs recommend this? sieht in der Dokumentation im Web nach.

HeyDeer liest die Unterhaltung, arbeitet in einer Sandbox, in der es deine Tests ausführen kann, und antwortet dort, wo du gefragt hast; Codeänderungen landen in einem neuen Pull Request, sofern du nichts anderes verlangst. Alle mit Schreibzugriff können fragen, und jede Anfrage verbraucht Credits des Arbeitsbereichs und erscheint in HeyDeer unter Aufgaben.

„Mit HeyDeer beheben“ ist in jedem Tarif enthalten, auch im kostenlosen. Eine Behebung braucht:

• Einen offenen Pull Request, dessen Branch im selben Repository liegt und nicht in einem Fork.
• Schreibzugriff auf das Repository.
• Lese- und Schreibzugriff von HeyDeer auf Contents, Pull requests und Workflows. Wurde HeyDeer installiert, bevor es Zugriff auf Workflows angefordert hat, muss ein Admin der Installation zuerst die aktualisierten Berechtigungen auf GitHub genehmigen.

Pro Pull Request läuft jeweils eine Behebung mit bis zu 100 Befunden.

Ja. Leg sie in AGENTS.md im Stammverzeichnis des Repositorys ab, dann prüft HeyDeer jeden Pull Request anhand dieser Konventionen; Coding-Agents, die AGENTS.md unterstützen, folgen derselben Datei, wenn sie Code schreiben. Schreib auf, was ein neues Teammitglied wissen müsste, etwa wie der Code organisiert ist, wie benannt wird, welche Hilfsfunktionen und Bibliotheken zu verwenden sind und wie Fehler und Tests funktionieren, eine Konvention pro Aufzählungspunkt, mit Begründung, wenn sie nicht offensichtlich ist.

Ein Verzeichnis, das eigene Konventionen braucht, kann eine eigene Datei haben, etwa src/payments/AGENTS.md. Sie ergänzt die Dateien darüber und hat bei Konflikten Vorrang. In einem Verzeichnis ohne AGENTS.md liest HeyDeer CLAUDE.md. Schreib Konventionen direkt in die Datei, da HeyDeer Importen nicht folgt.

In REVIEW.md, im Stammverzeichnis des Repositorys oder in jedem Verzeichnis, das eigene Hinweise braucht. Nutze die Datei für:

• Was geprüft werden soll, das HeyDeer nicht aus dem Code wissen kann, etwa welche Log-Felder als personenbezogene Daten gelten.
• Was ignoriert werden soll, eng gefasst und mit den betroffenen Pfaden.
• Wie schwer eine Art von Problem wiegt, mit Kritisch, Hoch, Mittel und Niedrig.
• Welche Belege eine Art von Befund braucht, wenn sich diese Art immer wieder als falsch erweist.

Eine REVIEW.md, die für Claude Code Review geschrieben wurde, funktioniert unverändert. Ein Pull Request kann REVIEW.md bearbeiten, also gehören Hinweise, die er nicht ändern darf, in die Prüfanweisungen.

Eine Anforderung, die du als Markdown-Datei in .agents/checks/ in deinem Repository ablegst, mit den betroffenen Dateien unter files in ihrem Frontmatter. HeyDeer verifiziert sie in jedem Pull Request, der diese Dateien ändert, mit einem eigenen Prüfer für diese Anforderung. Eine Repository-Prüfung ist dadurch gründlicher als allgemeine Hinweise und verbraucht mehr Credits.

Nutze Repository-Prüfungen für Anforderungen, die teuer werden, wenn man sie übersieht, und leicht zu übersehen sind, etwa die Zugriffskontrolle deiner API-Routen. Ein Befund aus einer Repository-Prüfung nennt ihre Datei und zählt für den Check HeyDeer Review und die automatische Genehmigung. Wenn du dir Repository-Prüfungen schreiben lassen willst, wähle Repository-Prüfungen einrichten im Dashboard: HeyDeer liest das Repository und seine bisherigen Pull Requests und öffnet dann einen Pull Request, der Repository-Prüfungen hinzufügt, ohne Credits zu verbrauchen.

Meist decken die Hinweise die geänderten Dateien nicht ab. Prüfe, welche Ursache zutrifft:

• Eine Repository-Prüfung muss eine .md-Datei direkt in .agents/checks/ sein, deren files-Muster auf eine geänderte Datei passen.
• Eine AGENTS.md oder REVIEW.md muss in einem Verzeichnis liegen, das die geänderten Dateien abdeckt.
• Prüfanweisungen gelten für Prüfungen, die nach dem Speichern angefordert werden, und Anweisungen des Repositorys haben bei Konflikten Vorrang vor denen des Arbeitsbereichs.
• Der Befund liegt womöglich außerhalb deines Feedback-Umfangs; probiere Ausgewogen oder Ausführlich.
• Eine Anforderung, die HeyDeer nicht durch Lesen des Codes verifizieren kann, muss als Bedingung an den Code umformuliert werden.
• Generierte Dateien und Lockfiles, die der Basis-Branch bereits enthält, werden übersprungen.

Nachdem du die Ursache behoben hast, kommentiere @heydeer review.

Arbeite diese Liste von oben nach unten ab; sie beginnt mit den Änderungen, die mit dem geringsten Aufwand am meisten bewirken:

• Stell den Feedback-Umfang auf Kompakt um, nachdem du dir eine Vorschau auf eine aktuelle Prüfung in HeyDeer angesehen hast.
• Markiere generierten Code in .gitattributes als linguist-generated.
• Überspringe Bot- oder Wegwerf-Pull-Requests mit Filtern für automatische Prüfungen, etwa mit einem Label skip-review.
• Lehne Befunde ab, die du bewusst nicht beheben willst, damit sie nicht erneut aufkommen.
• Füge für eine Art von Kommentar, auf die niemand reagiert, eine eng gefasste Prüfanweisung mit Begründung hinzu.
• Grenze die files-Muster einer Repository-Prüfung ein, wenn sie Dateien meldet, um die es ihr gar nicht geht.

Remote-MCP-Server, mit denen Prüfungen und Aufgaben nachsehen können, was der Code allein nicht zeigt: wie eine Funktion genutzt wird, was in den Logs steht, welche Daten in einer Tabelle liegen oder was die Dokumentation einer Bibliothek sagt. Sie sind in kostenpflichtigen Tarifen enthalten und werden vom Inhaber der GitHub-Organisation oder des persönlichen Kontos verwaltet.

Um einen hinzuzufügen, öffne Arbeitsbereichseinstellungen → Connectors, wähle Connector hinzufügen, gib den HTTPS-Endpunkt des Servers und die benötigten Header ein und wähle Tools laden. Wähle die erlaubten Tools und die Repositorys aus und dann Connector speichern. Anfangs sind nur lesende Tools erlaubt, ein Connector wird standardmäßig nur in privaten Repositorys verwendet, und Tool-Aufrufe erhöhen die Credits der jeweiligen Arbeit.

Nutze die Filter für automatische Prüfungen unter Wann prüfen in Arbeitsbereichseinstellungen → Prüfregeln oder im Tab Prüfregeln eines Repositorys. Jede Zeile filtert nach Labels, Autor, Team des Autors, Beziehung oder Kontotyp, Entwurfsstatus oder Herkunft, und ein Pull Request kommt nur infrage, wenn er jeder Zeile entspricht. Einige gängige Zeilen:

• Alle Bots überspringen: Kontotyp des Autors → Ist keines von → Bot.
• Nur Pull Requests mit Label prüfen: PR-Labels → Ist eines von → ai-review.
• Autoren abwählen lassen: PR-Labels → Ist keines von → skip-review.

Standardmäßig überspringen die Filter Entwürfe, Forks und Abhängigkeitsupdates. Sie gelten nur für automatische Prüfungen, du kannst also für jeden Pull Request weiterhin eine Prüfung anfordern.

In Credits, für die Arbeit, die jede Prüfung oder Behebung leistet. Eine größere Änderung oder eine tiefgehende Prüfung verbraucht also mehr als eine kleine Standardprüfung. Der ganze Arbeitsbereich teilt sich einen Tarif und ein Credit-Guthaben, mit unbegrenzt vielen Entwicklern und Repositorys und ohne Gebühren pro Nutzer, sodass neue Teammitglieder den Preis nicht ändern.

• Jeder Tarif enthält monatliche Credits. Free beginnt mit 1.000 Credits im ersten Monat und danach 300 pro Monat.
• In jedem Tarif, auch in Free, kannst du Credits zum Grundpreis von $10 pro 1.000 Credits hinzufügen, mit Rabatten bei größeren Käufen.
• Prüfungen öffentlicher Repositorys sind bis zu einer Fair-Use-Grenze kostenlos.

Kostenpflichtige Tarife bieten mehr monatliche Credits und parallele Prüfungen sowie tiefgehende Prüfungen, Autopilot und Connectors.

HeyDeer startet keine neuen Prüfungen mehr, bis der Arbeitsbereich wieder Credits hat. Eine bereits laufende Prüfung wird abgeschlossen, wobei HeyDeer die nicht bezahlte Nutzung übernimmt, während eine laufende Behebung stoppt. Kann eine automatische Prüfung nicht starten, nennt der Check HeyDeer Review den Grund, und HeyDeer kommentiert einmal pro Tag im ersten betroffenen Pull Request jedes Repositorys mit einem Link zu den Tarif- und Credit-Optionen.

Um weiterzumachen, füge Credits unter Nutzung und Abrechnung → Übersicht hinzu, warte auf die nächste monatliche Auffrischung oder wähle einen kostenpflichtigen Tarif, und fordere die Prüfung dann erneut an; spätere automatische Prüfungen starten wie gewohnt. In einem kostenpflichtigen Tarif schreibt HeyDeer dem Arbeitsbereich eine E-Mail, wenn die Credits knapp werden und wenn sie aufgebraucht sind, und die automatische Aufladung kann vorher Credits hinzufügen.

Admins des Arbeitsbereichs legen beides unter Nutzung und Abrechnung → Übersicht → Ausgabenkontrolle fest, sobald der Arbeitsbereich einen Tarif gewählt hat:

• Die automatische Aufladung ist standardmäßig aus. Sie kauft zu deinem Mengenrabatt eine feste Menge zusätzlicher Credits, sobald das Guthaben unter einen von dir festgelegten Schwellenwert fällt, damit Prüfungen weiterlaufen. Sie erfordert einen aktiven kostenpflichtigen Tarif und belastet die Karte deines Abonnements.
• Ein Nutzungslimit begrenzt die Credits, die Prüfungen und Behebungen zusammen in einer Kalenderwoche oder einem Kalendermonat verbrauchen. Ist es erreicht, starten keine neuen Prüfungen und Behebungen, bis das Limit zurückgesetzt wird oder du es erhöhst, während laufende abgeschlossen werden.

Wöchentliche Limits werden jeden Montag zurückgesetzt, monatliche am 1., jeweils um 00:00 UTC. Das Hinzufügen von Credits hebt ein Nutzungslimit nicht auf.

Admins des Arbeitsbereichs verwalten den Tarif unter Nutzung und Abrechnung → Übersicht:

• Für ein Upgrade nutze Tarif wechseln. Es gilt ab der Zahlung: Du zahlst die Differenz für den Rest des Zeitraums, bekommst einen entsprechenden Anteil der zusätzlichen monatlichen Credits und behältst dein Verlängerungsdatum.
• Für ein Downgrade nutze ebenfalls Tarif wechseln. Es gilt ab der nächsten Verlängerung, und Aktuellen Tarif behalten macht es rückgängig.
• Zum Kündigen öffne das Abrechnungsportal. Der Tarif bleibt bis zum Ende des bezahlten Zeitraums bestehen, danach kehrt der Arbeitsbereich zu Free zurück; wähle vorher Abonnement fortsetzen, um ihn zu behalten.

Steuere, wie viele Prüfungen laufen und wie tief sie gehen:

• Lass die Voreingestellte Prüftiefe auf Standard und nutze Tiefgehend nur, wo der Code es erfordert.
• Stell den Prüfzeitpunkt auf Einmal pro PR oder senke die Höchstzahl automatischer Prüfungen pro PR.
• Lass Nur neue Änderungen prüfen eingeschaltet.
• Überspringe Pull Requests, die keine Prüfung brauchen, mit Filtern für automatische Prüfungen, und markiere generierte Dateien.

In einem kostenpflichtigen Tarif begrenzt ein wöchentliches oder monatliches Nutzungslimit die Ausgaben. Nutzung und Abrechnung → Nutzung zeigt die verbrauchten Credits nach Repository, Pull Request, Prüfung und Aufgabe.

Jedes Mitglied sieht Prüfungen für die Repositorys, auf die es auf GitHub zugreifen kann, und kann mit Schreibzugriff auf ein Repository dort Prüfungen starten und abbrechen. Admins können außerdem:

• Prüfregeln und Prüfzeitpunkte ändern, die Mitglieder ansehen können.
• Arbeitsbereichseinstellungen und Nutzung und Abrechnung verwalten.
• Die Rollen von Mitgliedern ändern.

Connectors werden nur von Admins verwaltet, die als Inhaber der GitHub-Organisation oder Kontoinhaber gekennzeichnet sind, und Zugriff auf manuelle Prüfungen kann einschränken, wer Prüfungen anfordert.

Einblicke fasst zusammen, was deine Prüfungen gefunden haben und was dein Team daraus gemacht hat, für einen Zeitraum und ein Repository deiner Wahl:

• Geprüfte PRs, Befunde, Befunde pro PR und die Ablehnungsquote.
• Befunde nach Schweregrad im Zeitverlauf und ob eine spätere Prüfung jeden davon als behoben, noch im Code oder abgelehnt eingestuft hat.
• Dieselben Summen für jedes Repository und, für Admins des Arbeitsbereichs, für jede Person, die Pull Requests verfasst.

Jeder Befund zählt einmal, auch wenn spätere Prüfungen ihn erneut melden. Eine hohe Ablehnungsquote in einem Repository bedeutet oft, dass HeyDeer dort Kontext fehlt, den Prüfanweisungen, REVIEW.md oder eine Repository-Prüfung liefern können.

E-Mails zu Credits, Zahlungen und GitHub-Zugriff des Arbeitsbereichs, niemals Werbung:

• Knappe Credits (in einem kostenpflichtigen Tarif mit ausgeschalteter automatischer Aufladung, bei 20 % der monatlichen Credits des Tarifs) und aufgebrauchte Credits.
• Eine fehlgeschlagene Abonnementzahlung, eine Zahlung, die deine Bank bestätigen lassen will, oder eine Verlängerung, die nach der Kulanzfrist noch unbezahlt ist.
• Eine fehlgeschlagene oder wegen eines Kauflimits pausierte automatische Aufladung sowie pausierte Zahlungen, während ein Abrechnungsproblem geklärt wird.
• Die Genehmigung einer Anfrage zum Verbinden von HeyDeer durch einen Inhaber der GitHub-Organisation.

HeyDeer wird als GitHub App installiert, und mit Only select repositories beschränkst du es auf die Repositorys, die geprüft werden sollen. Die wichtigsten Berechtigungen sind:

• Contents mit Lese- und Schreibzugriff: Code und Verlauf lesen und Commits für Behebungen und Anfragen an @heydeer pushen, ohne je Commits in einem Branch zu überschreiben.
• Pull requests mit Lese- und Schreibzugriff: Prüfungen und Kommentare veröffentlichen und Pull Requests auf deinen Wunsch öffnen, aktualisieren oder mergen.
• Checks mit Lese- und Schreibzugriff: den Check HeyDeer Review anzeigen.
• Workflows: GitHub-Actions-Workflow-Dateien aktualisieren, wenn eine Behebung sie ändert.

Kleinere Berechtigungen decken Befehle ab, Actions-Logs für den Autopilot, Organisationsmitglieder für Filter und deine E-Mail-Adresse für Abrechnungshinweise. HeyDeer fordert keinen Administration-Zugriff an, und jedes Token ist auf ein Repository und die Berechtigungen beschränkt, die sein Schritt braucht.

Das, was es braucht, um deinen Prüfverlauf zu bewahren und den Arbeitsbereich zu betreiben:

• Ergebnisse von Prüfungen und Behebungen, ausgewählte Befunde und Anweisungen, die die kommentierten Zeilen zitieren können.
• Kennungen von Repositorys und PRs.
• Konto- und Arbeitsbereichsinformationen sowie Einstellungen.
• Abrechnungsunterlagen.

Dein Repository selbst wird in einem temporären Klon verarbeitet, der verworfen wird, wenn die Arbeit endet. Bei Connector-Aufrufen speichert HeyDeer Tool, Zeitpunkt, Dauer und Ergebnis, aber nicht, was gesendet oder zurückgegeben wurde.

Der Check HeyDeer Review am neuesten Commit nennt den Grund in seinem Titel. Die häufigsten Ursachen, die häufigste zuerst:

• Der Prüfzeitpunkt ist Nur manuell, die Standardeinstellung für neue Arbeitsbereiche: Wähle Einmal pro PR oder Bei jedem Push.
• Die Filter überspringen ihn, wie standardmäßig Entwürfe, Forks und Abhängigkeitsupdates: Markiere ihn als bereit, ändere die Filter oder kommentiere @heydeer review.
• Die Prüfung wartet in der Warteschlange, weil die Kapazität belegt ist: Sie startet, sobald ein Platz frei wird.
• Bei Einmal pro PR gibt es bereits eine erfolgreiche Prüfung, oder der PR hat die Höchstzahl automatischer Prüfungen pro PR erreicht: Kommentiere @heydeer review.
• Der Arbeitsbereich hat keine Credits mehr oder sein Nutzungslimit erreicht: Füge Credits hinzu oder erhöhe das Limit und fordere dann eine Prüfung an.
• Automatische Prüfungen sind für den PR pausiert: Kommentiere @heydeer resume.

Meist wurde das Repository noch nicht geprüft, oder das Veröffentlichen von Checks ist ausgeschaltet. Prüfe Folgendes der Reihe nach:

• Das Repository steht auf Nur manuell und wurde noch nie geprüft: Fordere eine Prüfung an, dann bekommen spätere Revisionen einen Check.
• GitHub-Check veröffentlichen ist ausgeschaltet: Schalte es unter Ergebnisse veröffentlichen in den Prüfregeln ein.
• HeyDeer fehlt die Checks-Berechtigung oder der Zugriff auf das Repository: Ein GitHub-Inhaber wählt Berechtigungsanfrage prüfen oder Repositorys hinzufügen unter Arbeitsbereichseinstellungen → GitHub-Verbindung.
• Der Pull Request ist geschlossen: Öffne ihn wieder.

Sobald HeyDeer in einem Repository Checks veröffentlicht, bekommt jede Aktualisierung eines Pull Requests ein Check-Ergebnis, sodass ein erforderlicher Check nie ewig wartet.

HeyDeer setzt 👀 unter jeden Befehl, den es annimmt. Fehlt es, prüfe Folgendes:

• Poste den Befehl als reinen Text in einem neuen PR-Kommentar oder Inline-Prüfkommentar, nicht in Code, einem Zitat, einem HTML-Kommentar oder einer Bearbeitung, und von einem persönlichen Konto statt einem Bot.
• Du brauchst Schreibzugriff und musst unter Zugriff auf manuelle Prüfungen aufgeführt sein, falls dieser eingeschränkt ist.
• Der Arbeitsbereich hat womöglich keine Credits mehr oder sein Nutzungslimit erreicht.
• HeyDeer braucht womöglich die Berechtigung Issues oder Pull requests: Ein GitHub-Inhaber wählt Berechtigungsanfrage prüfen unter Arbeitsbereichseinstellungen → GitHub-Verbindung.
• pause und resume funktionieren nur in offenen Pull Requests.

Nachdem du die Ursache behoben hast, poste den Befehl erneut in einem neuen Kommentar.

Mach den Check HeyDeer Review erforderlich und lass ihn bei Befunden fehlschlagen:

• Lass HeyDeer mindestens einen Pull Request im Repository prüfen, damit der Check existiert.
• Schalte in deiner GitHub-Branch-Schutzregel oder deinem Ruleset für den Basis-Branch erforderliche Status-Checks ein, füge HeyDeer Review hinzu und wähle HeyDeer als Quelle.
• Schalte in HeyDeer Check bei gefundenen Problemen fehlschlagen lassen unter Arbeitsbereichseinstellungen → Prüfregeln → Ergebnisse veröffentlichen ein.

Ein Pull Request lässt sich dann erst mergen, wenn seine Befunde und früheren Bedenken behoben oder abgelehnt sind. Ein Commit, den HeyDeer nicht automatisch prüft, etwa nach Erreichen der Höchstzahl automatischer Prüfungen pro PR, blockiert das Mergen ebenfalls, bis jemand eine Prüfung anfordert.

Die Zusammenfassung des Checks zählt die Befunde, offenen früheren Bedenken und fehlgeschlagenen Repository-Prüfungen, die hinter dem Ergebnis stehen. Der Check schlägt fehl, wenn:

• Check bei gefundenen Problemen fehlschlagen lassen eingeschaltet ist und die Prüfung Befunde innerhalb deines Feedback-Umfangs, offene oder unbestätigte frühere Bedenken oder Hinweise zur Prüfung enthält.
• unabhängig von der Einstellung eine Repository-Prüfung nicht gelaufen ist, ein früheres Bedenken nicht erneut geprüft wurde oder HeyDeer die Prüfung nicht starten oder abschließen konnte.

Behebe die Befunde und pushe, oder lehne sie in ihren Unterhaltungen ab und kommentiere @heydeer review. Fordere bei einer unvollständigen Prüfung eine weitere an; HeyDeer gibt die Credits einer fehlgeschlagenen Prüfung zurück, sofern sie keinen Connector aufgerufen hat.

Die automatische Genehmigung ist standardmäßig ausgeschaltet; schalte sie unter Ergebnisse veröffentlichen in den Prüfregeln ein. Ist sie eingeschaltet, zeigt die Seite der Prüfung in HeyDeer Nicht automatisch genehmigt mit dem Grund an, zum Beispiel:

• Es gibt noch Befunde oder frühere Bedenken: Behebe oder lehne sie ab, oder wähle Probleme mit niedrigem Schweregrad zulassen, um auch dann zu genehmigen, wenn nur noch niedrige übrig sind.
• Die Risikostufe des PRs liegt über deiner Einstellung PRs, die HeyDeer genehmigen darf, also genehmigt ihn ein Mensch.
• Eine Frage wartet unter Klärung erforderlich, oder die Prüfung enthält Hinweise zur Prüfung.
• Der PR ändert Hinweise, die HeyDeer aus ihm liest, etwa AGENTS.md oder eine Repository-Prüfung, oder HeyDeer hat ihn geöffnet.
• Nach der Prüfung sind neue Commits hinzugekommen, oder der Basis-Branch hat sich bewegt.