Was HeyDeer liest
Eine Prüfung liest die Änderungen des Pull Requests im Kontext des gesamten Repositorys, zusammen mit der PR-Diskussion und den Hinweisen, die du HeyDeer gibst. Diese Seite zeigt, wohin welche Art von Hinweisen gehört und welche davon ein Pull Request ändern kann.
Code und Diskussion
HeyDeer prüft, was der Pull Request ändert, und kann jede Datei am PR-Head sowie den Commit-Verlauf lesen und durchsuchen. Ein Befund kann auf Code außerhalb des Diffs verweisen, der durch die Änderung nicht mehr funktioniert.
Außerdem liest HeyDeer Titel, Beschreibung und Diskussion des PRs.
Zugehörige Issues und Pull Requests
Wenn Zugehörige Issues und PRs lesen aktiviert ist (voreingestellt), kann HeyDeer Issues und Pull Requests im selben Repository lesen, wenn sie die Änderung erklären, etwa ein Issue, das der PR behebt. Ändere dies unter Prüfregeln → Prüfverhalten; siehe Einstellungsreferenz.
Wohin welche Art von Hinweisen gehört
Zum Start brauchst du keine Hinweise: HeyDeer bezieht schon bei der ersten Prüfung das gesamte Repository ein. Ergänze Hinweise für die Lücken, die deine ersten Prüfungen zeigen.
Schreib nur, was für deine Codebasis spezifisch ist. HeyDeer kennt gängige Engineering-Praxis bereits, und jede Prüfung sucht nach Fehlern und Sicherheitsproblemen. Hinweise, die das wiederholen, bringen nichts.
| Was du HeyDeer mitteilen möchtest | Ablegen in |
|---|---|
| Wie dein Code funktioniert und welchen Konventionen er folgt. Auch Coding-Agenten befolgen sie. | AGENTS.md |
| Worauf Prüfungen achten sollen, was sie auslassen sollen und wie schwer ein Problem wiegt | REVIEW.md |
| Eine Anforderung, die HeyDeer in jedem Pull Request verifizieren muss, der bestimmte Dateien ändert | .agents/checks/ |
| Ein Ablauf, den mehrere Repository-Prüfungen teilen | .agents/skills/ |
| Prüfungshinweise, die ein Pull Request nicht ändern darf oder die für alle Repositorys gelten | Prüfanweisungen |
| Kontext außerhalb des Repositorys, etwa Tickets oder interne Dokumentation | Connectors |
Repository-Prüfung oder REVIEW.md
Prüfungen folgen AGENTS.md und REVIEW.md, während sie die gesamte Änderung untersuchen. Jede passende Repository-Prüfung bekommt zusätzlich einen eigenen Prüfer, der nur diese Anforderung verifiziert. Sie ist daher gründlicher, verbraucht aber mehr Credits.
Mach eine Anforderung, deren Übersehen teuer ist und die leicht übersehen wird, zu einer Repository-Prüfung, etwa die Zugriffskontrolle deiner API-Routen. Schreib den Rest in REVIEW.md. Siehe Eine wirksame Repository-Prüfung schreiben.
Wenn sich Hinweise widersprechen
Prüfanweisungen haben Vorrang vor REVIEW.md, AGENTS.md, CLAUDE.md und Skills, und Repository-Anweisungen haben Vorrang vor Arbeitsbereichsanweisungen. Weder Anweisungen noch irgendetwas im Repository können verhindern, dass eine passende Repository-Prüfung ausgeführt wird.
Wenn HeyDeer deine Hinweise zu ignorieren scheint, siehe Fehlerbehebung.
Was ein Pull Request ändern kann
HeyDeer liest AGENTS.md, CLAUDE.md, REVIEW.md, Repository-Prüfungen und Skills aus dem Head-Commit des Pull Requests. Ein Pull Request, der sie bearbeitet, wird mit seiner eigenen Version geprüft und kann so die Hinweise ändern, anhand derer er geprüft wird. HeyDeer genehmigt einen solchen Pull Request nie automatisch.
Prüfanweisungen und Connectors werden in HeyDeer gespeichert, daher kann ein Pull Request sie nicht ändern. Hinweise, die vor Änderungen durch Pull Requests geschützt sein müssen, gehören in die Prüfanweisungen.
HeyDeer liest .gitattributes aus dem Basis-Branch, sodass ein Pull Request seine eigenen Dateien nicht als generiert markieren kann, um sie aus der Prüfung herauszuhalten. Wo welche Konfiguration liegt und wer sie ändern kann, erfährst du unter Einstellungsreferenz.
Generierte Dateien
Markiere generierte Dateien, etwa generierte Clients, in .gitattributes als linguist-generated. HeyDeer überspringt sie bei Prüfungen und Repository-Prüfungen und liest das Attribut aus dem Basis-Branch.
Lockfiles, die der Basis-Branch bereits enthält, werden auch ohne Attribut übersprungen. Um eines prüfen zu lassen, markiere es als -linguist-generated. HeyDeer behandelt diese Dateinamen in jedem Ordner als Lockfiles: package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, bun.lock, bun.lockb, deno.lock, Cargo.lock, go.sum, Gemfile.lock, composer.lock, poetry.lock, Pipfile.lock, uv.lock, pdm.lock, pubspec.lock, Podfile.lock, Package.resolved, mix.lock, packages.lock.json, gradle.lockfile, flake.lock, MODULE.bazel.lock, .terraform.lock.hcl
# .gitattributes
src/generated/** linguist-generated
# Review this lock file anyway
Cargo.lock -linguist-generatedWenn alle geänderten Dateien übersprungen werden, zeigt der Check HeyDeer Review „Keine prüfbaren Dateien“, und es werden keine Credits verbraucht.
Was HeyDeer auslässt
Neben generierten Dateien liest HeyDeer Folgendes nicht:
- Issues und Pull Requests in anderen Repositorys.
- Dateien, die AGENTS.md oder CLAUDE.md importiert. Siehe AGENTS.md.
- Agent-Konfiguration im Repository, etwa
.claude/settings.json,.mcp.jsonoder Hooks. Um Prüfungen Kontext von außerhalb zu geben, verwende Connectors. - Ausgaben deines Codes. HeyDeer liest Code und Tests, baut oder führt sie aber nicht aus.
HeyDeer begrenzt den Diskussionskontext auf etwa 180 KB und 200 Unterhaltungen zum Code. Zuerst lässt HeyDeer ältere Prüfungen und erledigte Unterhaltungen weg, bei Bedarf auch weitere Diskussionen. Eine umfangreiche Diskussion verhindert keine Prüfung.
Die Größenlimits für AGENTS.md, Repository-Prüfungen, Skills, Prüfanweisungen und Connectors findest du unter Einstellungsreferenz.