GitHub の PR を入力に、変更されたコードやドキュメントを mermaid の図（全体像・関数単位のシーケンス図・参照箇所起点のシーケンス図）で可視化し、短い解説を付けて Markdown ファイルに書き出す。stacked PR では、スタックの全体像と、現在の段を強調した変更の全体像を描く。
`/pr-visualize` の明示起動のみ。`--comment` で PR コメントへ投稿（承認必須）。レビューの指摘は行わない。
GitHub(gh) 前提。
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
差分は行の増減しか見せない。読み手が知りたいのは「どんなデータが入り、何をして、何が出るか」と 「それが呼び出し元の挙動をどう変えるか」。このスキルは PR を読み、その 2 点をシーケンス図にして、 図から読み取れないことだけを短い文章で補う。
references/mermaid.mdreferences/writing.md<skill-dir> はこのファイルのあるディレクトリ。収集・検証・投稿は scripts/pr-visualize.sh に任せ、
gh や git を手で並べ直さない。
$ARGUMENTS から次を読み取る。
#N、pr:N。省略時は現在ブランチの PR。以下 <PR> と書く。--comment: 解説を PR コメントへ投稿する（手順 8）。PR になっていないローカルの差分は対象外。その場合は diff-review を案内して終える。
解説と中間ファイルは一時的な成果物。置き場所は次の順で決める。以下 <out-dir> と書く。
ファイル名は次のとおり。再実行時は上書きする。
pr-<番号>-visualize.md: 解説pr-<番号>-visualize.diff: 退避した差分pr-<番号>-visualize.comment.md: 投稿用の本文（--comment のときだけ）bash <skill-dir>/scripts/pr-visualize.sh preflight "<PR>"
タイトル・本文・コミットメッセージ（見出しだけ。本文も要るなら --full）・変更ファイルの統計が出る。
次の 3 つを控える。
MODE: full は PR のリポジトリが作業ディレクトリの remote と一致した状態。degraded は一致しない状態で、
差分の外のコードを読めない。degraded では手順 3 と参照箇所起点の図を省き、--comment は実行しない。
TOOLS: mmdc が無いと図を構文検証できない。その場合は解説に「未検証」と書く。
STACK: size が 2 以上なら stacked PR。次のコマンドで、各段の変更ファイルとスタックの図を取る。
検出できるのは GitHub のスタック機能に登録された PR だけ。それ以外は単独の PR として扱う。
bash <skill-dir>/scripts/pr-visualize.sh stack "<PR>"
スタックでも、図にするのは現在の PR の変更だけ。差分（手順 2）と変更前の状態（手順 3）は、 1 つ下の段までを含んだ状態が基準になる。
ERROR: が出たら（未認証、PR が見つからないなど）、先にそれを解決する。
bash <skill-dir>/scripts/pr-visualize.sh diff "<PR>" --out <out-dir>/pr-<番号>-visualize.diff
差分は標準出力に流さずファイルへ置く。大きな差分を会話に抱えると、後の読解と執筆の精度が落ちるため。 lockfile と、縮小済みの js・css の差分は自動で除かれる（統計は手順 1 の FILES に残る）。
bash <skill-dir>/scripts/pr-visualize.sh fetch "<PR>"
作業ツリー・ブランチ・ref は変えない。出力の head_sha（変更後）と base_sha（変更前）を使い、
HOW TO READ に出るコマンドで差分の外のコードを読む。ブランチを切り替えて読むことはしない。
FILES の統計で当たりを付け、差分は必要な範囲だけ読む。full ならファイル単位の
git diff <base_sha> <head_sha> -- <path> が使える。
変更を次のように仕分ける。
| 変更の種類 | 扱い |
|---|---|
| 関数の処理の中身が変わった、関数が増えた、シグネチャが変わった | 図にする |
| 1 行程度の包み関数、引数の追加と受け渡しだけ、属性が 1 つ増えただけ | 図にせず、呼び出し元の図に含めるか 1〜2 文で書く |
| 新規の補助関数で、呼び出し元の図に含めれば伝わるもの | 単独の図にせず、呼び出し元の図に含める |
| 型やデータ構造の定義が変更の主役（関数の変更はそれに従うだけ） | 型の図を 1 枚描く |
| テストコード | 図にせず、「テスト」の節で何を確かめているかを解説する |
| 名前の変更だけ、整形だけ、コメントや docstring だけ、lockfile、自動生成されたファイル | 図にせず、末尾の一覧に載せる |
| 設定や CI の変更 | 文章で書く |
| ドキュメントの変更 | 文章で書く。手順や構造そのものが変わった・新しく加わったときだけフローチャートを描く |
図にする単位は関数。関数でなくても、挙動を持つ処理のまとまり（サブコマンド、定数に入ったスクリプトの断片、 テンプレートなど）は 1 単位と数える。 図にするのは 8 つまで。超えるときは、挙動の変化が大きいもの、入口に近いものを優先し、 残りは末尾の一覧に載せる。全部を図にすると、読む量が差分そのものを超える。 文書のフローチャートは、この上限に数えない。
選んだ関数ごとに、参照箇所を調べる（full のみ）。
git grep -n -w -e '<関数名>' <head_sha> -- [<path>...]
同じ名前の別物が混ざるときは、パスで絞る。図の単位がサブコマンドや定数なら、その名前で検索する。 文字列の中に埋め込まれた参照（別の言語の式やコマンド文字列）は、その文字列で検索する。
path:行 の一覧にする。多いときは代表 5 件と件数にする。追加・変更されたテストは、どの変更を確かめるものかを対応付け、テスト関数の定義位置（path:行）を控える
（手順 6 の「テスト」の節に使う）。
references/mermaid.md を読んでから描く。描く図は次の 3 種類。型定義が変更の主役のときだけ、型の図を足す。
stack の STACK MERMAID をそのまま貼る。
2 枚目は変更の全体像で、スタック全体の変更を描き、現在の PR が担当する領域を強調する。変更前後は、変更後の 1 枚に色付きの枠と注記で示すのが既定。流れ自体が組み変わったときだけ
2 枚に分ける（基準は references/mermaid.md）。2 枚を並べるだけだと、読み手が自分で違いを探すことになる。
新規に追加されたコードには変更前が無い。枠も注記も付けず、新規であることを本文に 1 回書く。
references/writing.md を読んでから書く。構成・文章の規則・言語はそこに従う。
書き出し先は <out-dir>/pr-<番号>-visualize.md。
PR 本文の説明とコードが食い違うときは、コードを正として解説し、食い違いを専用の節に書く。 それ以外の指摘（不具合、改善案）は書かない。
bash <skill-dir>/scripts/pr-visualize.sh mermaid-check <out-dir>/pr-<番号>-visualize.md
RESULT: OK → 冒頭の「図の検証」に「検証済み」と書く。RESULT: FAIL → 落ちた図を直して再実行する。修正は 2 回まで。それでも落ちる図は外し、
外した図の番号を冒頭の「図の検証」に書く。RESULT: UNVERIFIED → mmdc が無い。冒頭の「図の検証」に「未検証（mmdc なし）」と書く。--comment のみ）投稿は他人の目に触れ、通知も飛ぶ。--comment は「投稿する意思」であって「この内容で投稿してよい」
ではないので、必ず内容の承認を挟む。
投稿内容を確定させる。
bash <skill-dir>/scripts/pr-visualize.sh comment "<PR>" --from <out-dir>/pr-<番号>-visualize.md \
--dry-run --out <out-dir>/pr-<番号>-visualize.comment.md
本文は解説から自動で組み立てられる（全体像までは開いたまま、変更の詳細・テスト・ドキュメントなど
以降の節は見出しごとに折りたたみ、その中の図も図ごとに折りたたむ）。
--out のファイルが、投稿される本文そのもの。action（新規か上書きか）、chars、body_hash を控える。
ユーザーに承認を求める。次を必ず伝える。
--out の場所）と、対象にした head の SHAClaude Code では AskUserQuestion を使い、質問の要点と選択肢（投稿する / 修正する / やめる）は 本文にも書く。使えないときは選択肢を番号付きで列挙して回答を待つ。
承認されたら、控えた body_hash を渡して投稿する。
bash <skill-dir>/scripts/pr-visualize.sh comment "<PR>" --from <out-dir>/pr-<番号>-visualize.md --expect <body_hash>
承認後に解説を書き換えると body_hash が合わず拒否される。その場合は 1 からやり直す。
次の場合、スクリプトは投稿を拒否する。回避せず、理由をユーザーに伝えて解説ファイルだけを残す。
degraded（図が欠けた解説を投稿しない）解説ファイルの場所、描いた図の枚数、図の検証結果、図にしなかった変更の件数を伝える。 投稿したときはその URL も伝える。
--comment を付けて承認を得たコメント投稿だけ。レビューコメントや PR 本文の編集はしない。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.
Claude Code の並列エージェント(agent teams・teammate)の後始末と無応答時の打ち切りルール。`name` を付けて Agent を起動するとき、TeamCreate でチームを組むとき、teammate から `idle_notification` が届いたとき、評価ループ等で次のイテレーションのエージェントを起動する前、エージェントの返信が届かないときに参照する。`name` を付けない通常のサブエージェント起動だけなら対象外。
The English summary is being prepared. Showing the original description.
spec.md の REQ-# を入力に、機能一覧・モジュール構成・インターフェース・データフローを持つ docs/dev/<対象>/basic-design.md を作成・改訂するスキル。/basic-design <対象名> で明示的に呼び出されたときのみ使用する。
The English summary is being prepared. Showing the original description.
技術的な内容を、技術用語を排したビジネス職向けの平易な説明文に翻訳する。`/biz-translate` と明示的に呼ばれたときのみ実行する。
The English summary is being prepared. Showing the original description.
`git commit` / `git commit --amend` を実行する前、または「commit」「amend」「コミット」「コミットして」の一語・短文だけを渡された時点で必ず発火する git コミット実施ルール。理由や差分の説明が一切無くても、ファイル全文を読んでメッセージを組み立てる前に先に参照する。主目的は論理的に独立した修正を都度・適切な粒度でコミットすること。メッセージは Conventional Commits 形式、素材は同梱の決定論スクリプト commit-context.sh が出す staged diff のみ。「コミット分けて」と依頼される、独立した複数修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase / squash / cherry-pick 後のメッセージを整える、`gh pr create` の PR タイトルをコミット流儀へ揃える場面でも参照する。plan モードでのコミット計画の立案は commit-plan スキルの領分。
The English summary is being prepared. Showing the original description.
実装計画・リファクタリング計画・レビュー対応計画・並列作業のタスク分解など、計画を成果物として書き出すときに必ず参照するコミット計画ルール。plan モードでは ExitPlanMode で plan を提示する前に必須、計画ドキュメントや job-graph のタスク分解・エージェントへの指示文でも同様に適用する。計画成果物にコミット計画セクション（論理的に独立した修正単位での分割と Conventional Commits 形式のメッセージ）が無ければ実装に入らない。「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画を立てて」「コミット計画を立てて」「タスクを分解して」と依頼される、複数の独立した修正をまとめるか分けるか計画段階で判断する等の場面では、ユーザーが「コミット」に一切言及していなくても必ず発火する。コミットの実施（素材収集・メッセージ確定・git commit 実行）は commit-flow スキルが担う。
The English summary is being prepared. Showing the original description.
プロジェクトに 1 つの「完成の定義」docs/dev/definition-of-done.md を対話で構築・改訂し、機械判定節と人判定節の二部構成で書き出すスキル。/def-done で明示的に呼び出されたときのみ使用する。
The English summary is being prepared. Showing the original description.