菜单
GitHub issueを「issueだけで実装できる」状態まで磨き上げるSkill。 コードベース調査・設計判断・worktreeでのお試し実装で修正方針を検証し、承認を得てからissue本文を書き換える。 ユーザーが「issueを磨いて」「#Nをpolishして」「issueを実装できるレベルに詰めて」のように依頼したら使うこと。 起票はgithub-issue-create、実装からPR作成まではgithub-issue-resolveを使う。
用 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-polish |
| description | GitHub issueを「issueだけで実装できる」状態まで磨き上げるSkill。 コードベース調査・設計判断・worktreeでのお試し実装で修正方針を検証し、承認を得てからissue本文を書き換える。 ユーザーが「issueを磨いて」「#Nをpolishして」「issueを実装できるレベルに詰めて」のように依頼したら使うこと。 起票はgithub-issue-create、実装からPR作成まではgithub-issue-resolveを使う。 |
| allowed-tools | Bash(gh:*), Bash(git:*), Bash(mkdir:*), Bash(rm:*), Bash(cd:*), Bash(ls:*), Bash(cat:*), Bash(mktemp:*), Read, Write, Edit, Glob, Grep, AskUserQuestion |
GitHub操作は必ずgh CLIで行うこと。GitHub connector/pluginやMCPのGitHubツールは使用しない。
指定されたissueを、実装者が追加調査なしで着手できる「issueだけで実装できる」状態まで磨き上げるSkill。コードベース調査で原因と変更箇所を特定し、設計の分岐点を根拠付きで決定し、worktreeでのお試し実装で修正方針を検証した上で、承認を得てissue本文を書き換える。
issue (必須): 対象のissue番号。先頭の # は省略可 (例: 123 または #123)language (任意): 磨き上げ後の本文の言語 (例: ja, en)。デフォルトは元issue本文の言語に合わせる--skip-trial (任意): お試し実装 (Phase 4) を省略する--dry-run (任意): 磨いた本文の提示 (Phase 5) で停止し、issueへの書き込みは一切行わない磨き上げ後の本文は次のセクション構成とする。元issueに情報がなく、調査でも埋められないセクションは省略する (空のセクションやプレースホルダーを残さない)。
path/to/file:行番号 単位で記述以下を取得して状況を確認する:
gh auth status (失敗時は停止し、認証を案内する)gh repo view --json defaultBranchRef,nameWithOwnergh issue view <number> --json number,state,title,body,labels,comments,urlstate: CLOSED の場合は中止し、「issue #N は既にclosedです」と報告する現在のissue本文とコメントをTarget Structureと突き合わせ、欠落しているセクション・曖昧な記述・実装者が追加調査を要する箇所を列挙する。コメントでの合意事項は本文へ反映する対象として扱う。
ギャップを埋めるためにコードベースを調査する:
path/to/file:行番号 単位で特定する実装方針の分岐点をすべて列挙し、各分岐を調査結果に基づき根拠付きで自分で決定する:
--skip-trial 指定時はこのPhaseを省略する。修正方針の実現可能性を一時worktreeで検証する:
polish/<issue-number>-trial、パスは <repo-root>/.tmp/<repo-name>-worktrees/<branch-name>。既存branch・worktreeと衝突する場合は末尾に -2, -3 を付ける
git worktree add -b <branch-name> <worktree-path> <default-branch>git worktree remove --force <worktree-path> → git branch -D <branch-name>Target Structureに沿って本文を再構成し、磨き上げ後の全文と変更点サマリ (追加・変更したセクションと理由) をユーザーに提示する。
--dry-run 指定時はここで終了するAskUserQuestionで承認を取る (AskUserQuestionが使えない環境では、同等の選択肢をテキストで提示して回答を待つ):
承認後に反映する:
gh issue edit <number> --body-file <tmpfile>gh issue comment で1件追記する (body編集はwatcherに通知されないため、通知とトレーサビリティをコメントで補う)以下を簡潔にまとめて出力する: