CommunityCoding & Developmentgithub.com

jhincapie/egm-cursor

Maintainer-only. Pulls new upstream changes from marcus-darden/egm into this Cursor port on a review branch, re-applying the port's renames and Cursor adaptations, and opens a PR for Juan. Run only when typed as /egm-sync-upstream.

What is egm-cursor?

egm-cursor is a Claude Code agent skill that maintainer-only. Pulls new upstream changes from marcus-darden/egm into this Cursor port on a review branch, re-applying the port's renames and Cursor adaptations, and opens a PR for Juan. Run only when typed as /egm-sync-upstream.

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

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

Ask in your favorite AI

Open a new chat with this agent skill pre-loaded.

Documentation

EGM sync upstream

Bring changes from marcus-darden/egm into this port without losing the port's renames, Cursor adaptations or port-only files. Read the repo-root AGENTS.md first: it is the rule book this skill applies. This skill lives in .cursor/skills/ so it is project-local; install.sh never installs it.

Invoke as /egm-sync-upstream [--dry-run] [upstream-ref]. upstream-ref defaults to upstream main. With --dry-run, do Steps 1 to 4 and print the plan; change nothing.

Hard rules

  1. Never push to main. All work happens on sync/upstream-<shortsha>; Juan merges the PR.
  2. Never overwrite a port-only file (list in AGENTS.md). If upstream changed something those files mirror (for example the upstream README's install section), describe it in the report instead.
  3. Don't guess. New upstream skills or agents, deleted upstream files, renamed upstream files and merge conflicts are flagged for Juan with the exact paths, not resolved by inventing a name or picking a side.
  4. Keep attribution. LICENSE keeps both copyright lines; UPSTREAM_COMMIT moves only when the branch actually contains the upstream changes.

Helpers

<skill-dir> is the folder holding this file.

  • python3 <skill-dir>/scripts/port_names.py path <upstream-path>... maps upstream paths to port paths and says when a path is port-only, not ported, or new.
  • python3 <skill-dir>/scripts/port_names.py merge <clone> <old> <new> <upstream-path> [--write] three-way merges one upstream file change into its port file (base and theirs are rewritten into port names first, ours is the port file), so Cursor adaptations in untouched lines survive. Exit 0 clean, 1 conflict markers left in, 3 nothing to do (port-only, not ported, or new).
  • python3 <skill-dir>/scripts/port_names.py rewrite <file> / check <file>... rewrite names in text, or list leftover old slash names.
  • bash <skill-dir>/scripts/check_port.sh runs every port check (Step 7).

Workflow

EGM sync progress:
- [ ] Step 1: working tree clean, on an up-to-date main
- [ ] Step 2: upstream cloned to a temp dir; old = UPSTREAM_COMMIT, new = upstream HEAD
- [ ] Step 3: CHANGELOG entries since old read; changed files listed with status
- [ ] Step 4: every changed file mapped and classified (merge / flag / skip)
- [ ] Step 5: branch sync/upstream-<shortsha> created; merges applied; adaptations re-checked
- [ ] Step 6: UPSTREAM_COMMIT updated
- [ ] Step 7: check_port.sh passes
- [ ] Step 8: SYNC-REPORT.md written
- [ ] Step 9: branch pushed; PR opened with gh; Juan told

Step 1: Clean start

git status --porcelain must be empty and the current branch main, up to date with origin/main (git fetch origin && git status -sb). If not, stop and tell Juan what is dirty. Do not stash his work.

Step 2: Fetch upstream

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})"

If old == new, report "upstream has no new commits since " and stop (no branch, no PR). If old is not an ancestor of new (git -C "$tmp/upstream" merge-base --is-ancestor $old $new), upstream rewrote history: stop and flag it.

Step 3: Read what changed

  • git -C "$tmp/upstream" log --oneline $old..$new
  • git -C "$tmp/upstream" diff --name-status -M $old $new
  • The new CHANGELOG.md entries (tags after the one containing old). The CHANGELOG explains why; quote the relevant rows in the report.

Step 4: Map and classify each file

Run port_names.py path on every changed upstream path, then put each in one bucket:

Upstream status and mappingBucket
M, maps to an existing port filemerge
A, maps into a known skill folder (for example a new asset in skills/goldfish/)merge (creates the file)
A, new skill, agent or walkthrough ("NEW" note)flag: Juan picks the egm- name and whether to port it
D (deleted upstream)flag: do not delete the port file
R (renamed upstream)flag: show old and new paths and the port path
port-only or not-ported noteskip (describe the change if it matters, such as README install text)
LICENSEmerge, then confirm both copyright lines remain

With --dry-run, print this table and the commit list, then stop.

Step 5: Apply on a branch

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

Run the merge once per merge file. On exit 1, leave the conflict markers out of the commit: restore the file (git checkout -- <port-path>), and record the conflict hunk in the report for Juan. After merging, re-read each touched file for the Cursor adaptations listed in AGENTS.md (Task-tool spawn text, readonly: true in agents, AGENTS.md alongside CLAUDE.md, reviewers ignoring AGENTS.md and .cursor/rules/, /review not /code-review, the Cursor row in runtimes.md). If upstream added a new place that needs one (for example a new CLAUDE.md lookup, a new tools: line in an agent, a new Claude-only spawn instruction), apply the same adaptation and list it under "adapted". Commit in logical groups with messages that cite upstream commits.

Step 6: Move the pointer

Write new to UPSTREAM_COMMIT only if every merge file merged cleanly or its conflict is recorded. Commit it last.

Step 7: Check

bash <skill-dir>/scripts/check_port.sh. It checks name equals folder, eval JSON, check_gate.py (BLOCKED then GO), leftover old slash names, and a test install to a temp dir (which must not contain this skill). Fix failures caused by the merge; anything else goes in the report.

Step 8: SYNC-REPORT.md

Write SYNC-REPORT.md at the repo root on the branch, and use the same text as the PR body:

# Upstream sync: <old7>..<new7>

Upstream commits: <list>
CHANGELOG: <quoted rows>

## Applied
- <port path> <- <upstream path>: <one line>
## Adapted for Cursor
- <port path>: <which adaptation and why>
## Skipped
- <upstream path>: <port-only | not ported>, <what changed, if it matters>
## Flagged for Juan
- <new skill/agent, deletion, rename, conflict>: <paths, the hunk, the question>
## Checks
<check_port.sh summary>
## Open questions
- <...>

Step 9: Push and open the PR

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

Tell Juan the PR URL, the counts (applied, adapted, skipped, flagged), and the flagged items. Do not merge the PR. Remove the temp clone.

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.

Related Skills