直近N日（デフォルト1日）のPRレビューで繰り返し指摘されている観点のうち「実際に修正すべき」と判断できるものを集約し、リポジトリルートのCODING_GUIDELINES.mdを生成・更新したうえで、commit-push + create-prでPRを作成する。サイズが膨らみすぎないよう既存ルールとの統合・圧縮も行う。
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
直近N日（デフォルト1日）のPRレビューコメントを収集し、繰り返し指摘されているかつ対応すべきと判断できる観点をリポジトリルートのCODING_GUIDELINES.mdに集約するスキル。Instructionsに従い、収集→クラスタリング→ガイドライン更新→PR作成まで一貫して実行する。
やること: 直近N日に更新されたPRのレビューコメント・会話コメントの横断収集（解決済みも含む）／同種の指摘の意味的クラスタリングと2回以上出現するものの抽出／「実際に修正すべき」観点だけのルール化／CODING_GUIDELINES.mdへの追記・既存ルールとの統合・圧縮／commit-pushでコミット・push（必要なら専用feature branchへ切替）／create-prでPR作成とPR URL返却／作成したPRにgh api userの自分自身をAssignee・cc-triage-scopeラベルを付与／編集差分のサマリ報告
絶対にやらないこと:
CODING_GUIDELINES.md以外のファイルの編集（claude-task-worker.jsonのlastRunはclaude-task-workerワーカーが別PRで更新するため、本スキルは同ファイルに一切触らない）commit-pushを呼ぶ）本スキルの GitHub 参照/更新は gh コマンドを優先し、gh が使えない場合に GitHub MCP へフォールバックする（本文中の gh コマンド例はそのまま第一手段として読む）。クラウド実行時のみ優先順位が逆転して GitHub MCP が第一手段になるが、その指示は起動プロンプトで渡されるので、指示が無ければローカル実行として扱う。判定手順・gh ↔ MCP の対応表・MCP に代替が無い操作は ${CLAUDE_PLUGIN_ROOT}/references/github-access.md を参照する。
本スキル固有のリスク: 本スキルは claude-task-worker の update-coding-guidelines ワーカーから24時間おきに自動起動され、ワーカーは起動時刻を claude-task-worker.json の lastRun へ記録する別PRを作ったうえで、次の24時間の実行を抑止する。処理が未完のままターンを終えると、その日の分の収集・ルール化が行われないまま実行済みとして扱われ、取りこぼしたレビューコメントは二度と対象期間に入らない（対象期間は常に直近N日で、遡らない）。
git rev-parse --show-toplevelの出力と一致するか）。一致しない場合は「リポジトリルートで実行してください」と返して終了するCODING_GUIDELINES.mdがあれば全文をReadで読み込み、現在のルール構成・項目数・トーンを把握する$ARGUMENTSを空白区切りで最大2トークンに分解する。
1#プレフィックスは除去して数値部分のみ保持例: /update-coding-guidelines → 日数=1, Issue番号=なし ／ /update-coding-guidelines 7 #123 → 日数=7, Issue番号=123
Issue番号はフェーズ5でcreate-prに渡す。指定なしの場合はPR本文のCloses #N行を省略する。
完了条件: リポジトリルートにいることが確認でき、既存CODING_GUIDELINES.mdがあれば内容を把握済みで、日数と任意Issue番号が確定していること。
GitHub MCP が使える場合は下記「MCP経路の収集契約」に従って同等の収集を行う。以下のスクリプトは MCP 利用不可時のフォールバックとして使う。
スクリプトが認証エラー（401 / 403）で落ちた場合は、同じスクリプトを再試行せず MCP 経路へ切り替える（スクリプトは中で gh を呼ぶ「gh 経路」そのもの。クラウドセッションでは gh api graphql / gh pr list が必ず 403 になる）。スクリプトの失敗を「対象期間に新規レビューコメントなし」に読み替えてはならない。 MCP 経路でも取得できなかった場合に限り、取得失敗とその原因を報告して終了する（CODING_GUIDELINES.md は更新しない）。
bash ${CLAUDE_SKILL_DIR}/scripts/fetch-recent-review-comments.sh <フェーズ0で確定した日数>
第1引数には日数のみを渡す（$ARGUMENTSをそのまま渡すとIssue番号トークンが余計な引数になる）。引数なしの場合はスクリプト側のDAYS="${1:-1}"でデフォルト1日が使われる。
返却されるJSONの構造:
period_since: 収集起点のISO8601タイムスタンプrepo: owner/namepr_count: 対象PR数prs[]:
pr_number / pr_title / pr_url / pr_authorreview_comments[]: コード行に紐づくレビューコメント（path / line / is_resolved / is_outdated / author / body / url / created_at）conversation_comments[]: PRのConversationタブに投稿されたコメント（author / body / url / created_at）pr_countが0の場合は「対象期間に新規レビューコメントなし」と報告して終了する（CODING_GUIDELINES.mdは更新しない）。
MCP 経路でもフェーズ2以降は同じキーで読むため、上の構造（キー名・値の意味）をフォールバックスクリプトと完全に一致させる。
search_pull_requests（query に repo:{owner}/{repo} updated:>=<収集起点の日付>）で対象PR番号を確定する（状態は問わない。上限100件）pull_request_read（get）でメタデータ、get_review_comments でレビュースレッド、issue_read（get_comments）で会話コメントを取得する。どちらもページングがあるため、次ページが無くなるまで取得しきるfetch_pr が生成する構造と同一）:
pr_number / pr_title / pr_url / pr_author（作成者ログイン、不明なら "unknown"）review_comments[]: レビュースレッドの各コメントを {path, line, is_resolved, is_outdated, author, body, url, created_at} へ展開（path / line / is_resolved / is_outdated はスレッド単位の値をコメントへ複写）。created_at が収集起点より前のコメントは除外するconversation_comments[]: 会話コメントのうち非表示（minimized）でないものを {author, body, url, created_at} へ展開。同じく収集起点より前のものは除外するreview_comments と conversation_comments がどちらも空のPRを落としたうえで、{period_since, repo, pr_count, prs: [...]} に組む。period_since はフェーズ0で確定した日数から算出したISO8601、pr_count は prs の件数スクリプト側でisMinimized: trueの会話コメントは除外済みだが、以下もルール化対象から外す（クラスタリング対象には含めるが、抽出条件の判断時に除外する）:
/gemini review等）やCIの自動投稿完了条件: スクリプトの実行結果が手元にあり、ルール化判断の対象となる「人間レビュアーからの修正要求コメント」が抽出できていること。
収集したコメント群を意味ベースでクラスタリングする。字面が違っても同種の指摘は同じクラスタにまとめ（例: 「nullチェックが漏れている」「undefinedの可能性がある」「optional chainingを使うべき」→「null/undefined安全性」クラスタ）、逆に同じキーワードでも文脈が違えば別クラスタにする。
繰り返し出現: 同種の指摘が2回以上（異なるPR / 異なるレビュアー / 異なる箇所）出現している
対応すべき類型: 以下のいずれかに該当する
出現1回の指摘は重要そうでも採用しない（再発時に改めて拾う）。「対応すべき類型」に含まれない繰り返し指摘も採用しない。
完了条件: クラスタごとに「何の問題か」「何回出現したか」「採用/不採用とその理由」「代表的なコメントURL（2件まで）」が言語化できていること。
以下のテンプレートでリポジトリルートに新規作成する。
# Coding Guidelines
このドキュメントは、過去のPRレビューで繰り返し指摘された観点をルール化したものです。
新規コード作成・既存コード修正時の自己レビューチェックリストとして参照してください。
## 更新ルール
- 同種の指摘が2回以上出現した場合のみルール化する
- ルールは「やるべきこと」を肯定形で書く
- 似た項目は統合し、ドキュメント全体のサイズを抑える
- 各ルールには代表的なPRコメントへのリンクを1〜2件添える
---
## <カテゴリ名>
### <ルールタイトル>
<ルール本文。1〜3行で簡潔に。「なぜ」を含める>
参考: [<PR番号 or 簡潔な説明>](<コメントURL>)
採用クラスタごとに以下のいずれかを行う（ルール数の単調増加はドキュメントを死蔵させるため、意味重複があれば必ず統合する）:
完了条件: CODING_GUIDELINES.mdが更新されており、追加/変更したルール、統合・圧縮した既存ルール、ファイル全体の行数が把握できていること。
git statusで差分が発生していなければ「ガイドライン更新差分なし」と報告してこのスキルを終了する（フェーズ4以降のコミット・PR作成は実行しない）。
commit-pushはカレントブランチにコミット・pushするため、デフォルトブランチ上で実行すると本番ブランチに直コミットが入る。必ずfeature branchへ切り替える。
DEFAULT_BRANCH=$(bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh default-branch)
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
CURRENT_BRANCH = DEFAULT_BRANCHの場合: chore/update-coding-guidelines-$(date +%Y%m%d-%H%M%S)形式のブランチをgit checkout -bで作成して切り替える（同名が存在する場合は末尾サフィックスでユニーク化）CURRENT_BRANCH ≠ DEFAULT_BRANCHの場合: そのまま使用する（既に作業ブランチ上にいると判断）切替後にもう一度git statusでCODING_GUIDELINES.mdが変更ファイルとして見えていることを確認する（ブランチ切替で差分が消えていないこと）。
完了条件: デフォルトブランチではない、かつCODING_GUIDELINES.mdの差分が見えるブランチ上にいること。
Skillツールでcommit-pushを引数なしで呼び出す（commit-push側がカレントブランチの差分とコミット履歴を自分で確認して戦略を選ぶ）。
Skillツールでcreate-prを呼び出す。create-prはcontext: forkのサブエージェントとして起動され本スキルの会話文脈は引き継がれないため、引数として渡せるのはIssue番号文字列のみ。
$0に展開され、PR本文にCloses #<Issue番号>が記載される）create-prのテンプレートは無条件でCloses #$0を本文に入れるため、空展開のCloses #行が本文に残る（5-4で後処理する）PR作成後、create-prが返却するPR URLを記録しておく。以降のフェーズでPR番号が必要な箇所は、この記録済みURLの末尾から抽出する（PR_NUMBER="${PR_URL##*/}"）。URLを取得できなかった場合はフェーズ5-3・5-4を実行せず、フェーズ6の出力に「PR URL未取得」と明記して終了する。
create-pr側でもAssignee（gh api userのログインユーザー）とcc-triage-scopeラベルを付ける手順になっているが、context: forkで結果を検証できないため、本スキル側で実際に付いているかを確認し、欠けていればgh pr editで補う。
GitHub MCP が使える場合は
pull_request_read（method:get）/get_meを使う。以下は MCP 利用不可時のフォールバック。
PR_URL="<create-prが返却したPR URL>"
PR_NUMBER="${PR_URL##*/}"
[ -n "$PR_NUMBER" ] || exit 1 # PR_URL未取得時は実行せず中断（前掲の方針どおり）
GH_USER=$(gh api user --jq '.login')
# 現状を確認
gh pr view "$PR_NUMBER" --json assignees,labels \
--jq '{assignees: [.assignees[].login], labels: [.labels[].name]}'
# 欠けていても冪等に付与できるため、そのまま実行してよい
gh pr edit "$PR_NUMBER" --add-assignee "$GH_USER" --add-label "cc-triage-scope"
--add-assignee / --add-label は既に付与済みでもエラーにならないため、確認結果によらず実行してよいcc-triage-scopeラベルがリポジトリに存在せずgh pr editが失敗する場合は、gh label create cc-triage-scopeで作成してから再実行するcreate-prが残したCloses #（数字なし）行を削除する。
GitHub MCP が使える場合は
pull_request_read（method:get）を使う。以下は MCP 利用不可時のフォールバック。
PR_URL="<create-prが返却したPR URL>"
PR_NUMBER="${PR_URL##*/}"
[ -n "$PR_NUMBER" ] || exit 1 # PR_URL未取得時は実行せず中断（前掲の方針どおり）
gh pr view "$PR_NUMBER" --json body --jq '.body' \
| sed -E '/^Closes #[[:space:]]*$/d' \
| gh pr edit "$PR_NUMBER" --body-file -
正規表現は行末（$）まで#の後ろに数字がないことを条件にしているため、数字付きのCloses #123は削除されない。Issue番号が指定されていたケースではこのステップはスキップする。
完了条件: PRが作成されており、PR URLが手元にあり、Assignee（自分自身）とcc-triage-scopeラベルが付与済みで、Issue番号未指定ケースでは本文のCloses #空行が削除されていること。
呼び出し元に以下を構造化して返す。
## 収集結果
- 期間: <SINCE> 〜 現在
- 対象PR数: <n>
- 抽出した指摘クラスタ数: <m>（うち採用 <k> 件）
## CODING_GUIDELINES.md 更新サマリ
- ファイル: <新規作成 / 既存更新>
- 追加ルール: <n>件
- <カテゴリ>: <ルールタイトル>（出典PR: #<num1>, #<num2>）
- 統合・圧縮した既存ルール: <n>件
- <旧ルールタイトル> ← <新指摘> として一般化
- 更新後の総行数: <n>行（前回: <n>行）
## 採用しなかったクラスタ（参考）
- <クラスタ名>: <理由（出現1回のみ / スタイル好みのため 等）>
## PR
- ブランチ: <feature branch名>
- PR URL: <URL>
- Assignee: <ログインユーザー名>（付与失敗時はその旨と理由）
- ラベル: cc-triage-scope（付与失敗時はその旨と理由）
- 関連Issue: #<num>（指定なしの場合は「なし」）
CODING_GUIDELINES.mdとするNo reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
GitHub Issueの確認事項（最後のコメント・descriptionの両方）を、コードベース・ドキュメント・そこから参照されている外部リンク（仕様書・ライブラリ公式ドキュメント等）まで調査し、根拠に基づいた回答をコメントに追記するスキル。調査しても事実で決まらず人間の意思決定が必要な項目は、固定セクションで明示して後続のトリアージへ引き渡す。
The English summary is being prepared. Showing the original description.
Write the merged Pencil design reference back into a UI implementation Issue's description. Takes the Issue number as argument, resolves the merged design PR on the `cc-ui-design-<Issue number>` branch, collects the `.pen` and snapshot paths it added, and appends (or replaces) the `## UIデザイン` section at the end of the Issue body using a lost-update-safe edit.
The English summary is being prepared. Showing the original description.
依頼された内容（自然言語の説明、または既存のIssue番号）を要件とTODOに分解し、タスクごとにGitHub Issueを作成するスキル。タスクの整理・分解、複数Issueの一括作成、依存関係の明示が必要な場合に使用する。「この機能をIssueに分けて」「タスクを洗い出してIssueにして」「PRDのIssue #123 を分解して」といったリクエストで発動する。
The English summary is being prepared. Showing the original description.
claude-task-worker のカスタムワーカー（`workerFiles` に登録する TS 定義）を、`AskUserQuestion` で要件を全項目確定させてから生成し、`claude-task-worker list-workers` でロード検証までするスキル。「カスタムワーカーを作って」「独自のワーカーを追加したい」「新しいラベルで動くワーカーを定義したい」といったリクエストで使用する。
The English summary is being prepared. Showing the original description.
claude-task-workerプラグインのバージョンをインクリメントし、commit-pushでコミット・プッシュしたうえでPRを作成する。引数で `major` / `minor` / `patch` を受け取り、対応する部分をインクリメントする（省略時は `patch`）。「バージョンを上げて」「バージョンアップ」「bump version」「メジャーバージョンを上げて」などのリクエストで使用する。
The English summary is being prepared. Showing the original description.
指定されたPR番号のDependabot PRを確認し、依存ライブラリのバージョンアップ内容をCHANGELOGとcontext7から取得して、コード修正が必要かを判定します。修正が必要な場合は修正を行い、pushまで実施します。
The English summary is being prepared. Showing the original description.