Die ersten fünf Tabellen folgen den Abschnitten von Arbeitsbereichseinstellungen → Prüfregeln. Voreinstellungen sind die Werte, mit denen ein neuer Arbeitsbereich startet, und jede Einstellung verlinkt auf die Seite, die sie erklärt. Ein Repository folgt dem Wert des Arbeitsbereichs, bis du ihn anpasst; siehe So funktionieren Einstellungen.
Wann prüfen
| Einstellung | Voreinstellung | Wirkung |
|---|
| Prüfzeitpunkt | Nur manuell | Ob HeyDeer Pull Requests selbstständig prüft: Einmal pro PR, Bei jedem Push oder Nur manuell. |
| Höchstzahl automatischer Prüfungen pro PR | 5 | Stoppt im Modus Bei jedem Push die automatischen Prüfungen eines Pull Requests, nachdem so viele erfolgreich waren: 1, 2, 3, 5, 10, 20 oder Unbegrenzt. |
| Automatische Prüfungen stoppen, wenn ein PR geschlossen wird | Ein | Stoppt wartende und laufende automatische Prüfungen, wenn ein Pull Request geschlossen oder gemergt wird. |
| Filter für automatische Prüfungen | PR-Status → Ist kein Entwurf, PR-Herkunft → Ist eines von → Dasselbe Repository und Autor → Ist keines von → dependabot[bot], renovate[bot], pre-commit-ci[bot], snyk-io[bot], snyk-bot | Welche Pull Requests automatische Prüfungen abdecken, nach Labels, Autor, Team, Kontotyp, Entwurfsstatus und Herkunft. Ein Pull Request muss jeder Zeile entsprechen. |
Prüfverhalten
| Einstellung | Voreinstellung | Wirkung |
|---|
| Voreingestellte Prüftiefe | Standard | Standard oder Tiefgehend. „Tiefgehend“ nimmt sich für jeden Schritt mehr Zeit, verbraucht mehr Credits und erfordert einen kostenpflichtigen Tarif. |
| Nur neue Änderungen prüfen | Ein | Spätere Prüfungen decken nur ab, was sich seit der letzten geändert hat, und prüfen frühere Bedenken erneut. |
| Feedback-Umfang | Ausgewogen | Welche Befunde HeyDeer meldet, nach Sicherheit und Schweregrad: Kompakt, Ausgewogen oder Ausführlich. |
| Prüfsprache | English | Die Sprache von allem, was HeyDeer auf GitHub veröffentlicht, einschließlich Befunden, dem Check HeyDeer Review und Antworten auf Befehle: English, 简体中文, 日本語, Español, 한국어, Português (Brasil), Deutsch. Code und Dateipfade bleiben unverändert. |
| Zugehörige Issues und PRs lesen | Ein | Ermöglicht HeyDeer, Issues und Pull Requests im selben Repository zu lesen, die die Änderung erklären. |
| Rundgang | Ein | Fügt einen Leitfaden durch die Änderung hinzu: gruppiert zusammengehörige Bearbeitungen und hebt die wichtigen hervor. |
| Repository-Snapshot behalten | Ein | Große Repositorys starten Prüfungen schneller mit einem Snapshot ihres Standard-Branches. Der Snapshot wird einen Tag nach der letzten Nutzung gelöscht oder wenn du diese Option deaktivierst. |
Ergebnisse veröffentlichen
| Einstellung | Voreinstellung | Wirkung |
|---|
| Automatische Genehmigung | Aus | Ermöglicht HeyDeer, Pull Requests zu genehmigen, die die beiden folgenden Bedingungen erfüllen. Funktioniert nur, solange Prüfkommentare im PR veröffentlichen aktiviert ist. |
| PRs, die HeyDeer genehmigen darf | PRs mit niedrigem und mittlerem Risiko | Die höchste Risikostufe, die HeyDeer genehmigt: PRs mit niedrigem Risiko, PRs mit niedrigem und mittlerem Risiko oder PRs jeder Risikostufe. |
| Zulässige offene Probleme | Keine offenen Probleme | Ob HeyDeer genehmigen darf, während Befunde oder frühere Bedenken mit niedrigem Schweregrad offen bleiben: Keine offenen Probleme oder Probleme mit niedrigem Schweregrad zulassen. |
| GitHub-Check veröffentlichen | Ein | Zeigt Fortschritt und Ergebnisse der Prüfung im Check HeyDeer Review. |
| Check bei gefundenen Problemen fehlschlagen lassen | Aus | Lässt den Check bei Befunden, offenen oder unbestätigten früheren Bedenken und unvollständigen Prüfungen fehlschlagen. Gilt nur, solange GitHub-Check veröffentlichen aktiviert ist. |
| Prüfkommentare im PR veröffentlichen | Ein | Veröffentlicht jede Prüfung im Pull Request. „Aus“ deaktiviert auch die automatische Genehmigung und das Markieren von Unterhaltungen als erledigt. |
| Geklärte HeyDeer-Unterhaltungen als erledigt markieren | Ein | Markiert Unterhaltungen von HeyDeer als erledigt, sobald eine spätere Prüfung das Bedenken als behoben erkennt oder eine Entscheidung akzeptiert, nichts zu ändern. |
Zugriff auf manuelle Prüfungen
| Einstellung | Voreinstellung | Wirkung |
|---|
| Wer Prüfungen anfordern kann | Alle mit Schreibzugriff auf das Repository | Wer Prüfungen von HeyDeer anfordern kann, in PR-Kommentaren oder über den Check. Die andere Option, Ausgewählte Benutzer oder Teams mit Schreibzugriff, nimmt bis zu 100 Benutzernamen und in Organisationen 30 Teams auf. |
In HeyDeer konfiguriert
Eine Prüfung verwendet die Prüfregeln, Anweisungen und Connectors, die gespeichert sind, wenn HeyDeer sie in die Warteschlange stellt. Ein Pull Request kann sie nicht ändern.
| Konfiguration | Wo | Wer sie ändern kann | Regeln und Limits |
|---|
| Prüfregeln | Arbeitsbereichseinstellungen → Prüfregeln oder Repositorys → (ein Repository) → Prüfregeln | Admins des Arbeitsbereichs | Ein Repository folgt jeder Standardeinstellung des Arbeitsbereichs, bis du sie anpasst. |
| Prüfanweisungen | Arbeitsbereichseinstellungen → Prüfanweisungen oder Repositorys → (ein Repository) → Prüfanweisungen | Admins des Arbeitsbereichs | Einfacher Text oder Markdown, bis zu 12.000 Zeichen pro Ebene. Bei Widersprüchen haben Repository-Anweisungen Vorrang. |
| Connectors | Arbeitsbereichseinstellungen → Connectors | Admins des Arbeitsbereichs, die auch Inhaber der GitHub-Organisation oder des Kontos sind | Connectors sind in kostenpflichtigen Tarifen enthalten. Bis zu 50 pro Arbeitsbereich, jeweils ein Streamable-HTTP-Server an einem öffentlichen HTTPS-Endpunkt. |
Admins können die Einstellungen eines Repositorys nur ändern, wenn sie auf GitHub darauf zugreifen können. Siehe Mitglieder des Arbeitsbereichs.
Repository-Dateien
HeyDeer liest außerdem diese Dateien aus dem geprüften Repository. Alle, die in den Branch eines Pull Requests pushen können, können die daraus gelesenen Dateien ändern; siehe Was ein Pull Request ändern kann.
| Datei | Gelesen aus | Regeln und Limits |
|---|
AGENTS.md, CLAUDE.md | Die eigene Version des Pull Requests | Beliebiges Verzeichnis. Gilt für das eigene Verzeichnis und alle darunterliegenden; tiefer liegende Dateien haben Vorrang. In Verzeichnissen ohne AGENTS.md wird CLAUDE.md gelesen. Insgesamt bis zu 32 KiB vom Stammverzeichnis bis zu einem Verzeichnis; der Rest bleibt unberücksichtigt. |
REVIEW.md | Die eigene Version des Pull Requests | Beliebiges Verzeichnis. Gilt für Änderungen im eigenen Verzeichnis und allen darunterliegenden; tiefer liegende Dateien haben Vorrang. Ein symbolischer Link wird nicht gelesen. |
.agents/checks/*.md | Die eigene Version des Pull Requests | Eine Markdown-Datei pro Prüfung, direkt in .agents/checks, mit files im Frontmatter. Namen beginnen mit einem Buchstaben oder einer Ziffer und enthalten Buchstaben, Ziffern, ., _ und -. Bis zu 16.000 Byte pro Datei. Eine Prüfung führt höchstens 10 passende Repository-Prüfungen aus, in der Reihenfolge der Dateinamen. |
.agents/skills/ | Die eigene Version des Pull Requests | Wird verwendet, wenn eine Repository-Prüfung ihn aufführt. Jeder Skill ist ein Ordner mit einer SKILL.md, benannt mit Kleinbuchstaben, Ziffern und einzelnen Bindestrichen, bis zu 64 Zeichen. |
.gitattributes | Der Basis-Branch | Als linguist-generated markierte Dateien und bereits vorhandene Lockfiles, sofern nicht als -linguist-generated markiert, werden bei der Prüfung ausgelassen. Alle, die in den Basis-Branch mergen können, können dies ändern. |
Frontmatter von Repository-Prüfungen
Jede Repository-Prüfung beginnt mit YAML-Frontmatter zwischen zwei ----Zeilen. Andere Schlüssel ignoriert HeyDeer.
| Schlüssel | Wert | Wirkung |
|---|
files | Ein Muster oder eine Liste von Mustern | Erforderlich; ohne diesen Schlüssel ignoriert HeyDeer die Datei. Die geänderten Dateien, die die Repository-Prüfung abdeckt. Stelle einem Muster ! voran, um Dateien auszuschließen; Ausschlüsse benötigen mindestens ein einschließendes Muster. |
skills | Ein Skill-Name oder eine Liste von Namen | Optional. Skills, die die Repository-Prüfung verwendet, geladen aus dem Pull Request. Ein fehlender Skill hält die Prüfung nicht auf. |
