[Jungle My Note | W06] 이슈 생성 프롬프트.md

[Jungle My Note | W06] 이슈 생성 프롬프트 설명.md

적절하게 해당 프롬프트에 링크, 주차 입력하고 Codex나 Claude에게 요청하면 됨.

[Jungle My Note | W06] 이슈 생성 프롬프트.md

다음 GitHub 저장소와 프로젝트에 대해, 기존 운영 방식을 먼저 분석하고, 내가 제공하는 CSV 텍스트를 기반으로 새 이슈/라벨/프로젝트 운영 계획을 세워줘.

입력 정보

• 대상 저장소: <OWNER/REPO>
• 대상 프로젝트: <GitHub Projects URL 또는 owner/project number>
• 참고할 기존 저장소/프로젝트: <선택사항>
• 작업 맥락: <예: n주차 운영, 새 스프린트, 학습 계획, 과제 세팅, 일반 프로젝트 초기 세팅 등>
• 이슈 원본 CSV 텍스트: title,content ...

핵심 원칙

• 먼저 기존 프로젝트/저장소 운영 방식을 분석한다.
• GitHub 조회와 변경은 가능하면 gh 커맨드를 우선 사용한다.
• CSV를 그대로 기계적으로 옮기지 말고, title/content 패턴을 분석해서 더 적절한 이슈 구조와 라벨 체계를 설계한다.
• 과제/학습/구현/문서화/운영/협업 등 내용이 달라질 수 있으므로, CSV의 제목 규칙과 저장소 구조를 함께 보고 분류 체계를 정한다.
• 기존 프로젝트의 형식을 최대한 존중하되, 현재 저장소 성격과 CSV 내용에 맞게 필요한 조정을 한다.
• 라벨은 CSV의 의미를 분석해서 자동으로 제안한다.
• 내가 검토할 것이므로, 반드시 Plan Mode로 상세 계획만 먼저 제시한다.
• 실제 GitHub 변경은 하지 말고 <proposed_plan>만 출력한다.

반드시 분석할 것

• 대상 저장소의 현재 이슈 목록
• 대상 저장소의 현재 라벨 목록
• 대상 프로젝트의 필드/상태/아이템 구조
• 참고 프로젝트가 있다면 기존 제목 규칙, 라벨 규칙, 공통 이슈 패턴
• 저장소 폴더/파일 구조
• CSV의 title/content 패턴
• CSV 항목들이 의미하는 작업 유형
• 기존 항목과 새 항목의 중복 가능성

CSV 해석 규칙

• title과 content를 함께 보고 이슈 목적을 해석한다.
• 제목 접두어가 있으면 분류 힌트로 사용한다.
  • 예: 공통 -, 학습 -, 구현 -, 문서 -, 운영 -, 버그 -, 기능 -
• 파일명, 문제번호, 기술명, 주제명 등이 제목에 들어 있으면 라벨 후보로 활용한다.
• 저장소 구조와 연결 가능한 항목은 경로/카테고리 기준으로 묶는다.
• CSV에 비어 있는 content가 많더라도, 제목과 저장소 맥락으로 보완 가능한 범위는 보완한다.
• 단, 근거 없는 세부사항은 꾸며내지 말고 계획에서 명시적으로 가정 처리한다.

라벨 설계 원칙

• 기존 프로젝트의 라벨 체계가 있으면 우선 참고한다.
• 없거나 부족하면 CSV 의미를 바탕으로 새 라벨 체계를 제안한다.
• 라벨은 최소한 아래 축을 검토한다.
  • 작업 성격: category_common, category_learning, category_implementation, category_docs, category_ops, category_bug, category_feature 등
  • 주제/도메인: 자료구조명, 기능명, 영역명
  • 주차/스프린트/배치: 필요 시 week_n, sprint_n 등
  • 난이도/우선순위: 기존 프로젝트에서 실제로 쓰는 경우에만
• 라벨은 너무 과하게 늘리지 말고, CSV와 저장소에 실제로 필요한 수준으로 제한한다.

이슈 생성 원칙

• 공통/반복 업무성 항목은 별도 공통 카테고리로 묶는지 검토한다.
• 학습성 항목은 학습 목표/개념 정리/도구 학습으로 분리할지 검토한다.
• 구현성 항목은 파일명, 문제 번호, 모듈명, 기능명 기준으로 정리한다.
• 필요하면 CSV 제목을 더 일관된 형식으로 정규화한다.
• 이슈 제목 형식은 전체적으로 일관되어야 한다.
• 이슈 본문 규칙도 함께 제안한다.
  • 예: 원본 CSV content 유지
  • 예: 관련 파일 경로 추가
  • 예: 참고 문서/문제지 경로 추가
  • 예: 빈 content는 템플릿성 본문으로 보완

계획에 반드시 포함할 내용

• 기존 운영 방식 분석 결과
• CSV 구조 분석 결과
• 현재 저장소 성격에 대한 판단
• 새 라벨 목록과 각 라벨의 목적
• 제목 정규화 규칙
• 어떤 CSV 항목을 어떤 라벨로 분류할지
• 공통/학습/구현/기타 항목을 어떻게 나눌지
• 기존 라벨/이슈를 유지, 정리, 교체 중 어떻게 처리할지
• 프로젝트에 어떻게 추가할지
• 상태값을 어떻게 설정할지
• 중복 생성 방지 전략
• 검증 방법

실행 계획 요구사항

• implementer가 바로 실행할 수 있을 정도로 decision-complete 해야 한다.
• CSV 파싱 -> 분류 -> 제목 정규화 -> 라벨 매핑 -> 기존 상태 비교 -> 생성/정리 -> 프로젝트 추가 -> 상태 설정 -> 검증 순서를 명확히 적는다.
• GitHub 상태 조회, 라벨 조작, 이슈 생성, 프로젝트 추가/수정은 gh issue, gh api, gh project, gh repo 등 gh CLI 흐름을 기준으로 계획한다.
• 기존 데이터가 있는 경우의 처리 원칙도 포함한다.
• 불확실한 부분은 assumptions로 분리하되, 가능한 한 탐색으로 먼저 줄인다.

주의사항

• CSV를 그대로 복붙하는 수준의 계획을 만들지 말 것
• 저장소 구조와 프로젝트 운영 방식을 반드시 함께 고려할 것
• 과제형이라고 단정하지 말 것
• 확인 가능한 사실은 먼저 탐색하고, 꼭 필요한 경우에만 질문할 것
• 내가 승인하기 전에는 실제 GitHub 변경을 하지 말 것