Community코딩 & 개발github.com

jhincapie/egm-cursor

관리자 전용. marcus-darden/egm의 새로운 업스트림 변경 사항을 이 Cursor 포트로 가져와 리뷰 브랜치에서 포트의 리네임과 Cursor 적응을 다시 적용하고 Juan에게 PR을 엽니다. /egm-sync-upstream으로만 실행하세요.

egm-cursor란 무엇인가요?

**EGM Sync Upstream**은 marcus-darden/egm 저장소의 업스트림 변경 사항을 Cursor 기반 포트로 동기화하기 위한 전용 AI 스킬입니다. 이 스킬은 업스트림의 새로운 커밋을 가져오되, 포트 고유의 파일명 변경, Cursor 적응 및 포트 전용 파일을 보존하여 기존 작업이 손실되지 않도록 합니다. 특히 Cursor, Claude Code, Codex와 같은 AI 코딩 도구와 함께 사용하도록 설계되었으며, `.cursor/skills/` 디렉토리에서 프로젝트 로컬로 실행됩니다. 핵심 워크플로우는 깨끗한 작업 트리 확인, 업스트림 저장소 임시 복제, 변경 사항 분석 및 분류, 병합 브랜치 생성 및 병합 적용, 포트 무결성 검사, 최종 보고서 작성, PR 생성을 포함합니다. 충돌, 새로운 스킬/에이전트, 삭제 또는 이름 변경과 같은 모호한 상황은 사람의 판단을 위해 플래그로 표시하여 자동 추측의 위험을 방지합니다. 이 스킬은 `AGENTS.md` 파일에 정의된 엄격한 규칙을 따르며, `--dry-run` 옵션을 지원하여 변경 없이 계획만 미리 볼 수 있으므로 안전한 동기화 프로세스에 이상적입니다.

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

Installed? Explore more 코딩 & 개발 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

EGM 업스트림 동기화

marcus-darden/egm의 변경 사항을 이 포트로 가져오면서 포트의 리네임, Cursor 적응 및 포트 전용 파일을 잃지 않습니다. 먼저 저장소 루트의 AGENTS.md를 읽으십시오. 이 스킬이 적용하는 규칙입니다. 이 스킬은 .cursor/skills/ 디렉토리에 있으므로 프로젝트 로컬입니다. install.sh는 이 스킬을 설치하지 않습니다.

/egm-sync-upstream [--dry-run] [upstream-ref]로 호출합니다. upstream-ref는 기본적으로 upstream main입니다. --dry-run을 사용하면 1~4단계를 수행하고 계획을 출력하며 아무것도 변경하지 않습니다.

엄격한 규칙

  1. 절대 main에 푸시하지 마십시오. 모든 작업은 sync/upstream-<shortsha> 브랜치에서 수행됩니다. Juan이 PR을 병합합니다.
  2. 포트 전용 파일을 절대 덮어쓰지 마십시오 (AGENTS.md에 목록 있음). 업스트림이 해당 파일이 미러링하는 항목(예: 업스트림 README의 설치 섹션)을 변경한 경우, 보고서에 설명만 추가하십시오.
  3. 추측하지 마십시오. 새로운 업스트림 스킬이나 에이전트, 삭제된 업스트림 파일, 이름이 변경된 업스트림 파일 및 병합 충돌은 정확한 경로와 함께 Juan에게 플래그로 표시되며, 이름을 임의로 짓거나 한쪽을 선택하여 해결하지 않습니다.
  4. 저작권 표시를 유지합니다. LICENSE는 두 저작권 라인을 모두 유지합니다. UPSTREAM_COMMIT은 브랜치가 실제로 업스트림 변경 사항을 포함할 때만 이동합니다.

헬퍼

<skill-dir>은 이 파일이 있는 폴더입니다.

  • python3 <skill-dir>/scripts/port_names.py path <upstream-path>...는 업스트림 경로를 포트 경로로 매핑하고 경로가 포트 전용, 포팅되지 않음 또는 새 항목인지 알려줍니다.
  • python3 <skill-dir>/scripts/port_names.py merge <clone> <old> <new> <upstream-path> [--write]는 하나의 업스트림 파일 변경 사항을 포트 파일로 3방향 병합합니다(기본 및 theirs는 먼저 포트 이름으로 다시 작성되고, ours는 포트 파일임). 따라서 변경되지 않은 라인의 Cursor 적응이 유지됩니다. 종료 코드 0: 깔끔함, 1: 충돌 마커가 남음, 3: 수행할 작업 없음(포트 전용, 포팅되지 않음 또는 새 항목).
  • python3 <skill-dir>/scripts/port_names.py rewrite <file> / check <file>...는 텍스트의 이름을 다시 작성하거나 남은 이전 슬래시 이름을 나열합니다.
  • bash <skill-dir>/scripts/check_port.sh는 모든 포트 검사를 실행합니다(7단계).

워크플로우

EGM 동기화 진행 상황:
- [ ] 1단계: 작업 트리 깔끔, 최신 main 브랜치
- [ ] 2단계: 업스트림을 임시 디렉토리에 복제; old = UPSTREAM_COMMIT, new = upstream HEAD
- [ ] 3단계: old 이후의 CHANGELOG 항목 읽기; 변경된 파일을 상태와 함께 나열
- [ ] 4단계: 변경된 모든 파일을 매핑하고 분류(병합 / 플래그 / 건너뛰기)
- [ ] 5단계: sync/upstream-<shortsha> 브랜치 생성; 병합 적용; 적응 재확인
- [ ] 6단계: UPSTREAM_COMMIT 업데이트
- [ ] 7단계: check_port.sh 통과
- [ ] 8단계: SYNC-REPORT.md 작성
- [ ] 9단계: 브랜치 푸시; gh로 PR 열기; Juan에게 알림

