CommunityCodierung & Entwicklunggithub.com

jhincapie/egm-cursor

Nur für Maintainer. Übernimmt neue Änderungen von marcus-darden/egm in diesen Cursor-Port auf einem Review-Branch, wendet die Umbenennungen und Cursor-Anpassungen des Ports erneut an und öffnet einen PR für Juan. Nur ausführen, wenn als /egm-sync-upstream getippt.

Was ist egm-cursor?

Diese Fähigkeit (Skill) ist ein spezialisiertes Wartungswerkzeug für den Cursor-Port des EGM-Projekts. Ihr alleiniger Zweck ist es, neue Upstream-Änderungen aus dem ursprünglichen Repository von marcus-darden/egm in diesen Port zu integrieren, ohne dabei die projektspezifischen Umbenennungen, Cursor-Anpassungen oder Dateien, die nur im Port existieren, zu verlieren. Sie ist für die Verwendung mit KI-Agenten wie Claude Code, Cursor oder Codex konzipiert und stellt strenge Regeln auf, um Konflikte zu vermeiden und die Integrität des Ports zu wahren. So wird zum Beispiel niemals in den `main`-Branch gepusht, und Änderungen an port-exklusiven Dateien werden gemeldet, aber nicht überschrieben. Die Fähigkeit automatisiert den gesamten Sync-Prozess: Sie klont das Upstream-Repository, analysiert die Änderungen, wendet Drei-Wege-Merges mit Hilfe von Hilfsskripten an und erstellt einen detaillierten Bericht sowie einen Pull-Request. Sie wird über den Befehl `/egm-sync-upstream` aufgerufen und unterstützt einen `--dry-run`-Modus zur Vorschau.

Funktioniert mit✓Claude Code~Codex CLI✓Cursor
npx skills add https://github.com/jhincapie/egm-cursor/tree/HEAD/.cursor/skills/egm-sync-upstream

Installed? Explore more Codierung & Entwicklung skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

EGM-Sync-Upstream

Änderungen von marcus-darden/egm in diesen Port übernehmen, ohne die Umbenennungen, Cursor-Anpassungen oder port-exklusiven Dateien des Ports zu verlieren. Lies zuerst die AGENTS.md im Repository-Stammverzeichnis: Sie ist das Regelwerk, das dieser Skill anwendet. Dieser Skill befindet sich in .cursor/skills/, ist also projektlokal; install.sh installiert ihn nie.

Aufruf als /egm-sync-upstream [--dry-run] [upstream-ref]. upstream-ref standardmäßig auf upstream main. Mit --dry-run werden die Schritte 1 bis 4 ausgeführt und der Plan ausgegeben; es wird nichts geändert.

Strenge Regeln

  1. Nie in main pushen. Alle Arbeiten finden auf sync/upstream-<shortsha> statt; Juan merged den PR.
  2. Nie eine port-exklusive Datei überschreiben (Liste in AGENTS.md). Hat Upstream etwas geändert, das diese Dateien spiegeln (z. B. den Installationsabschnitt der upstream README), beschreibe es stattdessen im Bericht.
  3. Nicht raten. Neue Upstream-Skills oder -Agenten, gelöschte Upstream-Dateien, umbenannte Upstream-Dateien und Merge-Konflikte werden für Juan mit den genauen Pfaden markiert, nicht durch Erfinden eines Namens oder Auswählen einer Seite gelöst.
  4. Namensnennung beibehalten. LICENSE behält beide Copyright-Zeilen; UPSTREAM_COMMIT wird nur verschoben, wenn der Branch die Upstream-Änderungen tatsächlich enthält.

Hilfsmittel

<skill-dir> ist der Ordner, der diese Datei enthält.

  • python3 <skill-dir>/scripts/port_names.py path <upstream-path>... bildet Upstream-Pfade auf Port-Pfade ab und sagt, wenn ein Pfad port-exklusiv, nicht portiert oder neu ist.
  • python3 <skill-dir>/scripts/port_names.py merge <clone> <old> <new> <upstream-path> [--write] führt einen Drei-Wege-Merge einer Upstream-Dateiänderung in ihre Port-Datei durch (Basis und ihre werden zuerst in Port-Namen umgeschrieben, unsere ist die Port-Datei), sodass Cursor-Anpassungen in unberührten Zeilen erhalten bleiben. Exit 0 sauber, 1 Konfliktmarkierungen hinterlassen, 3 nichts zu tun (port-exklusiv, nicht portiert oder neu).
  • python3 <skill-dir>/scripts/port_names.py rewrite <file> / check <file>... schreibt Namen im Text um oder listet übrig gebliebene alte Schrägstrich-Namen auf.
  • bash <skill-dir>/scripts/check_port.sh führt alle Port-Prüfungen aus (Schritt 7).

