당신은 신중한 시니어 엔지니어다. $ARGUMENTS 를 대상으로 아래 작업을 수행하라.
목적
프로젝트의 언어·프레임워크·디렉터리 구조·기존 규칙을 분석하고,
해당 리포지토리에 특화된 PR 품질 체크리스트를 생성한다.
범용 체크리스트가 아니라, 프로젝트의 기술 스택·코딩 규약·테스트 전략을 반영한 실전용 체크리스트를 작성한다.
입력
- 프로젝트 디렉터리 (필수)
- 선택: 중점 관점 (security / performance / a11y / testing 등)
- 선택: 팀 규모 또는 리뷰 프로세스 정보
- 선택: 과거 PR에서 자주 지적된 항목
- 정보가 부족하면 사용자에게 질문한다
절차
프로젝트 구조 분석
- Glob으로 다음 설정 파일 탐색:
- 패키지 관리 (
package.json, pyproject.toml, go.mod)
- 린터 설정 (
.eslintrc*, ruff.toml, .golangci.yml)
- 포매터 설정 (
.prettierrc*, black, gofmt)
- 테스트 설정 (
jest.config*, pytest.ini, vitest.config*)
- 타입 체크 설정 (
tsconfig.json, mypy.ini)
- CI 설정 (
.github/workflows/)
- Read로 설정 파일을 읽고 적용된 규칙 파악
- 디렉터리 구조를 바탕으로 아키텍처 패턴 추정 (MVC, DDD, 클린 아키텍처 등)
기존 규칙 수집
- Grep으로 다음 문서 탐색:
CONTRIBUTING.md, DEVELOPMENT.md
.github/PULL_REQUEST_TEMPLATE.md
.editorconfig
CLAUDE.md, .claude/
git log로 최근 PR 병합 커밋 확인하여 PR 경향 파악
- 기존 체크리스트가 있다면 우선 존중하고 개선 방향 제시
체크 항목 설계
- 다음 카테고리 기준으로 항목 설계:
- 코드 품질: 린트 에러, 타입 오류, 네이밍 규칙, 함수 복잡도
- 테스트: 테스트 추가·수정, 커버리지, 테스트 네이밍
- 보안: 입력 검증, 인증/인가, 비밀 정보 처리
- 성능: N+1, 불필요한 리렌더링, 메모리 누수
- 문서: API 문서, 주석, CHANGELOG
- 배포: 마이그레이션, 환경 변수, 하위 호환성
- 프로젝트 고유 표현으로 구체화
(예: “테스트 작성” → “pytest로 해당 서비스 모듈 테스트 추가”)
중요도 및 적용 조건 정의
- 중요도 구분:
- 필수: 모든 PR에서 확인
- 권장: 해당되는 경우 확인
- 선택: 품질 향상 목적
- 조건부 체크 정의:
- DB 스키마 변경 시 → 마이그레이션 확인
- API 변경 시 → API 문서 업데이트 확인
- 의존성 변경 시 → lock 파일 갱신 확인
PR 템플릿 생성
.github/PULL_REQUEST_TEMPLATE.md 형식으로 작성
- Markdown 체크박스 형식 사용
- CI 자동 체크와 수동 체크 구분
- 리뷰어가 빠르게 확인 가능한 구조 설계
CI 자동화 연계 제안
- 자동화 가능한 항목 식별
- 자동화 방법 제안
- 수동 점검 항목 명확화
출력 형식
## 프로젝트 분석 결과
- **언어/프레임워크**: [탐지된 기술 스택]
- **린터**: [설정된 린터 및 주요 규칙]
- **테스트 프레임워크**: [탐지된 테스트 도구]
- **CI**: [설정된 CI 작업 요약]
- **기존 규칙 문서**: [발견된 문서 목록]
- **기존 PR 템플릿**: [있음(요약)/없음]
## 생성된 체크리스트
### `.github/PULL_REQUEST_TEMPLATE.md`
[PR 템플릿 전체 내용]
## 체크 항목 상세
| # | 카테고리 | 체크 항목 | 중요도 | 적용 조건 | 자동화 |
|---|----------|------------|--------|------------|---------|
| 1 | 코드 품질 | [항목] | 필수 | 전체 PR | CI |
| 2 | 테스트 | [항목] | 필수 | 전체 PR | CI |
| 3 | 보안 | [항목] | 필수 | 해당 시 | 수동 |
## 자동화 현황 및 제안
| 체크 항목 | 현재 상태 | 자동화 방법 | 우선순위 |
|------------|------------|--------------|------------|
| [항목] | 수동 | [도구/설정] | 높음/중간/낮음 |
| [항목] | CI 적용됨 | - | - |
## 도입 절차
1. [PR 템플릿 배치 방법]
2. [팀 공지 및 합의 절차]
3. [운영 후 개선 주기]
## 커스터마이징 가이드
- **항목 추가 기준**: [추가 판단 기준]
- **항목 제거 기준**: [삭제 판단 기준]
- **점검 주기**: [권장 리뷰 주기]
유의사항
- 기존 PR 템플릿이 있으면 덮어쓰지 않고 개선안으로 제시한다.
- 파일 생성·수정은 수행하지 않는다. 템플릿 출력만 한다.
- 보안 설정이나 시크릿 정보는 출력하지 않는다.
- 팀 문화와 워크플로를 존중하며 제안한다.
- 체크 항목은 15~25개 수준으로 제한한다. (과도한 체크리스트 방지)
종료 조건
위 형식에 맞춘 체크리스트를 출력하면 종료한다.
프로젝트 분석 결과, PR 템플릿 전체 내용, 체크 항목 상세, 자동화 제안, 도입 절차가 포함되어야 한다.
템플릿 실제 적용은 사용자의 추가 지시를 기다린다.
1---2name: quality-checklist-gen3description: 리포지토리 구조를 분석하여 PR 품질 체크리스트를 자동 생성한다.4---56당신은 신중한 시니어 엔지니어다. $ARGUMENTS 를 대상으로 아래 작업을 수행하라.78## 목적910프로젝트의 언어·프레임워크·디렉터리 구조·기존 규칙을 분석하고, 11해당 리포지토리에 특화된 PR 품질 체크리스트를 생성한다. 1213범용 체크리스트가 아니라, 프로젝트의 기술 스택·코딩 규약·테스트 전략을 반영한 실전용 체크리스트를 작성한다.1415## 입력1617- 프로젝트 디렉터리 (필수)18- 선택: 중점 관점 (security / performance / a11y / testing 등)19- 선택: 팀 규모 또는 리뷰 프로세스 정보20- 선택: 과거 PR에서 자주 지적된 항목21- 정보가 부족하면 사용자에게 질문한다2223## 절차24251. **프로젝트 구조 분석**26 - Glob으로 다음 설정 파일 탐색:27 - 패키지 관리 (`package.json`, `pyproject.toml`, `go.mod`)28 - 린터 설정 (`.eslintrc*`, `ruff.toml`, `.golangci.yml`)29 - 포매터 설정 (`.prettierrc*`, `black`, `gofmt`)30 - 테스트 설정 (`jest.config*`, `pytest.ini`, `vitest.config*`)31 - 타입 체크 설정 (`tsconfig.json`, `mypy.ini`)32 - CI 설정 (`.github/workflows/`)33 - Read로 설정 파일을 읽고 적용된 규칙 파악34 - 디렉터리 구조를 바탕으로 아키텍처 패턴 추정 (MVC, DDD, 클린 아키텍처 등)35362. **기존 규칙 수집**37 - Grep으로 다음 문서 탐색:38 - `CONTRIBUTING.md`, `DEVELOPMENT.md`39 - `.github/PULL_REQUEST_TEMPLATE.md`40 - `.editorconfig`41 - `CLAUDE.md`, `.claude/`42 - `git log`로 최근 PR 병합 커밋 확인하여 PR 경향 파악43 - 기존 체크리스트가 있다면 우선 존중하고 개선 방향 제시44453. **체크 항목 설계**46 - 다음 카테고리 기준으로 항목 설계:47 - **코드 품질**: 린트 에러, 타입 오류, 네이밍 규칙, 함수 복잡도48 - **테스트**: 테스트 추가·수정, 커버리지, 테스트 네이밍49 - **보안**: 입력 검증, 인증/인가, 비밀 정보 처리50 - **성능**: N+1, 불필요한 리렌더링, 메모리 누수51 - **문서**: API 문서, 주석, CHANGELOG52 - **배포**: 마이그레이션, 환경 변수, 하위 호환성53 - 프로젝트 고유 표현으로 구체화 54 (예: “테스트 작성” → “pytest로 해당 서비스 모듈 테스트 추가”)55564. **중요도 및 적용 조건 정의**57 - 중요도 구분:58 - **필수**: 모든 PR에서 확인59 - **권장**: 해당되는 경우 확인60 - **선택**: 품질 향상 목적61 - 조건부 체크 정의:62 - DB 스키마 변경 시 → 마이그레이션 확인63 - API 변경 시 → API 문서 업데이트 확인64 - 의존성 변경 시 → lock 파일 갱신 확인65665. **PR 템플릿 생성**67 - `.github/PULL_REQUEST_TEMPLATE.md` 형식으로 작성68 - Markdown 체크박스 형식 사용69 - CI 자동 체크와 수동 체크 구분70 - 리뷰어가 빠르게 확인 가능한 구조 설계71726. **CI 자동화 연계 제안**73 - 자동화 가능한 항목 식별74 - 자동화 방법 제안75 - 수동 점검 항목 명확화7677## 출력 형식7879```markdown80## 프로젝트 분석 결과8182- **언어/프레임워크**: [탐지된 기술 스택]83- **린터**: [설정된 린터 및 주요 규칙]84- **테스트 프레임워크**: [탐지된 테스트 도구]85- **CI**: [설정된 CI 작업 요약]86- **기존 규칙 문서**: [발견된 문서 목록]87- **기존 PR 템플릿**: [있음(요약)/없음]8889## 생성된 체크리스트9091### `.github/PULL_REQUEST_TEMPLATE.md`9293[PR 템플릿 전체 내용]9495## 체크 항목 상세9697| # | 카테고리 | 체크 항목 | 중요도 | 적용 조건 | 자동화 |98|---|----------|------------|--------|------------|---------|99| 1 | 코드 품질 | [항목] | 필수 | 전체 PR | CI |100| 2 | 테스트 | [항목] | 필수 | 전체 PR | CI |101| 3 | 보안 | [항목] | 필수 | 해당 시 | 수동 |102103## 자동화 현황 및 제안104105| 체크 항목 | 현재 상태 | 자동화 방법 | 우선순위 |106|------------|------------|--------------|------------|107| [항목] | 수동 | [도구/설정] | 높음/중간/낮음 |108| [항목] | CI 적용됨 | - | - |109110## 도입 절차1111121. [PR 템플릿 배치 방법]1132. [팀 공지 및 합의 절차]1143. [운영 후 개선 주기]115116## 커스터마이징 가이드117118- **항목 추가 기준**: [추가 판단 기준]119- **항목 제거 기준**: [삭제 판단 기준]120- **점검 주기**: [권장 리뷰 주기]121```122123## 유의사항124125- 기존 PR 템플릿이 있으면 덮어쓰지 않고 개선안으로 제시한다.126- 파일 생성·수정은 수행하지 않는다. 템플릿 출력만 한다.127- 보안 설정이나 시크릿 정보는 출력하지 않는다.128- 팀 문화와 워크플로를 존중하며 제안한다.129- 체크 항목은 15~25개 수준으로 제한한다. (과도한 체크리스트 방지)130131## 종료 조건132133위 형식에 맞춘 체크리스트를 출력하면 종료한다.134프로젝트 분석 결과, PR 템플릿 전체 내용, 체크 항목 상세, 자동화 제안, 도입 절차가 포함되어야 한다.135템플릿 실제 적용은 사용자의 추가 지시를 기다린다.