القائمة
既存の GitHub Issue を整理・再構成します。ユーザーが Issue を「整理して」「構造化して」「書き直して」「わかりやすくして」「clarify して」などと依頼したときに使用してください。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
ユーザーの説明から新しい GitHub Issue を作成します。ユーザーが Issue を「作って」「起票して」「立てて」「登録して」などと依頼したときに使用してください。
ユーザーが 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-clarify-issue |
| description | 既存の GitHub Issue を整理・再構成します。ユーザーが Issue を「整理して」「構造化して」「書き直して」「わかりやすくして」「clarify して」などと依頼したときに使用してください。 |
| compatibility | Claude Code |
| allowed-tools | Read(*), Bash(fd *), Bash(rg *), Bash(gh repo view *), Bash(gh issue view *), Bash(gh issue edit *), Bash(gh issue list *), Bash(gh pr view *), Bash(gh pr list *), Bash(gh label list *), Bash(git config --local --get *), Bash(git config --local convention.language *) |
既存の GitHub Issue を読み取り、内容を保持しながら構造・表現・明確さを改善する。
このスキルは、以下のような状態の Issue を整理する。
ユーザーが Issue を「整理して」「構造化して」「書き直して」「わかりやすくして」「clarify して」などと依頼したときに使う。
このスキルがやること:
未確認事項 として残すこのスキルがやらないこと:
著者の意図を忠実に保ちながら、内容を能動的に明確化する。
「clarify（明確化）」するスキルである以上、空欄や 未確認 を残すことは最後の手段であり、デフォルトの選択肢ではない。調べれば分かること・聞けば分かることは積極的に埋める。
情報の解釈に迷ったときは「変更しない」を選ぶ。推測で内容を補ってはいけない。
リポジトリローカルの Issue テンプレートが存在する場合、そのセクション構成を参考にする。
gh issue view <issue-number> --json number,title,body,labels,url で Issue を取得する現在の Issue 内容を読み取り、以下のいずれかへ分類する。
新しい能力・機能・画面・API・振る舞いを追加する Issue。
典型的なシグナル:
addsupportimplementnew既存の機能、UX、性能、保守性、運用、分かりやすさを改善する Issue。
典型的なシグナル:
improveoptimizerefactor壊れている、期待通りでない、誤っている、意図した挙動と違うものを修正する Issue。
典型的なシグナル:
bugfixregressionリポジトリローカルのテンプレートが存在する場合、そのセクション構成を参考にする。
.github/ISSUE_TEMPLATE/
リポジトリにテンプレートがない場合は、このスキルの fallback テンプレートを使う。
Feature -> templates/feature.md
Improvement -> templates/improvement.md
Bug -> templates/bug.md
既存の本文から情報を抽出し、適切なセクションに移す。
未確認事項 に記載する1. コードベース・関連 Issue・PR から調べて埋める（後述）
2. ユーザーに短い質問をして埋める（後述）
3. どうしても分からない場合のみ `未確認` と書くか `未確認事項` に残す
元の本文にない情報を推測だけで創作してはいけない。
元の本文に情報が不足している場合、以下の順で埋める努力をする。
以下のような情報はコードベースや関連 Issue・PR を調べれば分かることが多い。
調べ方の例:
# コードベースを検索する
rg -uuu "キーワード" .
# 関連 Issue を探す
gh issue list --search "キーワード"
# 関連 PR を探す
gh pr list --search "キーワード"
コードベースを調べても分からない情報で、ユーザーが即答できそうなものは質問する。
質問するかどうかの判断基準:
質問するときのルール:
未確認事項 に残す以下のような情報は 未確認事項 に残してよい。
未確認事項 は「このスキルが手を尽くして埋めきれなかった情報」だけを残す場所。何でもとりあえず入れる場所ではない。
タイトルが以下の状態の場合は、改善案を提示してユーザーに確認を取る。
ユーザーが確認した場合のみタイトルを更新する。
タイトルが十分に明確な場合は変更しない。
未確認事項 に列挙するgh issue edit <issue-number> --body <新しい本文> で本文を更新する--title <新しいタイトル> を追加するgh issue edit を実行する前に、必ず以下を提示してユーザーの承認を得る。
承認を得るまで gh issue edit を実行しない。
ユーザーから修正の指示があれば、内容を反映してから再度提示し、承認を得る。
Fallback テンプレートはこのファイルと同階層の templates/ に置く。
templates/feature.md
templates/improvement.md
templates/bug.md
これらは、リポジトリに適切な Issue テンプレートが存在しない場合にのみ使う。