project-flow-ops

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로 남겨야 하는지 봐줘"