Project Flow Ops
이 스킬은 연결되지 않은 GitHub 이슈, PR 및 Linear 작업을 하나의 실행 흐름으로 전환합니다.
문제가 코딩이 아닌 조정(Coordination)일 때 사용하세요.
사용 시점
- 열려 있는 PR 또는 이슈 백로그 분류
- Linear에 넣을 것과 GitHub에만 남길 것 결정
- 활성 GitHub 작업을 내부 실행 레인에 연결
- PR을 병합, 포트/재구축, 닫기 또는 보류로 분류
- 리뷰 코멘트, CI 실패 또는 오래된 이슈가 실행을 차단하고 있는지 감사
운영 모델
- GitHub는 공개 및 커뮤니티 진실
- Linear는 활성 예정 작업에 대한 내부 실행 진실
- 모든 GitHub 이슈에 Linear 이슈가 필요한 것은 아님
- 다음 경우에만 Linear를 생성하거나 업데이트:
- 활성
- 위임됨
- 예정됨
- 교차 기능
- 내부적으로 추적할 만큼 중요함
핵심 워크플로
1. 공개 표면을 먼저 읽기
수집:
- GitHub 이슈 또는 PR 상태
- 작성자 및 브랜치 상태
- 리뷰 코멘트
- CI 상태
- 연결된 이슈
2. 작업 분류
모든 항목은 다음 상태 중 하나로 끝나야 함:
| 상태 | 의미 |
|---|---|
| 병합 | 자체 포함, 정책 준수, 준비 완료 |
| 포트/재구축 | 유용한 아이디어이나 ECC 내에 수동으로 재배치되어야 함 |
| 닫기 | 잘못된 방향, 오래됨, 안전하지 않음 또는 중복됨 |
| 보류 | 잠재적으로 유용하나 현재 예정되지 않음 |
3. Linear가 필요한지 결정
다음 경우에만 Linear를 생성하거나 업데이트:
- 실행이 적극적으로 계획됨
- 여러 저장소 또는 작업 스트림이 관련됨
- 작업에 내부 소유권 또는 순서 지정이 필요함
- 이슈가 더 큰 프로그램 레인의 일부임
모든 것을 기계적으로 미러링하지 마십시오.
4. 두 시스템의 일관성 유지
작업이 활성화된 경우:
- GitHub 이슈/PR은 공개적으로 무슨 일이 일어나고 있는지 말해야 함
- Linear는 내부적으로 소유자, 우선순위 및 실행 레인을 추적해야 함
작업이 출시되거나 거부된 경우:
- 공개 해결 방법을 GitHub에 다시 게시
- Linear 작업을 적절히 표시
리뷰 규칙
- 제목, 요약 또는 신뢰만으로 병합하지 말고 전체 diff를 사용
- 외부 소스 기능이 가치 있지만 자체 포함되지 않은 경우 ECC 내에서 재구축해야 함
- CI 적색은 분류 및 수정 또는 차단을 의미하며, 병합 준비가 된 것처럼 가장하지 마십시오
- 실제 차단 요소가 제품 방향인 경우 도구 뒤에 숨지 말고 말하십시오
출력 형식
반환:
PUBLIC STATUS
- 이슈 / PR 상태
- CI / 리뷰 상태
CLASSIFICATION
- merge / port-rebuild / close / park
- 한 문단 근거
LINEAR ACTION
- create / update / Linear 항목 불필요
- 해당하는 경우 프로젝트 / 레인
NEXT OPERATOR ACTION
- 정확한 다음 조치
좋은 사용 사례
- "열려 있는 PR 백로그를 감사하고 무엇을 병합하고 무엇을 재구축해야 하는지 알려줘"
- "GitHub 이슈를 ECC 1.x 및 ECC 2.0 프로그램 레인에 매핑해줘"
- "이것이 Linear 이슈가 필요한지 아니면 GitHub에만 남아 있어야 하는지 확인해줘"