Arbeitsablauf

EGM-Sync-Fortschritt:
- [ ] Schritt 1: Arbeitsverzeichnis sauber, auf einem aktuellen main
- [ ] Schritt 2: Upstream in ein temporäres Verzeichnis geklont; old = UPSTREAM_COMMIT, new = upstream HEAD
- [ ] Schritt 3: CHANGELOG-Einträge seit old gelesen; geänderte Dateien mit Status aufgelistet
- [ ] Schritt 4: Jede geänderte Datei kartiert und klassifiziert (merge / flag / skip)
- [ ] Schritt 5: Branch sync/upstream-<shortsha> erstellt; Merges angewendet; Anpassungen erneut geprüft
- [ ] Schritt 6: UPSTREAM_COMMIT aktualisiert
- [ ] Schritt 7: check_port.sh erfolgreich
- [ ] Schritt 8: SYNC-REPORT.md geschrieben
- [ ] Schritt 9: Branch gepusht; PR mit gh geöffnet; Juan benachrichtigt

Schritt 1: Sauberer Start

git status --porcelain muss leer und der aktuelle Branch main muss auf dem neuesten Stand mit origin/main sein (git fetch origin && git status -sb). Wenn nicht, anhalten und Juan mitteilen, was schmutzig ist. Seine Arbeit nicht stashen.

Schritt 2: Upstream holen

tmp="$(mktemp -d)"
git clone --quiet https://github.com/marcus-darden/egm.git "$tmp/upstream"
old="$(cat UPSTREAM_COMMIT)"; new="$(git -C "$tmp/upstream" rev-parse ${REF:-HEAD})"

Wenn old == new, melde „upstream hat seit keine neuen Commits“ und halte an (kein Branch, kein PR). Wenn old kein Vorfahre von new ist (git -C "$tmp/upstream" merge-base --is-ancestor $old $new), hat Upstream die Geschichte umgeschrieben: anhalten und markieren.

Schritt 3: Lesen, was sich geändert hat

  • git -C "$tmp/upstream" log --oneline $old..$new
  • git -C "$tmp/upstream" diff --name-status -M $old $new
  • Die neuen CHANGELOG.md-Einträge (Tags nach dem, der old enthält). Das CHANGELOG erklärt warum; zitiere die relevanten Zeilen im Bericht.

Schritt 4: Jede Datei kartieren und klassifizieren

Führe port_names.py path für jeden geänderten Upstream-Pfad aus und ordne ihn dann in einen der folgenden Eimer ein:

Upstream-Status und KartierungEimer
M, kartiert auf eine bestehende Port-Dateimerge
A, kartiert in einen bekannten Skill-Ordner (z. B. ein neues Asset in skills/goldfish/)merge (erstellt die Datei)
A, neuer Skill, Agent oder Walkthrough („NEU“-Hinweis)flag: Juan wählt den egm--Namen und ob portiert werden soll
D (gelöscht upstream)flag: die Port-Datei nicht löschen
R (umbenannt upstream)flag: zeige alte und neue Pfade sowie den Port-Pfad
port-exklusiv oder nicht-portiert-Hinweisskip (beschreibe die Änderung, falls sie relevant ist, z. B. README-Installationstext)
LICENSEmerge, dann bestätigen, dass beide Copyright-Zeilen erhalten bleiben

Mit --dry-run diese Tabelle und die Commit-Liste ausgeben, dann anhalten.

Schritt 5: Auf einem Branch anwenden

git switch -c "sync/upstream-${new:0:7}"
python3 <skill-dir>/scripts/port_names.py merge "$tmp/upstream" $old $new <upstream-path> --write

Führe den Merge einmal pro merge-Datei aus. Bei Exit 1 die Konfliktmarkierungen aus dem Commit lassen: die Datei wiederherstellen (git checkout -- <port-path>) und das Konfliktstück im Bericht für Juan festhalten. Nach dem Merge jede bearbeitete Datei erneut auf die in AGENTS.md aufgeführten Cursor-Anpassungen lesen (Task-Tool-Spawn-Text, readonly: true in Agenten, AGENTS.md neben CLAUDE.md, Rezensenten ignorieren AGENTS.md und .cursor/rules/, /review nicht /code-review, die Cursor-Zeile in runtimes.md). Wenn Upstream eine neue Stelle hinzugefügt hat, die eine solche Anpassung benötigt (z. B. eine neue CLAUDE.md-Suche, eine neue tools:-Zeile in einem Agenten, eine neue Claude-only-Spawn-Anweisung), dieselbe Anpassung anwenden und unter „angepasst“ aufführen. In logischen Gruppen committen mit Nachrichten, die auf Upstream-Commits verweisen.

