Die Assistenten Ihrer Entwickler – etwa Claude Code, Codex und Cursor – sowie die Agenten von Coroid lesen dieselben AGENTS.md. Der Großteil davon dient beiden: die Befehle, die Konventionen und die Grenzen. Der Teil, der nicht gemeinsam genutzt wird, ist der Git-Workflow, denn Coroid erstellt den Branch, den Commit und den Pull-Request selbst.
Was die Agenten von Coroid lesen
Vor jeder Aufgabe lesen die Agenten von Coroid die Speicherdateien im Wurzelverzeichnis des Repositories: AGENTS.md, CLAUDE.md, GEMINI.md und die Regeln von Cursor in
.cursor/rules. Sie folgen @ Importen, und identische Anweisungen werden nur einmal eingefügt. Wählen Sie aus, welche Quellen die Agenten unter
Einstellungen → Wissen → Kontext. Siehe Projektkontext.
Eine Aufgabe liest die Dateien aus ihrem eigenen Checkout, sodass eine Änderung an AGENTS.md
anwendbar ist auf die Aufgaben, die nach dem Erreichen des Basis-Branches beginnen.
Was beiden dient
Schreiben Sie diese Angaben einmal für jeden Agenten:
- Befehle: installieren, erstellen, testen sowie der engste sinnvolle Test, etwa für ein Paket oder eine Datei. Überprüfen Sie sie aus einem sauberen Klon heraus und geben Sie das Verzeichnis an, in dem sie ausgeführt werden sollen, sowie die Dienste, die die Tests benötigen.
- Konventionen, die der Code nicht zeigt: Benennung, Fehlerbehandlung, wie Zeichenfolgen übersetzt werden und welche Muster verboten sind.
- Grenzen: gesperrte Module, Pfade, die ein Team verwaltet, Abhängigkeiten, die nicht hinzugefügt werden dürfen, sowie Dateien, die niemals manuell bearbeitet werden sollen.
Halten Sie es kurz. Jede Zeile wird bei jeder Aufgabe von jedem Agenten gelesen. Verlinken Sie zu einem ausführlicheren Dokument statt es einzufügen und lassen Sie das weg, was der Code bereits zeigt.
Was Coroid selbst übernimmt
Die Agenten von Coroid ändern Dateien in einer Sandbox. Coroid übernimmt den Rest:
| Schritt | In Coroid |
|---|---|
| Branch | Coroid erstellt pro Aufgabe einen: feature/coroid-<id>-<title>, oder bugfix/, refactor/, test/ oder docs/ je nach Art der Arbeit. Die Spuren eines Plans verwenden coroid/factory/… |
| Commit | Coroid schreibt die Commit-Nachricht und fügt Provenienz-Angaben wie Coroid-Task. Wenn Ihr angeschlossenes Konto der Autor ist, fügt es Co-authored-by: Coroid <ai@coroid.ai> |
| Push | Coroid übertragt den Branch. Die Sandbox lehnt git push, git pull, git fetch und git clone, und speichert keine Zugangsdaten für Ihren Provider. |
| Pull-Request | Coroid öffnet ihn, betitelt nach der Aufgabe, mit einer Beschreibung, die die Aufgabe, ihre Akzeptanzkriterien sowie die Ergebnisse der QA und der Überprüfung verlinkt. |
Anweisungen wie „Arbeiten Sie in einem ws/ Branch“, „Öffnen Sie die pull request mit
gh pr create" oder „Enden Sie jeden Commit mit einer Mitautoren-Zeile“ gelten innerhalb von Coroid nicht. Nur die von einem Agenten geänderten Dateien verlassen die Sandbox; ein dort erstellter Branch oder Commit wird daher verworfen. Coroid weist seine Agenten vor den von Ihnen vorgegebenen Instruktionsdateien darauf hin: Sie überspringen diese Schritte und folgen dem Rest.
Nichts wird in Ihren Basis-Branch committet: siehe Repository- und Branch-Einstellungen.
Geben Sie an, welche Teile wo gelten
Die Agenten von Coroid überspringen Ihren Git-Workflow bereits. Dies in der Datei zu erwähnen hilft jedem Leser – einschließlich Menschen – und hält einen auf Coroid beschränkten Schritt, etwa eine Prüfung vor dem Abschluss, an einem Ort. Fügen Sie einen kurzen Abschnitt ganz oben ein:
## Working in Coroid
When you run inside Coroid, Coroid creates the branch, commits, pushes and
opens the pull request. Change files only, and skip "Git workflow" below.
Before you finish, run `npm run validate`.Markieren Sie anschließend den lokalen Workflow als das, was er ist:
## Git workflow (local agents)
- Branch: `ws/<nn>-<name>` from `main`, in your own worktree.
- Commit messages end with your assistant's co-author line.
- Run `npm run check:local`, then open the pull request with `gh pr create`.Die Assistenten Ihrer Entwickler behalten ihren Workflow bei, und niemand muss raten, welche Schritte wem gehören.
Prüfungen, die jeder pull request bestehen muss
Eine Prüfung, die nur in AGENTS.md ausgeführt wird, wenn ein Agent sie ausführen möchte.
Die Commits von Coroid überspringen außerdem die Git-Hooks Ihres Repositories, etwa Husky oder Pre-commit. Eine Prüfung, die für jede Änderung gelten muss, gehört in
Qualitätskontrolle als Repository-Befehl Prüfung:
- Coroid führt sie auf den von seinen Agenten vorgenommenen Änderungen aus.
- Mit aktivierten pull request-Prüfungen wird sie auch bei den Pull-Requests ausgeführt, die Ihr Team öffnet – einschließlich solcher, die mit Claude Code, Codex oder Cursor erstellt wurden.
Beide Arbeitsweisen erfüllen dann denselben Standard. Siehe Qualitätsrichtlinien und -schranken.
Für die Anti-Slop-Regeln kann ein Entwickler-Assistent über MCP bei Coroid danach fragen. anti_slop_rules gibt einen Auszug zurück, der die Regeln des Projekts für
AGENTS.md: siehe
Anti-Slop-Regeln aus Ihrem Editor.
CI, die nur für bestimmte Branches ausgeführt wird
Wenn Ihre CI oder Branch-Schutz nur für bestimmte Branch-Namen ausgeführt wird, fügen Sie die von Coroid hinzu:
feature/coroid-*
bugfix/coroid-*
refactor/coroid-*
test/coroid-*
docs/coroid-*
coroid/factory/**Andernfalls werden die Pull-Requests von Coroid ohne die Prüfungen geöffnet, auf die Ihr Team angewiesen ist.
Eine Datei für jedes Tool
Halten Sie die Anweisungen an einem Ort auf: AGENTS.md:
- Codex und Cursor lesen
AGENTS.md. - Claude Code liest
CLAUDE.md. Erstellen Sie daraus eine einzige@AGENTS.mdZeile – sowie alles, was Claude Code benötigt. - Cursor liest seine Regeln ebenfalls in
.cursor/rules. Coroid liest sie, während Cursor sie anwendet: siehe Projektkontext.
Coroid liest CLAUDE.md mittels Import und schließt es ein AGENTS.md einmal.
Überprüfen Sie, was Coroid liest
Unter Einstellungen → Wissen → Kontext, Repository-Quellen listet jede Datei mit einer geschätzten Tokenanzahl sowie einem Schalter auf. Bearbeiten öffnet dort eine Datei. Beim Speichern wird ein pull request in einem verbundenen Repository erstellt, sodass die Änderung denselben Prüfungsprozess durchläuft wie jede andere auch.