菜单
ユーザーから情報を収集してGitHub Issueを作成するSkill。 ユーザーが「issue作って」「バグ報告を起票して」のように依頼したら使うこと。 複数候補の一括起票はgithub-issue-discover、issue解決からPR作成まではgithub-issue-resolve、 作成済みissueの磨き上げはgithub-issue-polishを使う。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
GitHubのPull Request(PR)のコードレビューを行うSkill。worktreeを作成してソースコード全体を読みながらFinder SubAgentで指摘候補を発見し、Verifier SubAgentで検証する。レビューをレポートとインラインコメントで投稿する。self reviewにも対応する。 ユーザーが「このPRをレビューして」のように依頼したら使うこと。
Agent skill (SKILL.md)の品質を評価基準に沿って採点し、観点ごとの判定と修正案をレポートするSkill。 評価のみ行い、ファイルの編集はしない。 ユーザーが「このskillを評価して」「skillをレビューして」「SKILL.mdの品質を見て」のように依頼したら必ずこのSkillを使うこと。 skillの新規作成や編集そのものを依頼された場合は使わない。
GitHub issueを起点に「調査 → worktree作成 → 実装 → PR作成」を一気通貫で実行するSkill。実装はSubAgentに委譲し、commitとPR作成はgit-commit・github-pr-create skillに連結して実行する。「#N をsubagentで解決して」「実装をsubagentに任せてissueからPRまで」のような依頼に使う。
Pull Requestを作成するSkill。現在のbranchからpull requestを作成する。言語指定可能。 ユーザーが「PR作って」「pull request作成して」のように依頼したら使うこと。
計画や設計について、意思決定のあらゆる分岐点が解消されるまで、徹底的に質問を繰り返してください。ユーザーが計画の改善・詳細化・最適化を望んでいる場合や、設計について厳しく問い詰めてほしいと言われたとき、あるいは「計画(Plan)を詰めて」、「計画(Plan)を改善して」と要望があった際にこの手順を使用してください。
weztermのpane・tab・windowを `wezterm cli` で操作するskill。paneの分割・フォーカス移動・リサイズ・zoom・close、 tab/windowの作成・切替・リネーム、paneの表示内容の読み取り、paneへのコマンド送信と実行結果の確認を行う。 ユーザーが「weztermのpaneを分割して」「weztermの別paneでコマンドを実行して」のように、weztermと明示して依頼したときだけ使うこと。 ユーザーはtmuxも併用しているため、「paneを分割して」のようにweztermと明示されていないpane/tab操作の依頼では使わない (どちらを指すかユーザーに確認する)。 tmuxの操作、およびwezterm自体の設定 (wezterm.luaやkeybinding) の変更にも使わない。
| name | github-issue-create |
| description | ユーザーから情報を収集してGitHub Issueを作成するSkill。 ユーザーが「issue作って」「バグ報告を起票して」のように依頼したら使うこと。 複数候補の一括起票はgithub-issue-discover、issue解決からPR作成まではgithub-issue-resolve、 作成済みissueの磨き上げはgithub-issue-polishを使う。 |
| allowed-tools | Bash(gh:*), Bash(git:*), Bash(ls:*), Read |
GitHub操作は必ずgh CLIで行うこと。GitHub connector/pluginやMCPのGitHubツールは使用しない。
ユーザーから自由入力で受け取ったIssue概要を元に、種別とラベルを自動判定してGitHub Issueを作成する。
language: Issueのタイトルと本文の言語（例: "ja", "en"）。デフォルト: "en"--label <name>: ラベルを 追加 する（任意、複数指定可）。自動判定されたラベルに加えて付与される--assignee <username>: 担当者を割り当て（任意、複数指定可）--dry-run: Issueを作成せず、生成したタイトル・本文・ラベル・担当者の提示のみ行うテンプレートは以下の優先順位で選択する：
.github/ISSUE_TEMPLATE/ が存在する場合はそれを使用references/ 配下を使用
language が "en" または未指定）: references/ISSUE_TEMPLATE/language が "ja"）: references/ISSUE_TEMPLATE_JA/各ディレクトリには以下のテンプレートが含まれる：
feature_request.md - 機能追加（デフォルトラベル: enhancement）bug_report.md - バグ報告（デフォルトラベル: bug）task.md - タスク（デフォルトラベルなし）test.md - テスト追加（デフォルトラベル: test）前提情報の取得: 以下を取得する。
gh repo view --json name,owner --jq '.owner.login + "/" + .name'gh label list --limit 100 --json name,description --jq '.[] | "\(.name)\t\(.description // "")"'ls .github/ISSUE_TEMPLATE/ 2>/dev/null || echo "none"gh auth status が失敗した場合は作業を停止し、認証を案内する下書き素材の確保: ユーザーの依頼にIssueの内容（何をしたいか・何が起きているか）が含まれていれば、そのテキスト全体を「下書き素材」として使い、追加の入力は求めない。依頼に内容がまったく含まれていない場合のみ、AskUserQuestion ではなく 自由テキスト入力 で概要を受け取る:
作成したいIssueの内容を自由に記述してください。背景、目的、再現手順、完了条件など分かる範囲で構いません。1行でも構いません。
種別の自動判定: 下書き素材の内容からテンプレートを自動選択する。判定ヒューリスティック:
bug_reporttestfeature_requesttask判定が曖昧な場合は task を選ぶ（最も汎用的）。判定結果はステップ9の報告時にユーザーに開示する。
テンプレートの読み込み: ステップ1で確認したテンプレート所在に従い、ステップ3で選んだテンプレート種別のファイルを Read で読み込む。フロントマターから labels をデフォルトラベルとして抽出し、本文部分は構造の参考にする。
タイトルと本文の生成: 下書き素材を元に、テンプレートに沿った形でタイトルと本文を生成する:
ラベルの自動判定: 付与するラベルを次の手順で決める:
enhancement / bug / test）を起点とするdocumentation がある → 追加security がある → 追加ci がある → 追加performance がある → 追加--label で渡されたラベルを最終リストに追加する作成可否の判断: 生成したタイトル・本文について、ユーザーへの確認は行わない。次の場合のみ例外とする:
--dry-run が指定されている場合は、生成したタイトル・本文・種別・ラベル・担当者を提示して終了する（Issueは作成しない）Issueの作成:
gh issue create --title "<title>" --body "<body>" [--label <name> ...] [--assignee <username> ...]
結果の報告: