issue

スター9

フォーク0

更新日2026年6月10日 04:24

Create GitHub issues with auto-generated English titles and contextual body content. Use when the user wants to create an issue, report a bug, request a feature, file a ticket, or says "이슈 만들어줘", "이슈 생성", "버그 리포트", "feature request". Also trigger when the user discusses a bug or feature and then says "이거 이슈로 올려줘" or similar.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

ソース

ysoftman

ysoftman/myenv

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

GitHub Issue Creator

대화 맥락을 기반으로 현재 repo에 GitHub issue를 생성한다.

실행 절차

현재 repo 정보를 확인한다:
- gh repo view --json nameWithOwner,url,visibility -q '"\(.nameWithOwner)\t\(.url)\t\(.visibility)"'로 repo name, url, visibility를 한 번에 확인
- url의 호스트가 github.com인지(엔터프라이즈 GHES는 대상 아님), visibility가 PUBLIC인지 기록해 둔다 — step 5의 민감 정보 검사에서 사용
- gh api user -q '.login'으로 현재 사용자 계정을 확인 (assignee용)
대화 맥락을 분석하여 이슈 내용을 구성한다:
- 버그, 기능 요청, 개선, 질문 등 이슈 유형을 파악
- 관련 코드, 에러 메시지, 변경 사항 등을 수집
이슈를 작성한다:
- 제목: 영어, 간결하게 (70자 이내), 동사 원형으로 시작
  - 버그: "Fix ...", "Resolve ..."
  - 기능: "Add ...", "Implement ..."
  - 개선: "Improve ...", "Update ...", "Refactor ..."
- 본문: 아래 템플릿을 기반으로 맥락에 맞게 작성 (불필요한 섹션은 생략)
라벨을 자동 선택한다:
- gh label list --json name,description -q '.[] | "\(.name): \(.description)"'으로 사용 가능한 라벨과 설명을 확인
- 이슈 내용을 분석하여 가장 적절한 라벨을 선택 (복수 선택 가능):
  - 버그/오류/크래시 → bug
  - 새 기능/추가 → enhancement, feature
  - 문서 관련 → documentation
  - 성능 관련 → performance
  - 보안 관련 → security
  - 리팩토링/코드 정리 → refactoring
  - 테스트 관련 → test
  - 긴급/심각 → critical, urgent
  - 질문/논의 → question
- 위는 일반적인 매핑이며, repo에 실제 존재하는 라벨 중에서만 선택한다
- 라벨의 description도 참고하여 내용에 가장 부합하는 라벨을 고른다
- 적절한 라벨이 없으면 라벨 없이 생성
공용(public) GitHub 저장소 민감 정보 검사 — step 1에서 기록한 host가 github.com이고 visibility가 PUBLIC인 경우에만 수행한다(private·GHES·github.com이 아닌 호스트는 생략). 작성한 제목·본문·라벨 문자열에서 다음과 같은 실제 민감 정보 후보를 스캔한다:
- 회사명/내부 도메인 (사내 서비스명, *.corp·*.internal 등 비공개 도메인, 고유한 회사/조직명)
- 사용자 ID/이메일 (실명·실ID·실이메일 형태 — 공개 도메인이 아닌 사내/기업 이메일 포함)
- 패스워드/토큰/API 키/비밀번호 유사 문자열 (예: password=, token=, api_key=, AKIA..., ghp_..., Bearer ..., JWT, 프라이빗 키 블록)
- 내부 IP/호스트/URL (예: 10.*, 172.16-31.*, 192.168.*, *.corp, *.internal)
더미/예시 값은 경고하지 않는다: aaa, 1234, foo/bar/baz, example.com, user@example.com, test, dummy, placeholder, 명백한 랜덤 해시 예제 등은 무시한다. 애매하면 알리는 쪽으로 기운다.

후보가 하나라도 발견되면 step 6의 승인 절차에 들어가기 전에 별도로 사용자에게 알린다:
- 어느 위치(제목/본문/라벨)의 어느 부분에 무엇이 있는지 목록으로 제시 (ANSI 노란색 \033[33m ... \033[0m 권장)
- "공용 GitHub 저장소라 이 이슈는 공개됩니다. 계속 진행할까요?"로 물은 뒤 사용자 응답을 기다린다
- 사용자가 거부하면 이슈를 만들지 않고 대기. 승인하거나 마스킹/제거 지시를 하면 그에 따라 초안을 수정한 뒤 step 6으로 진행한다.
후보가 없으면 이 step을 조용히 통과한다.
사용자에게 제목, 본문, 라벨을 보여주고 확인을 받는다. 제목·본문·라벨은 printf에 ANSI 녹색(\033[32m ... \033[0m) escape 코드를 씌워 터미널에 녹색으로 출력한다. 반드시 Bash 도구로 printf 명령을 실제 실행한다 — 코드 블록으로만 보여주면 안 된다:
```
printf '\033[32m%s\033[0m\n' "$(cat <<'EOF'
제목: ...
본문:
...
라벨: ...
EOF
)"
```

확인 후 gh issue create로 이슈를 생성한다:

gh issue create --title "제목" --body "본문" --assignee @me [--label "라벨"]

생성된 이슈 URL을 사용자에게 알려준다.

본문 템플릿

이슈 유형에 따라 적절한 섹션을 선택하여 사용한다. 모든 섹션이 필수는 아니며, 맥락에 따라 유연하게 구성한다.

Bug Report

## Description

[버그에 대한 간단한 설명]

## Steps to Reproduce

1. [재현 단계]

## Expected Behavior

[기대 동작]

## Actual Behavior

[실제 동작]

## Additional Context

[에러 로그, 스크린샷, 관련 코드 경로 등]

Feature Request / Enhancement

## Description

[기능 또는 개선에 대한 설명]

## Motivation

[왜 이 변경이 필요한지]

## Proposed Solution

[제안하는 해결 방법]

## Additional Context

[참고 자료, 관련 코드 경로 등]

주의사항

이슈 생성 전 반드시 사용자 확인을 받는다
본문에 민감한 정보(비밀번호, 토큰 등)가 포함되지 않도록 주의한다
대화에서 충분한 맥락이 없으면 사용자에게 추가 정보를 요청한다

このリポジトリの他の Skills

同じリポジトリ

jira-create-issue

ysoftman/myenv

Create or edit Jira issues on boards the user has access to. Use this skill whenever the user asks to create, add, file, open, write, or edit a Jira issue/ticket/task, mentions `/jira-create-issue`, `jira 이슈 생성`, `지라 이슈 만들어`, `이슈 수정`, or asks to "티켓 올려줘", even when the project or issue key is not stated explicitly — the skill will infer the project from conversation context or present accessible boards for the user to pick. Always trigger this over generic jira lookup when the intent is to create or modify an issue.

2026-06-209

commit

ysoftman/myenv

Review changes, run lint/format, then create a git commit with English message. Use when user wants to commit, save changes, or says "커밋", "git commit", "git ci".

2026-06-159

tldr

ysoftman/myenv

Explain programming language syntax in Korean with concise examples. Use when user asks about syntax like "python list comprehension", "go goroutine", "rust ownership", or any programming concept explanation.

2026-06-159

review

ysoftman/myenv

Review GitHub PRs and track improvements as tasks. Use when user asks to review a PR, check a pull request, says "PR 리뷰해줘", "PR 봐줘", or provides a GitHub PR URL or number. Delegates both the review judgment and comment writing to the `reviewer` agent (run in the background).

2026-06-159

lint-formatting

ysoftman/myenv

Run language-specific linters, formatters, and static type checks with full command reference. Use when user asks to lint, format, type-check, check style, or says "린트", "포맷", "타입 체크", "lint", "format", "type check", "biome", "ruff", "pyright", "clippy", "golangci-lint", "rumdl", "prettier", "shfmt". Also use when needing detailed command variants (check-only, fix-only, partial scope) beyond the standard fix-everything command.

2026-06-129

jira-git-checkout-branch

ysoftman/myenv

Pick one of the user's In Progress Jira issues and create/checkout a git branch named after it. Use when the user says things like "jira 이슈로 브랜치 만들어", "내 지라 이슈 기반으로 브랜치 파줘", "jira issue branch", or `/jira-git-checkout-branch`. If the working tree is dirty, asks the user whether to proceed; halts if the Atlassian MCP server is not available.

2026-06-109

name	issue
description	Create GitHub issues with auto-generated English titles and contextual body content. Use when the user wants to create an issue, report a bug, request a feature, file a ticket, or says "이슈 만들어줘", "이슈 생성", "버그 리포트", "feature request". Also trigger when the user discusses a bug or feature and then says "이거 이슈로 올려줘" or similar.
allowed-tools	Bash, Read, Grep, Glob
model	sonnet
effort	low

GitHub Issue Creator

대화 맥락을 기반으로 현재 repo에 GitHub issue를 생성한다.

실행 절차

현재 repo 정보를 확인한다:
- gh repo view --json nameWithOwner,url,visibility -q '"\(.nameWithOwner)\t\(.url)\t\(.visibility)"'로 repo name, url, visibility를 한 번에 확인
- url의 호스트가 github.com인지(엔터프라이즈 GHES는 대상 아님), visibility가 PUBLIC인지 기록해 둔다 — step 5의 민감 정보 검사에서 사용
- gh api user -q '.login'으로 현재 사용자 계정을 확인 (assignee용)
대화 맥락을 분석하여 이슈 내용을 구성한다:
- 버그, 기능 요청, 개선, 질문 등 이슈 유형을 파악
- 관련 코드, 에러 메시지, 변경 사항 등을 수집
이슈를 작성한다:
- 제목: 영어, 간결하게 (70자 이내), 동사 원형으로 시작
  - 버그: "Fix ...", "Resolve ..."
  - 기능: "Add ...", "Implement ..."
  - 개선: "Improve ...", "Update ...", "Refactor ..."
- 본문: 아래 템플릿을 기반으로 맥락에 맞게 작성 (불필요한 섹션은 생략)
라벨을 자동 선택한다:
- gh label list --json name,description -q '.[] | "\(.name): \(.description)"'으로 사용 가능한 라벨과 설명을 확인
- 이슈 내용을 분석하여 가장 적절한 라벨을 선택 (복수 선택 가능):
  - 버그/오류/크래시 → bug
  - 새 기능/추가 → enhancement, feature
  - 문서 관련 → documentation
  - 성능 관련 → performance
  - 보안 관련 → security
  - 리팩토링/코드 정리 → refactoring
  - 테스트 관련 → test
  - 긴급/심각 → critical, urgent
  - 질문/논의 → question
- 위는 일반적인 매핑이며, repo에 실제 존재하는 라벨 중에서만 선택한다
- 라벨의 description도 참고하여 내용에 가장 부합하는 라벨을 고른다
- 적절한 라벨이 없으면 라벨 없이 생성
공용(public) GitHub 저장소 민감 정보 검사 — step 1에서 기록한 host가 github.com이고 visibility가 PUBLIC인 경우에만 수행한다(private·GHES·github.com이 아닌 호스트는 생략). 작성한 제목·본문·라벨 문자열에서 다음과 같은 실제 민감 정보 후보를 스캔한다:
- 회사명/내부 도메인 (사내 서비스명, *.corp·*.internal 등 비공개 도메인, 고유한 회사/조직명)
- 사용자 ID/이메일 (실명·실ID·실이메일 형태 — 공개 도메인이 아닌 사내/기업 이메일 포함)
- 패스워드/토큰/API 키/비밀번호 유사 문자열 (예: password=, token=, api_key=, AKIA..., ghp_..., Bearer ..., JWT, 프라이빗 키 블록)
- 내부 IP/호스트/URL (예: 10.*, 172.16-31.*, 192.168.*, *.corp, *.internal)
더미/예시 값은 경고하지 않는다: aaa, 1234, foo/bar/baz, example.com, user@example.com, test, dummy, placeholder, 명백한 랜덤 해시 예제 등은 무시한다. 애매하면 알리는 쪽으로 기운다.

후보가 하나라도 발견되면 step 6의 승인 절차에 들어가기 전에 별도로 사용자에게 알린다:
- 어느 위치(제목/본문/라벨)의 어느 부분에 무엇이 있는지 목록으로 제시 (ANSI 노란색 \033[33m ... \033[0m 권장)
- "공용 GitHub 저장소라 이 이슈는 공개됩니다. 계속 진행할까요?"로 물은 뒤 사용자 응답을 기다린다
- 사용자가 거부하면 이슈를 만들지 않고 대기. 승인하거나 마스킹/제거 지시를 하면 그에 따라 초안을 수정한 뒤 step 6으로 진행한다.
후보가 없으면 이 step을 조용히 통과한다.
사용자에게 제목, 본문, 라벨을 보여주고 확인을 받는다. 제목·본문·라벨은 printf에 ANSI 녹색(\033[32m ... \033[0m) escape 코드를 씌워 터미널에 녹색으로 출력한다. 반드시 Bash 도구로 printf 명령을 실제 실행한다 — 코드 블록으로만 보여주면 안 된다:
```
printf '\033[32m%s\033[0m\n' "$(cat <<'EOF'
제목: ...
본문:
...
라벨: ...
EOF
)"
```

확인 후 gh issue create로 이슈를 생성한다:

gh issue create --title "제목" --body "본문" --assignee @me [--label "라벨"]

생성된 이슈 URL을 사용자에게 알려준다.

본문 템플릿

이슈 유형에 따라 적절한 섹션을 선택하여 사용한다. 모든 섹션이 필수는 아니며, 맥락에 따라 유연하게 구성한다.

Bug Report

## Description

[버그에 대한 간단한 설명]

## Steps to Reproduce

1. [재현 단계]

## Expected Behavior

[기대 동작]

## Actual Behavior

[실제 동작]

## Additional Context

[에러 로그, 스크린샷, 관련 코드 경로 등]

Feature Request / Enhancement

## Description

[기능 또는 개선에 대한 설명]

## Motivation

[왜 이 변경이 필요한지]

## Proposed Solution

[제안하는 해결 방법]

## Additional Context

[참고 자료, 관련 코드 경로 등]

주의사항

이슈 생성 전 반드시 사용자 확인을 받는다
본문에 민감한 정보(비밀번호, 토큰 등)가 포함되지 않도록 주의한다
대화에서 충분한 맥락이 없으면 사용자에게 추가 정보를 요청한다