메뉴
ユーザーの説明から新しい GitHub Issue を作成します。ユーザーが Issue を「作って」「起票して」「立てて」「登録して」などと依頼したときに使用してください。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | personal-create-issue |
| description | ユーザーの説明から新しい GitHub Issue を作成します。ユーザーが Issue を「作って」「起票して」「立てて」「登録して」などと依頼したときに使用してください。 |
| compatibility | Claude Code |
| allowed-tools | Bash(fd *), Bash(gh repo view *), Bash(gh issue list *), Bash(gh label list *), Bash(gh issue create *), Bash(git config --local --get *), Bash(git config --local convention.language *) |
ユーザーの説明から、新しい GitHub Issue を作成する。
このスキルは、ユーザーのラフな依頼、バグ報告、機能追加案、改善案を、対象リポジトリの既存 Issue 運用にできるだけ沿った形で構造化する。
ユーザーが GitHub Issue を「作って」「起票して」「立てて」「登録して」「file して」などと依頼したときに使う。
このスキルがやること:
このスキルがやらないこと:
リポジトリローカルの規約を、このスキルのデフォルトより優先する。
docs/issue-authoring.md のような独自ドキュメントが存在することを前提にしない。
GitHub における Issue テンプレートの標準的な場所は以下である。
.github/ISSUE_TEMPLATE/
このスキル内の templates/ は fallback 用であり、リポジトリに適切な Issue テンプレートがない場合にのみ使う。
Issue を作成する前に、対象リポジトリで以下を確認する。
.github/ISSUE_TEMPLATE/*.yml.github/ISSUE_TEMPLATE/*.yaml.github/ISSUE_TEMPLATE/*.md.github/ISSUE_TEMPLATE/config.ymltemplates/もし CONTRIBUTING.md、.github/CONTRIBUTING.md などが存在し、簡単に確認できる場合は補助情報として参照してよい。
ただし、それらの存在を前提にしてはいけない。
ユーザーの依頼を、内部的に以下のいずれかへ分類する。
新しい能力・機能・画面・API・振る舞いを追加する Issue。
典型的なシグナル:
addsupportimplementnew既存の機能、UX、性能、保守性、運用、分かりやすさを改善する Issue。
典型的なシグナル:
improveoptimizerefactor壊れている、期待通りでない、誤っている、意図した挙動と違うものを修正する Issue。
典型的なシグナル:
bugfixregressionリポジトリローカルのテンプレートが存在する場合、内部分類をもっとも近いテンプレートにマッピングする。
例:
Feature -> feature_request.yml, feature.yml, enhancement.md
Improvement -> improvement.yml, enhancement.yml, task.md
Bug -> bug_report.yml, bug.yml
完全に一致するテンプレートがない場合は、もっとも近い汎用テンプレートを使う。
使えるローカルテンプレートがない場合は、このスキルの fallback テンプレートを使う。
Feature -> templates/feature.md
Improvement -> templates/improvement.md
Bug -> templates/bug.md
リポジトリ側に独自の命名がある場合、GitHub 上で Feature / Improvement / Bug という名前を強制しない。
ユーザーの入力が薄くても、不要に作成を止めない。
可能な限り Issue として成立する本文を作り、不足している情報は 未確認事項 に残す。
質問するのは、回答がないと Issue として成立しない場合だけにする。
質問する場合のルール:
未確認事項 に残す通常、以下のような情報は 未確認事項 に残してよい。
ユーザーはテンプレート通りに情報を渡さなくてよい。
このスキルは、ユーザーの自然文を読み取り、適切なセクションに分解する。
例:
ユーザー一覧の検索が使いにくい。名前で探したいのにメールアドレスでしか検索できなくて、毎回時間がかかる。
この場合、fallback の Improvement テンプレートでは次のように分離する。
## 現状
ユーザー一覧では、メールアドレスでしか検索できない。
## 課題
名前でユーザーを探したいケースで目的のユーザーを見つけにくく、検索に時間がかかる。
分からない情報を勝手に創作してはいけない。
自信を持って埋められないセクションは 未確認 と書くか、未確認事項 に移す。
タイトルは簡潔で、何をする Issue か分かるものにする。
良い例:
請求書PDFをダウンロードできるようにする
ユーザー一覧を名前で検索できるようにする
下書き請求書の詳細画面で500エラーになる問題を修正する
避ける例:
請求書対応
検索改善
バグ修正
本文は、別のエンジニアが読んでも以下を理解できる状態を目指す。
ユーザーが日本語で依頼した場合、またはリポジトリの Issue が日本語中心の場合は日本語で書く。
リポジトリのテンプレートや既存 Issue が英語中心の場合は英語で書く。
既存のリポジトリラベルを優先する。
よくあるマッピング:
Feature -> enhancement, feature, type:feature
Improvement -> enhancement, improvement, type:improvement
Bug -> bug, type:bug
デフォルトでは新規ラベルを作成しない。
適切な既存ラベルがない場合は、ラベルなしで Issue を作成する。
ユーザーが明示的にラベル作成を依頼した場合のみ、必要最小限のラベルを作成する。
Issue 作成時は、以下の順で進める。
未確認事項 に残す作成権限がない場合は、作成予定のタイトルと本文を明確に提示する。
gh issue create を実行する前に、必ず以下を提示してユーザーの承認を得る。
承認を得るまで gh issue create を実行しない。
ユーザーから修正の指示があれば、内容を反映してから再度提示し、承認を得る。
ユーザーが Issue 作成を明示的に依頼しており、承認が得られた場合は、単なる下書きだけを返さず実際に Issue を作成する。
Fallback テンプレートはこのファイルと同階層の templates/ に置く。
templates/feature.md
templates/improvement.md
templates/bug.md
これらは、リポジトリに適切な Issue テンプレートが存在しない場合にのみ使う。
既存の GitHub Issue を整理・再構成します。ユーザーが Issue を「整理して」「構造化して」「書き直して」「わかりやすくして」「clarify して」などと依頼したときに使用してください。
ユーザーが PR のマージを求めたときや、エージェントが PR をマージするときに必ず使用してください。
Git リポジトリの慣習に則って新しいブランチや worktree を作成します。ユーザーがブランチや worktree の作成を求めたときや、エージェントが `git branch` や `git switch -c`、`git worktree add` などを用いて新しい作業を開始するときに必ず使用してください。
各リポジトリの既存の慣習からコミットメッセージ・PR タイトルの言語/スタイルを検出し、それに従うための手順をまとめたリファレンスです。ユーザーが Git の規約について尋ねたときや、他のスキルがコミット・PR 作成時に規約判定を必要とするときに使用してください。
プロジェクトに TypeScript 環境をセットアップします。typescript（ネイティブコンパイラ）のインストール、適切な @tsconfig/bases の選定と tsconfig.json への反映、package.json への typecheck スクリプト追加、CI への typecheck ジョブ追加を行います。TypeScript のセットアップを求められたときに使用してください。
Git リポジトリのスタイルに合わせてコミットを作成します。ユーザーがコミットを求めたときや、エージェントがコミットするときに必ず使用してください。