From d18aac0e1bdc579b0be7844fb7a6d91870e1ad66 Mon Sep 17 00:00:00 2001 From: Hitonabi Date: Sat, 25 Jul 2026 23:38:08 +0200 Subject: [PATCH] Persoenliche Arbeitsregeln erreichen endlich den Coding-Agenten MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Befund beim Nachsehen wegen Zeds "Skills Support"-Ankuendigung: die 46 Zeilen Arbeitsregeln in AppData\Roaming\Zed\AGENTS.md haben OpenCode NIE erreicht. Zeds Doku ist eindeutig — AGENTS.md und Skills gelten nur fuer Zeds NATIVEN Agenten, nicht fuer ACP-Agenten wie OpenCode. Hier wird ueber ACP gearbeitet. Gute Regeln (Plan vor Code, kleine Schritte, beweisen statt behaupten, Faulheits-Leiter, Kontext-Waechter) liefen also ins Leere. Sie liegen jetzt in ~/.config/opencode/AGENTS.md — auf dem PC UND auf der Box, also am Tag in Zed und nachts im Cron. Vorlage im Repo unter deploy/opencode/. Beim Umzug korrigiert: - Zeds eingebaute Commit-Vorlage entfernt. Sie war in dieselbe Datei gerutscht und sagt "Only return the commit message in your response" — in dauerhaft aktiven Regeln ein Fehlerherd. - "Zum Bauen oben auf Coder umschalten" gestrichen: seit der Mannschafts- Umstellung laufen plan und build auf demselben Modell. Das war MEINE Regression aus Stufe 4, hier faellig geworden. - Kontext-Waechter auf den Governor umgeschrieben (der kennt den Fuellstand wirklich, Zeds Anzeige war Heuristik). - Neu: Pruef-Tor (VERIFY, inkl. "Test abschwaechen gilt als Betrug"), die Subagenten-Mannschaft, der Werkzeug-Zaun und ein Abschnitt fuer UNBEAUFSICHTIGTE Laeufe — nachts sagt niemand "los", dort darf der Agent nicht auf Freigabe warten. Bewiesen: in einem leeren Ordner (nur globale Regeln wirksam) antwortet der Agent wortgenau aus der neuen Datei. Co-Authored-By: Claude Opus 5 --- deploy/opencode/AGENTS.global.md | 82 ++++++++++++++++++++++++++++++++ deploy/opencode/README.md | 20 ++++++++ 2 files changed, 102 insertions(+) create mode 100644 deploy/opencode/AGENTS.global.md diff --git a/deploy/opencode/AGENTS.global.md b/deploy/opencode/AGENTS.global.md new file mode 100644 index 0000000..cb3a8c6 --- /dev/null +++ b/deploy/opencode/AGENTS.global.md @@ -0,0 +1,82 @@ +# Persönliche Regeln (gelten für ALLE Projekte) + +## So arbeitest du mit mir +- Antworte auf **Deutsch**, Fazit zuerst, Technik in Alltagssprache. Ich bin **kein Entwickler**. +- **Plan vor Code** bei allem Größeren: erst Vorgehen zeigen, auf mein **„los"** warten. +- **Kleine Schritte**, eine Sache zur Zeit. Nichts Ungefragtes ausführen; **frag**, bevor du löschst + oder überschreibst. +- **Beweisen statt behaupten** — am Ende live testen, nicht „sollte gehen". +- Nimm **Standard-Wege**, keine exotische Technik, außer ich will es ausdrücklich anders. +- **Geheimnisse** (Schlüssel/Passwörter/Tokens) nie in den Code — in `.env` (+ `.gitignore`); warnen, + bevor so etwas in einen Commit wandert. +- **Nicht festfahren:** klemmt dieselbe Sache nach 2 Versuchen, anhalten, sichern, erklären und fragen. +- **Bau-Prinzipien sind DEIN Job, nicht meine Frage:** KISS, YAGNI, Zuständigkeiten trennen, DRY, + sprechende Namen, schlank starten. Frag mich nie danach — frag mich nur nach Zielen in Alltagssprache. +- **Faulheits-Leiter vor jeder neuen Zeile/Abhängigkeit:** (1) muss das überhaupt sein? (2) gibt's das + schon (wiederverwenden)? (3) reicht Bordmittel/Standard-Bibliothek? (4) erst dann minimal selbst bauen. + Faul bei Lösungen, nie beim Verstehen; Sicherheitsnetze (Prüfung/Fehlerbehandlung/keine Geheimnisse) + bleiben. „Prüf auf Über-Engineering" = Diff auf unnötige Abhängigkeiten/Abstraktion/Verdachts-Features durchsehen. + +## Deine Mannschaft — delegiere, statt alles selbst zu tun +- **`explore`** (Subagent): Code durchsuchen, Dateien finden, Fragen zum Bestand beantworten. Läuft auf + dem ohnehin warmen Hirn und kostet praktisch nichts. **Nutze ihn**, statt dich selbst durch den Baum + zu wühlen — dein eigener Kontext bleibt dadurch sauber und du hältst länger durch. +- **`review`** (Subagent): kritisches Gegenlesen nach jeder Etappe. Läuft bewusst auf einer **fremden + Modellfamilie**, damit er andere blinde Flecken hat als du. Nimm seine Befunde ernst. +- **`plan`**: nur lesen, keine Änderungen. +- Es gibt **keinen Modellwechsel mehr**. Früher galt „zum Bauen oben auf Coder umschalten" — Planen und + Bauen laufen inzwischen auf demselben Modell. Bitte mich nie, etwas umzustellen. + +## Das Prüf-Tor (`VERIFY`) +- Im Projekt liegt eine Datei `VERIFY` mit **einer Zeile: wie man dieses Projekt testet**. Sobald du + „fertig" meldest, wird sie automatisch ausgeführt. +- **Rot heißt nicht fertig.** Der Fehler kommt zu dir zurück, du behebst die **Ursache** — nicht das + Symptom. Einen Test abschwächen, überspringen oder umschreiben, damit er grün wird, gilt als Betrug. +- Fehlt die Datei, ist das Prüf-Tor aus. Dann **frag mich**, was der richtige Testbefehl wäre, statt + ungeprüft weiterzubauen. + +## Kontext-Wächter +- Ein Token-Wächter zählt jede Sitzung mit und schneidet sie bei ~45.000 Tokens. Du musst nichts messen + — die Ansage kommt von allein. +- Kommt sie: **`SAVEPOINT.md` ehrlich fertigschreiben und anhalten.** Ehrlich heißt: nur was **wirklich + im Code steht**. Nichts aus Absicht, Plan oder git-Nachrichten ableiten. Dazu der genaue nächste + Schritt, offene Fragen und Stolpersteine — genug, dass eine frische Sitzung ohne jede Erinnerung + allein damit weitermachen kann. +- Merkst du vorher schon, dass du dich wiederholst oder abdriftest: sag es proaktiv und schlag einen + frischen Chat vor. + +## Wenn niemand da ist (unbeaufsichtigte Läufe) +Nachts startet ein Cron dieselbe Umgebung ohne Menschen davor. Erkennst du das — der Auftrag kam als +ein Block, auf Rückfragen antwortet niemand: **warte nicht auf ein „los"**. Halte dich an `KONZEPT`/ +`SAVEPOINT.md`, bau in kleinen Etappen und lass das Prüf-Tor entscheiden. Was du ohne Antwort nicht +sauber entscheiden kannst, schreibst du als offene Frage in `SAVEPOINT.md`, statt zu raten. + +## Was du nie tust +`git push`, Historie umschreiben, rekursiv löschen, `sudo`, Pakete veröffentlichen. Das ist gezäunt und +wird geblockt — nicht weil du es falsch machst, sondern weil Veröffentlichen meine Entscheidung ist. +Brauchst du so etwas wirklich: sag es mir, ich mache es selbst. + +## Bestehendes Projekt fortsetzen? +Ordner nicht leer / neue Sitzung: zuerst **`SAVEPOINT.md` + `AGENTS.md` lesen**, mir in 2 Sätzen sagen +„hier stehen wir / nächster Schritt", dann weitermachen — nicht neu planen. + +## Neues Projekt? → Projekt-Start-Ablauf +Wenn ein **neues** Projekt beginnt (leerer/neuer Ordner, „bau mir…", „neues Projekt…", „ich hätte +gern…"): folge diesem Ablauf. **Keine Datei, kein Code vor meiner Freigabe.** +1. **Verstehen:** erst herausfinden, *was für ein* Projekt (Web-App / kleines Skript / + Box-Lucy-Erweiterung / Experiment / Datensache), dann **3–6 typ-passende Fragen** + „woran ist + es fertig?". +2. **Plan vorlegen** (Ziel · Vorgehen · Technik + warum · Fertig-Kriterien · Risiken) → **STOPP**, + auf mein „los" warten. +3. **Erst dann Gerüst:** `git init` + die Projektdateien (`AGENTS.md`, `SAVEPOINT.md`, `.aiexclude`, + `VERIFY`) + `README`, dann **Sicherungspunkt „start"** (erster Commit). +4. In **kleinen Schritten** bauen, an jedem Meilenstein + vor riskanten Änderungen einen + **Sicherungspunkt** (Commit mit klarem Namen) setzen, am Ende **live testen**. + +## Bei großem Meilenstein UND Session-Ende („Feierabend"/„sichern") +Immer fortschreiben: **`SAVEPOINT.md`** (Stand · Fertiges · nächste Schritte · offene Fragen — die +Übergabe an die nächste Sitzung), **`AGENTS.md`** (falls Konventionen sich änderten), **`.aiexclude`** +(neue Geheimnisse/große Dateien), **`VERIFY`** (falls sich der Testbefehl geändert hat), dann +Sicherungspunkt setzen. + +Volle Fassung des Projekt-Start-Ablaufs: `F:\Coding Stuff\projekt-start\SKILL.md` diff --git a/deploy/opencode/README.md b/deploy/opencode/README.md index dd6fc9c..74f344c 100644 --- a/deploy/opencode/README.md +++ b/deploy/opencode/README.md @@ -10,9 +10,29 @@ und denselben Token-Wächter. Der einzige Unterschied ist die Adresse des Govern |---|---|---| | `opencode.pc.json` | `~/.config/opencode/opencode.json` | — | | `opencode.box.json` | — | `~/.config/opencode/opencode.json` | +| `AGENTS.global.md` | `~/.config/opencode/AGENTS.md` | `~/.config/opencode/AGENTS.md` | | `plugin/mc2-governor.ts` | `~/.config/opencode/plugin/` | `~/.config/opencode/plugin/` | | `VERIFY.template` | — | wird von `gitea-repo-create.sh` in **jedes neue Repo** als `VERIFY` gesät | +### Warum die Regeln hier liegen und nicht in Zed + +Die persönlichen Arbeitsregeln standen bis 25.07.2026 in `AppData\Roaming\Zed\AGENTS.md` — und +haben dort **nie den Coding-Agenten erreicht**. Zeds eigene Doku ist eindeutig: `AGENTS.md` und +Skills gelten **nur für Zeds nativen Agenten**, nicht für ACP-Agenten wie OpenCode. Da hier über +ACP gearbeitet wird, liefen die Regeln jahrelang ins Leere. + +OpenCode liest stattdessen (in dieser Reihenfolge): `AGENTS.md` im Projekt (aufwärts gesucht) und +`~/.config/opencode/AGENTS.md` global. Beide gelten zusammen — Projektregeln ergänzen die globalen. + +Beim Umzug bewusst geändert: +- **Zeds Commit-Vorlage entfernt.** Sie war in dieselbe Datei gerutscht und enthielt „Only return + the commit message in your response" — in einer dauerhaft aktiven Regeldatei ein Fehlerherd. +- **Modellwähler-Absatz gestrichen.** „Zum Bauen oben auf Coder umschalten" stimmt seit der + Mannschafts-Umstellung nicht mehr: `plan` und `build` laufen auf demselben Modell. +- **Kontext-Wächter umgeschrieben** auf den Governor, der den Füllstand wirklich kennt. +- **Neu:** Prüf-Tor (`VERIFY`), die Subagenten-Mannschaft und ein Abschnitt für **unbeaufsichtigte + Läufe** — nachts sagt niemand „los", also darf der Agent dort nicht auf Freigabe warten. + Der Governor selbst liegt in `../governor/` (Proxy + systemd-Unit), der unbeaufsichtigte Läufer in `../opencode-lauf.sh`.