| name | project-flow-ops |
| description | GitHub와 Linear 전반의 실행 흐름을 운영합니다. 이슈와 PR을 triage하고, 활성 작업을 연결하며, GitHub는 공개 표면으로 유지하고 Linear는 내부 실행 레이어로 유지합니다. 백로그 제어, PR triage, GitHub-Linear 조정이 필요할 때 사용합니다. |
| origin | ECC |
Project Flow Ops
이 스킬은 서로 끊어진 GitHub 이슈, PR, Linear 작업을 하나의 실행 흐름으로 바꿉니다.
문제가 코딩이 아니라 조정일 때 사용합니다.
사용 시점
- 열린 PR 또는 이슈 백로그를 triage할 때
- 무엇을 Linear로 옮기고 무엇을 GitHub에만 남길지 결정할 때
- 활성 GitHub 작업을 내부 실행 레인에 연결할 때
- PR을 merge / port-rebuild / close / park로 분류할 때
- 리뷰 코멘트, CI 실패, stale 이슈가 실행을 막고 있는지 감사할 때
운영 모델
- GitHub는 공개 및 커뮤니티 기준 진실 원천
- Linear는 활성 예약 작업의 내부 실행 진실 원천
- 모든 GitHub 이슈가 Linear 이슈가 될 필요는 없습니다
- 다음 조건일 때만 Linear를 만들거나 갱신합니다
- active
- delegated
- scheduled
- cross-functional
- 내부 추적 가치가 충분히 큼
핵심 워크플로
1. 먼저 공개 표면 읽기
수집 항목:
- GitHub 이슈 또는 PR 상태
- 작성자와 브랜치 상태
- 리뷰 코멘트
- CI 상태
- 연결된 이슈
2. 작업 분류
모든 항목은 다음 상태 중 하나로 끝나야 합니다.
| State | Meaning |
|---|
| Merge | 독립적이고 정책 적합하며 바로 머지 가능 |
| Port/Rebuild | 아이디어는 유용하지만 ECC 내부에서 다시 구현해야 함 |
| Close | 방향이 틀렸거나 stale, unsafe, duplicated |
| Park | 쓸모는 있을 수 있으나 지금 일정에 없음 |
3. Linear 필요성 판단
다음 경우에만 Linear를 만듭니다.
- 실행이 실제로 계획돼 있음
- 여러 저장소 또는 워크스트림이 얽힘
- 내부 소유권이나 순서 관리가 필요함
- 더 큰 프로그램 레인의 일부임
기계적으로 전부 미러링하지 않습니다.
4. 두 시스템 일관성 유지
작업이 active 상태라면:
- GitHub 이슈/PR은 공개적으로 무슨 일이 일어나는지 보여줘야 함
- Linear는 내부적으로 owner, priority, execution lane을 추적해야 함
작업이 출하되거나 기각되면:
- 공개 결과를 GitHub에 다시 남기고
- Linear 상태도 맞게 정리합니다
리뷰 규칙
- 제목, 요약, 신뢰만으로 머지하지 말고 전체 diff를 봅니다
- 외부 소스 기능은 가치가 있지만 self-contained가 아니면 ECC 내부에서 재구축합니다
- CI가 빨간색이면 분류 후 수정 또는 차단합니다
- 실제 blocker가 제품 방향이면 툴링 뒤에 숨지 말고 그렇게 말합니다
출력 형식
PUBLIC STATUS
- issue / PR state
- CI / review state
CLASSIFICATION
- merge / port-rebuild / close / park
- one-paragraph rationale
LINEAR ACTION
- create / update / no Linear item needed
- project / lane if applicable
NEXT OPERATOR ACTION
- exact next move
좋은 사용 사례
- "열린 PR 백로그를 감사해서 merge할 것과 rebuild할 것을 구분해줘"
- "GitHub 이슈를 ECC 1.x와 ECC 2.0 프로그램 레인에 매핑해줘"
- "이게 Linear 이슈가 필요한지 GitHub-only로 남겨야 하는지 봐줘"
