菜单
今開いている Pull Request の一覧と状況(CI・コンフリクト・レビュー・変更内容)を調べて 報告し、マージして問題ないものはマージするか確認するスキル。「PRの状況を教えて」 「開いてるPR見て」「PR一覧」「マージできるPRある?」「PRのCI通ってる?」などの依頼で使う。 マージは必ずユーザーに確認してから行う(勝手にマージしない)。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/Naturalclar/medley-generator --skill review-prs命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
medley-generator の曲プール (src/data/songs.json) に曲を追加・編集・削除するスキル。 「曲を追加して」「セトリに〇〇を足して」「add a song」「この曲を練習中にして」「〇〇を弾ける曲に変えて」 「曲を消して」「bpm を直して」など、songs.json の曲データを変更する依頼が来たら必ずこのスキルを使う。 ユーザーが JSON やファイル名を明示しなくても、曲プールの中身を変えたそうな依頼なら発動すること。 日本語タイトルからローマ字 id を自動生成し、既存フォーマットを崩さない最小差分で書き込む。
medley-generator の既存曲プールの傾向をもとに、ボカロ / J-POP / J-ROCK から メドレー向きの曲をサジェストするスキル。「曲をサジェストして」「おすすめの曲を教えて」 「〇〇(アーティスト名)でいくつか提案して」「夏っぽい曲ない?」「他にも曲追加したい」 など、追加する曲の候補を求められたら必ずこのスキルを使う。 既存曲との重複を必ず避け、選ばれた曲は manage-songs スキルで追加する。
曲を追加する Pull Request を拾って、作品コード(JASRAC / NexTone)と作詞者・作曲者が 埋まっていなければ J-WID / NexTone を引いて補完し、CI が通ったら squash マージするスキル。 「曲追加のPRを処理して」「PRの曲に作品コードを入れて」「作品コードを調べて」 「曲を追加して」「この曲の作品コードは?」「未調査の曲を埋めて」などの依頼で使う。 曲を1曲追加するだけの依頼でも、作品コードを調べる必要があるならこのスキルの スクリプトを使う(J-WID / NexTone を叩く道具一式がここにある)。
| name | review-prs |
| description | 今開いている Pull Request の一覧と状況(CI・コンフリクト・レビュー・変更内容)を調べて 報告し、マージして問題ないものはマージするか確認するスキル。「PRの状況を教えて」 「開いてるPR見て」「PR一覧」「マージできるPRある?」「PRのCI通ってる?」などの依頼で使う。 マージは必ずユーザーに確認してから行う(勝手にマージしない)。 |
open な PR を棚卸しして「今どうなっているか」「マージしてよいか」を判断できる形で 報告するスキル。このスキル単体では絶対にマージしない。マージ可能なものを挙げて ユーザーに聞き、明示的な指示があって初めてマージする。
owner/repo は Naturalclar/medley-generator、マージ方式は squash(このリポの慣習)。
mcp__github__list_pull_requests(owner, repo, state: "open",
fields: ["number","title","draft","mergeable_state","head","user","created_at"])
0件なら「開いている PR はありません」と伝えて終わり。
PR ごとに以下を取得する(PR が多いときは並列で):
pull_request_read(method: "get_check_runs") — 各ジョブの status と conclusionpull_request_read(method: "get_review_comments") — 未解決スレッドの有無pull_request_read(method: "get_files") または get_diff — 何を変える PR か
(曲追加なら曲名、コード変更ならどのファイルか、が言えるくらいまで)mergeable_state の読み方:
clean … マージ可能dirty … コンフリクトあり(要解決)blocked … 必須チェック/レビュー待ちunstable … CI が失敗または進行中だがマージ自体は可能unknown … GitHub が計算中。少し待って pull_request_read(method: "get") で取り直すPR ごとに 番号・タイトル・変更概要・CI・コンフリクト・レビューを簡潔にまとめる。 表形式が読みやすい。そのうえでマージして問題ない PRと問題がある PRを分けて示す。
「マージして問題ない」= 次のすべてを満たす:
completed かつ conclusion: successmergeable_state が clean(コンフリクトなし)問題がある場合は何が問題でどうすれば直るかまで書く(例: 「main と衝突。
git merge origin/main で解決が必要」「e2e が失敗。ログを見て原因を調べる必要あり」)。
マージ可能な PR があれば、AskUserQuestion で確認する。選択肢は状況に応じて: 「全部マージ」「一部だけ(番号指定)」「マージしない」など。
ユーザーが明示的にマージを指示するまでマージしない。 確認せずマージするのは禁止。
mcp__github__merge_pull_request(owner, repo, pullNumber, merge_method: "squash")
複数マージする場合は1件ずつ。先にマージした PR の影響で後続がコンフリクトすることがある
ので、2件目以降はマージ前に mergeable_state を取り直して確認する。dirty になったら
そこで止めてユーザーに報告する。
マージ後は結果(どれがマージされ、どれが残ったか)を報告する。
in_progress / queued のときは「実行中」と報告する。待つ場合は
foreground の sleep が使えないため、Bash を run_in_background: true にして待つ。claude/...)の PR をマージしたら、次の作業に備えて
ブランチを最新 main から作り直しておくとよい(ship-pr スキルと同じ後片付け)。基于 SOC 职业分类
