القائمة
ユーザーの説明から新しい GitHub Issue を作成します。ユーザーが Issue を「作って」「起票して」「立てて」「登録して」などと依頼したときに使用してください。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
既存の 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 リポジトリのスタイルに合わせてコミットを作成します。ユーザーがコミットを求めたときや、エージェントがコミットするときに必ず使用してください。
| 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 テンプレートが存在しない場合にのみ使う。