opspresso/engineering

실패한 CI·GitHub Actions 실행의 로그와 revision을 조사해 원인과 해결 방법을 찾을 때 쓴다. 코드·테스트·의존성·실행 환경·일시적 실패를 구별하고 요청된 경우에만 수정한다. 서비스의 운영 장애는 incident-triage, 단순 PR 검토는 code-review를 쓴다.

Pull Request·Merge Request·diff·패치의 버그, 회귀 위험, 보안 문제와 테스트 누락을 검토할 때 쓴다. 변경과 관련 코드를 확인해 근거 있는 지적을 심각도순으로 보고한다. 저장소 전체 감사는 범위 밖이며 PR 본문 작성은 pr-description을 쓴다.

패키지·SDK·프레임워크·도구 의존성을 지정 버전이나 호환 범위로 업그레이드할 때 쓴다. 실제 버전과 전이 의존성, 공식 변경 사항을 확인하고 manifest·lockfile·사용 코드를 함께 검증한다. 버전 추천만 요청하면 설치하지 않으며 취약점 전체 대응은 security-remediation을 쓴다.

PR 본문, 커밋 메시지, 이슈 코멘트, 릴리스 노트, 설계 문서와 README의 문장을 작성하거나 개선할 때 쓴다. 기술적 원인과 결과를 독자가 이해할 수 있게 쓰고 저장소의 형식과 용어를 따른다. 일반 업무 문서는 korean-writing, 기존 한국어 글의 윤문은 korean-humanize를 쓴다.

GitHub Issue·버그 보고·재현 사례를 바탕으로 오류의 근본 원인을 찾아 수정할 때 쓴다. 재현 조건과 기대 동작을 확인하고 좁은 수정과 회귀 검증을 수행한다. 원인 설명만 요청하면 코드를 바꾸지 않으며 새 기능 개발은 implement-feature를 쓴다.

기존 프로젝트에 새 기능이나 명시적인 동작 변경을 구현할 때 쓴다. 요구사항을 관찰 가능한 완료 조건으로 정리하고 기존 구조에 맞춰 구현·검증한다. 버그 복구는 fix-issue, 동작을 유지하는 구조 개선은 refactor-code, 새 프로젝트는 project-generator를 쓴다.

Pull Request 제목과 본문을 작성하거나 기존 설명을 개선할 때 쓴다. 실제 변경에서 해결할 문제, 변경 후 동작과 검증을 정리하고 필요한 위험과 관련 링크를 덧붙인다. 코드의 버그·회귀 검토는 code-review를 쓴다.

새 웹 앱·API·CLI·라이브러리·자동화 프로젝트의 실행 가능한 초기 구조를 만들 때 쓴다. 목적과 스택·실행 환경을 확인하고 최소 기능·설정 예시·실행 방법을 생성해 검증한다. 기존 프로젝트 기능 추가는 implement-feature이며 새 원격 저장소 생성·공개 배포는 별도 요청이다.

외부 동작을 유지하면서 코드 구조·중복·모듈 경계·유지보수성을 개선할 때 쓴다. 기존 동작과 공개 계약을 기준으로 작은 변경과 동등성 검증을 수행한다. 새 동작 구현이나 버그 수정, 단순 문장 편집은 별도 작업이다.

사용자가 지정한 취약점·CVE·보안 경고·코드 결함을 방어적으로 수정하고 검증할 때 쓴다. 영향 경로와 실제 적용 버전을 확인해 최소 수정과 안전한 회귀 검증을 수행한다. 일반 구현에 자동으로 전체 보안 감사를 추가하거나 공격 대상 탐색을 수행하지 않는다.