1단계: 깔끔한 시작

git status --porcelain이 비어 있어야 하고 현재 브랜치가 main이어야 하며 origin/main과 최신 상태여야 합니다(git fetch origin && git status -sb). 그렇지 않으면 중단하고 Juan에게 무엇이 더티한지 알려주십시오. 그의 작업을 스태시하지 마십시오.

2단계: 업스트림 가져오기

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

old == new이면 "upstream has no new commits since "라고 보고하고 중단합니다(브랜치 없음, PR 없음). old가 new의 조상이 아닌 경우(git -C "$tmp/upstream" merge-base --is-ancestor $old $new), 업스트림이 히스토리를 다시 쓴 것입니다. 중단하고 플래그를 표시하십시오.

3단계: 변경 사항 읽기

  • git -C "$tmp/upstream" log --oneline $old..$new
  • git -C "$tmp/upstream" diff --name-status -M $old $new
  • 새로운 CHANGELOG.md 항목(old를 포함하는 태그 이후의 태그들). CHANGELOG는 이유를 설명합니다. 보고서에 관련 행을 인용하십시오.

4단계: 각 파일 매핑 및 분류

변경된 모든 업스트림 경로에 대해 port_names.py path를 실행한 다음 각각을 하나의 버킷에 넣습니다.

업스트림 상태 및 매핑버킷
M, 기존 포트 파일에 매핑됨병합
A, 알려진 스킬 폴더에 매핑됨(예: skills/goldfish/의 새 자산)병합 (파일 생성)
A, 새로운 스킬, 에이전트 또는 연습("NEW" 참고)플래그: Juan이 egm- 이름과 포팅 여부를 결정
D (업스트림에서 삭제됨)플래그: 포트 파일을 삭제하지 마십시오
R (업스트림에서 이름 변경됨)플래그: 이전 및 새 경로와 포트 경로를 표시
포트 전용 또는 포팅되지 않음 참고건너뛰기 (변경 사항이 중요하면 설명, 예: README 설치 텍스트)
LICENSE병합, 그런 다음 두 저작권 라인이 남아 있는지 확인

--dry-run을 사용하면 이 테이블과 커밋 목록을 출력한 다음 중단합니다.

5단계: 브랜치에 적용

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

병합 파일당 한 번씩 병합을 실행합니다. 종료 코드 1인 경우, 충돌 마커를 커밋에서 제외하십시오. 파일을 복원하고(git checkout -- <port-path>), 충돌 헝크를 보고서에 기록하여 Juan에게 전달합니다. 병합 후, AGENTS.md에 나열된 Cursor 적응(작업 도구 생성 텍스트, 에이전트의 readonly: true, CLAUDE.md 옆의 AGENTS.md, AGENTS.md 및 .cursor/rules/를 무시하는 리뷰어, /code-review가 아닌 /review, runtimes.md의 Cursor 행)을 위해 수정된 각 파일을 다시 읽으십시오. 업스트림이 새로운 적응이 필요한 곳을 추가한 경우(예: 새로운 CLAUDE.md 조회, 에이전트의 새로운 tools: 라인, 새로운 Claude 전용 생성 명령), 동일한 적응을 적용하고 "적응됨" 아래에 나열하십시오. 업스트림 커밋을 인용하는 메시지와 함께 논리적 그룹으로 커밋하십시오.

6단계: 포인터 이동

모든 병합 파일이 깔끔하게 병합되었거나 충돌이 기록된 경우에만 new를 UPSTREAM_COMMIT에 씁니다. 마지막으로 커밋하십시오.

7단계: 확인

bash <skill-dir>/scripts/check_port.sh. 이름이 폴더와 일치하는지, JSON 평가, check_gate.py (BLOCKED 다음 GO), 남은 이전 슬래시 이름, 그리고 이 스킬을 포함하지 않아야 하는 임시 디렉토리에 테스트 설치를 확인합니다. 병합으로 인한 실패는 수정하고, 다른 모든 것은 보고서에 기록합니다.

8단계: SYNC-REPORT.md

브랜치의 저장소 루트에 SYNC-REPORT.md를 작성하고 PR 본문과 동일한 텍스트를 사용하십시오.

# 업스트림 동기화: <old7>..<new7>

업스트림 커밋: <목록>
CHANGELOG: <인용된 행>

## 적용됨
- <포트 경로> <- <업스트림 경로>: <한 줄>
## Cursor용 적응됨
- <포트 경로>: <적응 내용 및 이유>
## 건너뜀
- <업스트림 경로>: <포트 전용 | 포팅되지 않음>, <변경 사항, 중요할 경우>
## Juan에게 플래그됨
- <새 스킬/에이전트, 삭제, 이름 변경, 충돌>: <경로, 헝크, 질문>
## 검사
<check_port.sh 요약>
## 열린 질문
- <...>

9단계: 푸시 및 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

Juan에게 PR URL, 개수(적용됨, 적응됨, 건너뜀, 플래그됨) 및 플래그된 항목을 알려주십시오. PR을 병합하지 마십시오. 임시 클론을 제거하십시오.

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.

관련 스킬