Need
버그 컨텍스트가 모이는 위치
Default options
Sentry 알림, Slack 채널, Linear 보기, GitHub 이슈, PR 검사, 지원 요청 대기열, 온콜 메모, 로그, 대시보드, 배포 메모
Why it's needed
Codex가 점검해야 할 정확한 대기열, 채널, 보기, 레포지토리, 알림 링크, 대시보드, 파일을 지정하세요.
Codex use case
버그 트리아지 자동화
매일 접수되는 버그 보고서를 우선순위 목록으로 정리한 다음, 점검을 자동화하세요.
Difficulty 중급
Time horizon 1시간
Codex에 최근 알림, 이슈, 실패한 검사, 로그, 채팅에 올라온 보고를 확인하도록 요청하고, 하나의 채팅에서 목록을 조정한 다음 해당 점검을 예약 실행하세요.
적합한 대상
- Sentry 알림, Slack 스레드, Linear 이슈, GitHub 이슈, 실패한 PR 검사, 지원 티켓, 로그 등 여러 곳에서 버그를 추적하는 팀.
- 작업을 예약하기 전에 하나의 Codex 채팅에서 수동으로 실행해 보려는 트리아지 워크플로우.
Contents
버그 트리아지 자동화
매일 접수되는 버그 보고서를 우선순위 목록으로 정리한 다음, 점검을 자동화하세요.
Codex에 최근 알림, 이슈, 실패한 검사, 로그, 채팅에 올라온 보고를 확인하도록 요청하고, 하나의 채팅에서 목록을 조정한 다음 해당 점검을 예약 실행하세요.
중급
1시간
Codex에 최근 알림, 이슈, 실패한 검사, 로그, 채팅에 올라온 보고를 확인하도록 요청하고, 하나의 채팅에서 목록을 조정한 다음 해당 점검을 예약 실행하세요.
중급
1시간
관련 링크
적합한 대상
- Sentry 알림, Slack 스레드, Linear 이슈, GitHub 이슈, 실패한 PR 검사, 지원 티켓, 로그 등 여러 곳에서 버그를 추적하는 팀.
- 작업을 예약하기 전에 하나의 Codex 채팅에서 수동으로 실행해 보려는 트리아지 워크플로우.
스킬 및 플러그인
- GitHub가 버그 접수 채널 중 하나라면 이슈, Pull Request, 댓글, 검토 스레드, 실패한 검사를 확인합니다.
- 알림을 점검하는 경우 프로덕션 오류, 스택 트레이스, 영향을 받은 릴리스, 이벤트 컨텍스트를 살펴봅니다.
- 팀원이 버그를 보고하는 채널이나 스레드를 읽고 팀 채널에 공유할 요약 초안을 준비합니다.
- 버그 대기열을 읽고 기존 이슈를 찾거나, 업데이트 초안을 작성하거나, 트리아지 점검 후 연결된 후속 티켓을 준비합니다.
시작 프롬프트
[repo/service/team]에 대해 최근 [time window] 동안의 버그 트리아지 점검을 실행하세요.
다음 플러그인을 사용하세요: [@Sentry / @Slack / @Linear / @GitHub / none]
입력 소스:
- Sentry: [project / alert link / none]
- Slack: [channel / thread links / none]
- Linear: [team / project / view / issue query / none]
- GitHub: [repo / issue query / PR checks / none]
- 기타: [logs / support tickets / deploy link / dashboard / attached file / none]
출력 형식:
먼저 접근할 수 없었던 입력 소스가 있다면 이름을 밝히세요.
그런 다음 P0부터 P3까지 정렬한 버그 우선순위 목록을 반환하세요.
버그를 찾지 못했다면 다음과 같이 답하세요: 조건에 맞는 버그를 찾지 못했습니다.
각 버그에 다음을 포함하세요:
- 우선순위: P0, P1, P2 또는 P3
- 제목
- 근거(링크 또는 짧은 인용)
- 권장하는 다음 조치
규칙:
- 어떤 것도 게시, 생성, 할당, 레이블 지정, 종료, 재실행 또는 편집하지 마세요.
- 중복 보고서는 하나의 버그 아래에 묶으세요.
- 관찰된 근거와 추정을 구분하세요.
[repo/service/team]에 대해 최근 [time window] 동안의 버그 트리아지 점검을 실행하세요.
다음 플러그인을 사용하세요: [@Sentry / @Slack / @Linear / @GitHub / none]
입력 소스:
- Sentry: [project / alert link / none]
- Slack: [channel / thread links / none]
- Linear: [team / project / view / issue query / none]
- GitHub: [repo / issue query / PR checks / none]
- 기타: [logs / support tickets / deploy link / dashboard / attached file / none]
출력 형식:
먼저 접근할 수 없었던 입력 소스가 있다면 이름을 밝히세요.
그런 다음 P0부터 P3까지 정렬한 버그 우선순위 목록을 반환하세요.
버그를 찾지 못했다면 다음과 같이 답하세요: 조건에 맞는 버그를 찾지 못했습니다.
각 버그에 다음을 포함하세요:
- 우선순위: P0, P1, P2 또는 P3
- 제목
- 근거(링크 또는 짧은 인용)
- 권장하는 다음 조치
규칙:
- 어떤 것도 게시, 생성, 할당, 레이블 지정, 종료, 재실행 또는 편집하지 마세요.
- 중복 보고서는 하나의 버그 아래에 묶으세요.
- 관찰된 근거와 추정을 구분하세요.
사용 방법
Sentry 알림, Linear 이슈, GitHub 이슈, PR 검사, 배포 로그, 지원 티켓, Slack 스레드 등 버그가 이미 보고되는 곳을 Codex가 확인하도록 하세요. 먼저 수동으로 한 번 점검하고 채팅에서 보고서를 다듬은 다음, 예약 실행하세요.
전체 트리아지 과정을 하나의 Codex 채팅에서 진행하세요:
- 점검을 한 번 실행해 목록 초안을 받으세요.
- 같은 채팅에서 목록을 검토하고 피드백을 제공하세요.
- 해당 채팅에서 트리아지 작업을 예약하세요.
- 선택 사항: 보고서의 품질이 충분하다고 판단되면 Codex에 Linear 이슈, Slack 업데이트, GitHub 댓글 또는 인계 메모의 초안을 작성하도록 요청하세요.
시작하기 전에 Sentry, Slack, Linear, GitHub 등 Codex에 필요한 플러그인을 설치하세요. 시작 프롬프트에서 대괄호로 표시된 플러그인 목록을 실제 @ 플러그인 칩으로 바꾸세요. 그런 다음 대괄호로 표시된 각 소스를 검색할 정확한 위치로 바꾸세요. 예를 들면 Sentry 프로젝트 또는 알림 URL, Slack 채널 또는 스레드, Linear 팀, 보기 또는 쿼리, GitHub 레포지토리, 이슈 쿼리 또는 PR 검사, 배포 링크, 로그 파일, 지원 요청 대기열 또는 대시보드입니다.
1단계: 점검 실행
테스트, 레포지토리 도구, 빌드 검사, CI 실패 등 로컬 컨텍스트가 도움이 되는 경우에는 버그가 속한 레포지토리에서 Codex를 시작하세요. 플러그인, 커넥터, MCP 서버, 링크, 내보내기 파일, 붙여 넣은 로그 또는 첨부 파일을 통해 버그 소스에 접근할 수 있다면 어떤 레포지토리에서든 점검을 실행할 수 있습니다.
먼저 위의 시작 프롬프트를 실행하세요. 점검에 필요한 플러그인과 소스만 남기세요.
예를 들어 완성된 프롬프트에는 점검에 사용할 플러그인과 정확한 대기열, 채널 또는 레포지토리를 지정할 수 있습니다.
2단계: 유용한 보고서 만들기
자동화하기 전에 보고서를 매일 확인할 가치가 있을 만큼 유용하게 다듬으세요.
유용한 첫 점검 결과는 다음 조건을 충족합니다:
- 유의미한 버그가 P0부터 P3까지 우선순위순으로 정렬되어 있습니다.
- 중복 보고서가 하나의 버그로 그룹화되어 있습니다.
- 각 버그에 근거 링크나 짧은 인용이 있습니다.
- 추정은 관찰된 사실과 구분되어 있습니다.
- 각 버그에 권장하는 다음 조치가 간략히 적혀 있습니다.
예약하기 전에 같은 채팅에서 보고서를 다듬으세요. Codex에 다음과 같이 요청할 수 있습니다:
- 목록의 순위를 정하기 전에 소스를 하나 더 확인하세요.
- 팀이 이미 알고 있는 노이즈 알림은 제외하세요.
- P0 및 P1 버그만 반환하세요.
- Slack의 버그 보고, Sentry 알림, GitHub의 검사 실패가 동일한 버그를 가리키면 하나로 병합하세요.
- 각 버그에서 가장 적합한 링크 하나만 표시하세요.
- 다른 사람이 이슈를 재현하거나 적절한 담당자에게 전달할 수 있도록 충분한 근거를 추가하세요.
3단계: 자동화
필요할 때 실행한 보고서가 유용하다면 같은 채팅에서 해당 트리아지 작업을 예약하세요. Codex는 채팅에서 다듬은 내용을 활용해 반복 실행에 사용할 프롬프트를 작성할 수 있습니다.
트리아지 작업 예약
이 채팅에서 다듬은 버그 트리아지 워크플로우를 위한 작업을 예약하세요.
일정: [every hour / every weekday morning / daily]
이 채팅에서 사용한 것과 동일한 소스, 우선순위 규칙, 중복 그룹화 방식, 근거 형식, P0-P3 보고서 형식을 사용하세요.
이 예약 작업의 프롬프트를 작성할 때는 작업이 예약 실행 시 해당 소스를 다시 읽는 데 필요한 플러그인 멘션 또는 연결된 소스 사용 지침을 포함하세요.
예약 작업은 초안만 작성하도록 유지하세요. 게시, 생성, 할당, 레이블 지정, 종료, 재실행, 수정 작업 시작 또는 코드 편집을 하지 마세요.
예약하기 전에 작업 프롬프트, 일정, 소스, 작업 정책을 보여 주세요.
4단계: 후속 작업 전달
예약 보고서가 충분히 유용해지면 후속 작업을 어디로 전달할지 결정하세요. Codex는 팀 채널에 올릴 Slack 업데이트 초안을 작성하고, 추적하려는 버그의 Linear 이슈를 작성하고, 검사에 실패한 PR에 남길 GitHub 댓글을 작성하거나, 온콜 담당자를 위한 인수인계 메모를 만들 수 있습니다.
이 채팅에서 예약한 버그 트리아지 작업을 업데이트하세요.
예약 작업이 실행될 때마다 필요한 후속 조치의 초안을 작성하세요:
- [channel]에 올릴 Slack 업데이트
- [which bugs should become issues]에 대한 Linear 이슈
- [issue / PR / failing check]에 남길 GitHub 댓글
- [team / on-call / owner]에 전달할 인수인계 메모
규칙:
- 먼저 Codex에서 후속 조치의 초안을 작성하세요.
- 각 작업을 내가 명시적으로 승인하기 전에는 Slack에 게시하거나, Linear 이슈를 만들거나, GitHub에 댓글을 달지 마세요.
- 기존 Linear, GitHub, Slack 항목이나 알림 소스의 링크가 있으면 포함하세요.
- 명시적으로 승인하지 않은 모든 작업은 초안 작성만 하세요.
Tech stack
Need
Default options
Why it's needed
Need
Codex가 버그 컨텍스트를 읽는 방법
Default options
Slack, Linear, GitHub, Sentry용 플러그인 ; 커넥터; MCP 서버 ; 레포지토리 CLI; 링크; 내보내기 파일; 첨부 파일; 붙여 넣은 로그
Why it's needed
기존 통합이 있다면 설치하세요. Codex가 아직 읽을 수 없는 내부 소스에는 간단한 MCP 서버, CLI, 내보내기 기능 또는 대시보드 링크를 구축하거나 구성하세요.
| Need | Default options | Why it's needed |
|---|---|---|
| 버그 컨텍스트가 모이는 위치 | Sentry 알림, Slack 채널, Linear 보기, GitHub 이슈, PR 검사, 지원 요청 대기열, 온콜 메모, 로그, 대시보드, 배포 메모 | Codex가 점검해야 할 정확한 대기열, 채널, 보기, 레포지토리, 알림 링크, 대시보드, 파일을 지정하세요. |
| Codex가 버그 컨텍스트를 읽는 방법 | Slack, Linear, GitHub, Sentry용 플러그인 ; 커넥터; MCP 서버 ; 레포지토리 CLI; 링크; 내보내기 파일; 첨부 파일; 붙여 넣은 로그 | 기존 통합이 있다면 설치하세요. Codex가 아직 읽을 수 없는 내부 소스에는 간단한 MCP 서버, CLI, 내보내기 기능 또는 대시보드 링크를 구축하거나 구성하세요. |
