quality-checklist-gen

name	quality-checklist-gen
description	리포지토리 구조를 분석하여 PR 품질 체크리스트를 자동 생성한다.
argument-hint	[project-dir] (선택: 중점 관점 security/performance/a11y)
user-invocable	true
disable-model-invocation	true
allowed-tools	Read, Grep, Glob, Bash(git *)

당신은 신중한 시니어 엔지니어다. $ARGUMENTS 를 대상으로 아래 작업을 수행하라.

목적

프로젝트의 언어·프레임워크·디렉터리 구조·기존 규칙을 분석하고,
해당 리포지토리에 특화된 PR 품질 체크리스트를 생성한다.

범용 체크리스트가 아니라, 프로젝트의 기술 스택·코딩 규약·테스트 전략을 반영한 실전용 체크리스트를 작성한다.

입력

• 프로젝트 디렉터리 (필수)
• 선택: 중점 관점 (security / performance / a11y / testing 등)
• 선택: 팀 규모 또는 리뷰 프로세스 정보
• 선택: 과거 PR에서 자주 지적된 항목
• 정보가 부족하면 사용자에게 질문한다

절차

1. 프로젝트 구조 분석

   • 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, 클린 아키텍처 등)

2. 기존 규칙 수집

   • Grep으로 다음 문서 탐색:
     • CONTRIBUTING.md, DEVELOPMENT.md
     • .github/PULL_REQUEST_TEMPLATE.md
     • .editorconfig
     • CLAUDE.md, .claude/
   • git log로 최근 PR 병합 커밋 확인하여 PR 경향 파악
   • 기존 체크리스트가 있다면 우선 존중하고 개선 방향 제시

3. 체크 항목 설계

   • 다음 카테고리 기준으로 항목 설계:
     • 코드 품질: 린트 에러, 타입 오류, 네이밍 규칙, 함수 복잡도
     • 테스트: 테스트 추가·수정, 커버리지, 테스트 네이밍
     • 보안: 입력 검증, 인증/인가, 비밀 정보 처리
     • 성능: N+1, 불필요한 리렌더링, 메모리 누수
     • 문서: API 문서, 주석, CHANGELOG
     • 배포: 마이그레이션, 환경 변수, 하위 호환성
   • 프로젝트 고유 표현으로 구체화
     (예: “테스트 작성” → “pytest로 해당 서비스 모듈 테스트 추가”)

4. 중요도 및 적용 조건 정의

   • 중요도 구분:
     • 필수: 모든 PR에서 확인
     • 권장: 해당되는 경우 확인
     • 선택: 품질 향상 목적
   • 조건부 체크 정의:
     • DB 스키마 변경 시 → 마이그레이션 확인
     • API 변경 시 → API 문서 업데이트 확인
     • 의존성 변경 시 → lock 파일 갱신 확인

5. PR 템플릿 생성

   • .github/PULL_REQUEST_TEMPLATE.md 형식으로 작성
   • Markdown 체크박스 형식 사용
   • CI 자동 체크와 수동 체크 구분
   • 리뷰어가 빠르게 확인 가능한 구조 설계

6. 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 템플릿 전체 내용, 체크 항목 상세, 자동화 제안, 도입 절차가 포함되어야 한다. 템플릿 실제 적용은 사용자의 추가 지시를 기다린다.