원클릭으로
personal-clarify-issue
既存の GitHub Issue を整理・再構成します。ユーザーが Issue を「整理して」「構造化して」「書き直して」「わかりやすくして」「clarify して」などと依頼したときに使用してください。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
既存の GitHub Issue を整理・再構成します。ユーザーが Issue を「整理して」「構造化して」「書き直して」「わかりやすくして」「clarify して」などと依頼したときに使用してください。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| 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 テンプレートが存在しない場合にのみ使う。
ユーザーの説明から新しい 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 リポジトリのスタイルに合わせてコミットを作成します。ユーザーがコミットを求めたときや、エージェントがコミットするときに必ず使用してください。