Project Flow Ops
이 스킬은 분리된 GitHub 이슈, PR 및 Linear 작업을 하나의 실행 흐름으로 전환합니다.
문제가 코딩이 아닌 조정일 때 사용하세요.
사용 시기
- 열린 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 빨간색은 분류 및 수정 또는 차단을 의미합니다. 병합 준비가 된 것처럼假装하지 마십시오.
- 실제 차단 요소가 제품 방향인 경우 도구 뒤에 숨지 말고 그렇게 말하십시오.
출력 형식
반환:
공개 상태
- 이슈 / PR 상태
- CI / 리뷰 상태
분류
- 병합 / 포팅-재구축 / 종료 / 보류
- 한 문단 근거
LINEAR 조치
- 생성 / 업데이트 / Linear 항목 불필요
- 해당하는 경우 프로젝트 / 경로
다음 운영자 조치
- 정확한 다음 단계
좋은 사용 사례
- "열린 PR 백로그를 감사하고 무엇을 병합하고 무엇을 재구축할지 알려줘"
- "GitHub 이슈를 우리의 ECC 1.x 및 ECC 2.0 프로그램 경로에 매핑해줘"
- "이것이 Linear 이슈가 필요한지 아니면 GitHub에만 남아야 하는지 확인해줘"