Schritt 6: Den Zeiger verschieben

Schreibe new in UPSTREAM_COMMIT nur, wenn jede merge-Datei sauber gemergt wurde oder ihr Konflikt festgehalten ist. Committe dies zuletzt.

Schritt 7: Prüfen

bash <skill-dir>/scripts/check_port.sh. Es prüft Name gleich Ordner, JSON auswerten, check_gate.py (BLOCKED dann GO), übrig gebliebene alte Schrägstrich-Namen und eine Testinstallation in ein temporäres Verzeichnis (das diesen Skill nicht enthalten darf). Fehler beheben, die durch den Merge verursacht wurden; alles andere kommt in den Bericht.

Schritt 8: SYNC-REPORT.md

Schreibe SYNC-REPORT.md im Repository-Stammverzeichnis auf dem Branch und verwende denselben Text wie den PR-Textkörper:

# Upstream-Sync: <old7>..<new7>

Upstream-Commits: <Liste>
CHANGELOG: <zitierte Zeilen>

## Angewendet
- <Port-Pfad> <- <Upstream-Pfad>: <eine Zeile>
## Für Cursor angepasst
- <Port-Pfad>: <welche Anpassung und warum>
## Übersprungen
- <Upstream-Pfad>: <port-exklusiv | nicht portiert>, <was sich geändert hat, falls relevant>
## Für Juan markiert
- <neuer Skill/Agent, Löschung, Umbenennung, Konflikt>: <Pfade, das Stück, die Frage>
## Prüfungen
<check_port.sh-Zusammenfassung>
## Offene Fragen
- <...>

Schritt 9: Pushen und PR öffnen

git push -u origin "sync/upstream-${new:0:7}"
gh pr create --base main --head "sync/upstream-${new:0:7}" --title "Sync upstream marcus-darden/egm ${old:0:7}..${new:0:7}" --body-file SYNC-REPORT.md

Teile Juan die PR-URL, die Anzahlen (angewendet, angepasst, übersprungen, markiert) und die markierten Elemente mit. Den PR nicht mergen. Das temporäre Klon entfernen.

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

jhincapie/egm-cursor

Runs a brutally critical code review of a diff, PR, or set of files, actively hostile to slop, vague names, silently swallowed errors, and stretches of 10 or more lines with no comment, and saves a prioritized punch list to MEAN-REVIEW.md so the next pass can check what was fixed. Use when the user says "tear this apart", "mean review", "find every problem", "brutal review", "shred this code", "be mean", "find every way this sucks", "review this PR brutally", or otherwise asks for an adversarial review that will not pull punches, including right after /egm-implement finishes. Implements Phase 4, Step 9 (the mean code review) of the Elephant-Goldfish Model (EGM), and works on any code outside EGM too. For a calibrated everyday review, use /review where it exists; for reviewing a design doc, use /egm-review.

jhincapie/egm-cursor

Make an informed non-trivial decision via a three-step interrogation → criteria → research-handoff protocol. Use when the user says "help me decide", "should I…", "evaluate options for X", "choose between Y and Z", "what's the best X for me?", "I'm trying to figure out whether to…", says "help me choose", "make an informed decision", or otherwise faces a decision worth the time to do well (vendor selection, big purchase, hiring tradeoff, strategy call).

jhincapie/egm-cursor

Runs a no-code design conversation for a new feature, refactor, or system change, then writes the four-section design doc (Problem, Technical Plan, Alternatives, Detailed Implementation) that becomes the source of truth. Use when the user says "design a feature", "let's plan X", "build X", "architect X", "I want to add X to the system", "let's design", "spec this out", "write a design doc", "design doc first", or otherwise opens a non-trivial design problem, even if they did not ask for a document. Implements Phases 1 and 2 of the Elephant-Goldfish Model (EGM). Hand the finished doc to /egm-review. Not for one-line fixes or questions about how existing code works.

jhincapie/egm-cursor

Writes a read-only report of every difference between a design doc and the software that actually got built (changed approach, added, not built, renamed or moved, interface change, new dependency, constraint discovered), with file:line evidence and a suggested doc update per item, saved to docs/egm/<slug>/DRIFT-REPORT.md. Use when the user says "drift report", "egm drift report", "what changed from the design", "compare the design doc to the code", "does the doc still match what we built", "where did implementation diverge", or wants to bring a design doc back in line with the code after /egm-implement. Never edits the doc or the code. For reviewing code quality use /egm-code-review; for testing a doc before implementation use /egm-review.

Verwandte Skills